logging problem BIT6

[malte]

Hi there,
we're using BIT6 pro build 1014. Since we moved from BIT5.3 to BIT6 we found a problem with the logging files.

We use the bit-input-script.txt to supply Serial Number Model No. etc.
to have it logged also. In BIT5.3 this was OK, since BIT6 these information are displayed in the GUI, but to get it into the log file, you need to stop and start the test once more.

So it seems, that the log file is created before bit-input-script.txt is parsed.

Kind Regards
Malte

[Ian (PassMark)]

We have tested this and you are correct.

If you use a BurnInTest V6.0 script file, with a pre-test application that generates the "bit-script-input.txt" to set report attributes like Serial number (as per our downloadable sample - with the plugin samples) , then the log file header is created before the pre-test application runs.

Without going into the background for the change (from V5.3), as a solution we have decided upon the following:
- Pre-test actions will run each time a script "RUN" command is executed (i.e. will be per test run within the script). So this is no longer the place to specify a script appliation to run applications that generates the "bit-script-input.txt".
- To set report items like serial number we will add a new script command, STARTLOGGING, to turn logging on and create a log file (start logging). The intent of this is to allow any test script reporting items to be configured before the log file is created.

Hence you would have a script like:
#Run an external applciation to set the report configuration subscript
EXECUTEWAIT ".\bitsetup.exe"
#Start logging using current settings
STARTLOGGING
#Set first test duration time for 1 minute
SETDURATION 1
#Run the test
RUN CONFIG

We will add this in BurnInTest V6.0.1016 due next week. I will send you a private build of this today.

Regards,
Ian Robinson

[malte]

Hi Ian,
thanks for your fast reply. Please check if I understand correctly.
We create the bit-input-script with a batch file before BIT is launched.

:: This is normally set by requests from the testers
set _sn=1234567
set _model=RK886EX
set _fa=FA123435
set _test=Malte
set _bitpath=.\BIT6\
:burnin
if exist .\log\%_sn%stress16h.log del .\log\%_sn%stress16h.log
echo SETLOG ".\log\%_sn%stress16h.log" >> tmp-script.txt
echo SETMACHINETYPE "%_model%" >> tmp-script.txt
echo SETSERIAL "%_sn%" >> tmp-script.txt
echo SETNOTES "Assembly order: %_fa% Tester ID: %_test%" >> tmp-script.txt
type tmp-script.txt > %_bitpath%bit-script-input.txt
start /wait %_bitpath%bit -p -c %_bitpath%stresstest.bitcfg -r -w

I create a temp-script.txt first, because I need same data later for interfaces tests and in the past, the bit-input-script.txt was deleted after used once.

So, do I have to add STARTLOGGING to the input-script?
We don't run any pre-test application at this point.
In later tests we run a batch file that just does:

type tmp-script.txt > %_bitpath%bit-script-input.txt

Best Regards
Malte

[Ian (PassMark)]

Malte,

Sorry, you are not using this mechanism as I expected. I thought you were running a test script (*.bits file).

The bit-script-input.txt mechanism was designed such that the input file would only be parsed when either:
1) The Pre-test "Run external application & wait for it to exit" is specified and occurs when starting a test run, or
2) The script command "EXECUTEWAIT" is run from a script.

So unless you are doing one of these actions, I am not sure why this worked in the first place.


I was not suggesting you add STARTLOGGING to the input-script, but rather to the script you are running. But based on your command line "start /wait %_bitpath%bit -p -c %_bitpath%stresstest.bitcfg -r -w" it looks like you are not running a script at all.


So we will change BurnInTest to parse the bit-script-input.txt file on BurnInTest startup and hence support more generic use for this Report information configuration input mechanism. In this case you should not have to change anything in your .bat file.

I will send you a new private build with this change today (planned for Public release next week).

Regards,
Ian Robinson