My DT800 program is extending to proportions that it is more difficult to find bugs in the program. In the help file I found that there are debugging options available.

The error messages in the lower pane tell me the error codes and I can track them in the manual, so I know what kind of error it is. BUT I am still not able to locate the specific program line where the error occurs. Can anyone give me a hint how to deal with this problem?

Best Regards,
Gerben Bakker

Good morning Gereben,

The simplest way would be to load the program text into the text window and send the code line by line. This way the dataTaker will return error messages after each line is entered.

The error are most likely in line of alarm statements or in User channel types.

Cheers,
Roger

Thanks Roger,

So I understand there is no debugger reply with line numbers available? In that case I have to ask you an other question: Is there a limit to the program length, because I get the message

E32: Job not found.

I think this is strange because sending the program works well. But if I send the command CURJOB or alike I don't see the program in memory. If I try to send a former (smaller) program everything works fine. If I send the program lines one by one it doesn't give structural replies: one time it gives an error message, the other time it doesn't; so I cannot lie a finger on it!

Good morning Gerben,

The DT80 has line numbers and enhanced debugging but not the DT800.
Your error is means the job has not loaded, This usually means there is either a syntax error or there is data or alarms in the logger from a job with the same name. You should see a error message for both these conditions.

Cheers,
Roger

Thank you Roger,

It was a problem with an IF command that I had made within a user channel type. Now I solved it using an alarm, but in future I think IF statements are more clearly to read by users afterwards. I don't know why it didn't work with the IF statements yet.

Good morning Gerben,

Post the IF statement here and I'll take a look at it.

Cheers,
Roger

Hi Roger!

The IF-statements in Schedule G were as follows:

RG"ISCObem":121CV LOGOFFG G
'This subroutine will be executed only once if {lit_trig_Bem>=1}
'AND {ISCO_vol<1}
'Adjust Mon and Submon values as follows:
'IF submon+1>=6, --> submon=0 and mon=mon+1
'IF Submon+1<6, --> submon=submon+1
IF(91CV+1>6) {[91CV=0 81CV=81CV+1]}
IF(91CV+1<6) {[91CV=91CV+1]}

'Write to outputfile
81CV("Mon_Bem")
91CV("SunMon_Bem")

'Turn on ISCO for 50ms
7DSO=0 DELAY5=50 7DSO=1

'Set ISCO-flag when Mon=24 and Submon=5
111CV=81CV=24AND91CV=5

'Reset 121CV causing subroutine to stop
121CV(NL)=0
END

Regards,
Gerben

Good morning Gerben,

There are two errors in the IF statements.

1. There is a space between the If condition and the action. This is not allowed.
2. Calculations are not allowed in the test condition of the statement.

Instead of

IF(91CV+1>6) {[91CV=0 81CV=81CV+1]}

You need to either add a line 91CV=91CV+1 or change the test condition from 6 to 5. (The logic works out the same)

IF(91CV>5){[91CV=0 81CV=81CV+1]}

or

91CV=91CV+1
IF(91CV>6){[91CV=0 81CV=81CV+1]}

Cheers,
Roger

Thank you Roger,

This was useful! What are the limits of the IF command, e.g. I presume it is not possible to add AND or OR commands within the test condition (at least I didn't succeed)?

Regards,
Gerben

Good morning Gerben,

While you can't use logic chaining inside the IF or ALARM statements you can still chain statements together.

The logical operations are AND, OR and NOT, i.e:

IF(1CV>5)AND
IF(1DS<0)"This is an AND chain"{[1CV=0]}

There is no Else statement but the same can be done by using two different if statements where the conditions are mutualy exclusive.

Cheers,
Roger

I have found that for some complex tasks, you can also break various ALARM conditions up into different schedules and turn these on and off as required.