unprocessible command found in simulate.processnextline - do_a

geoff07

Senior Member
Any idea what this means? Seen when starting to simulate. 'do_a' does not appear in the code, which runs with no issues on a real 40X2. PE6.0.9.3
 

geoff07

Senior Member
Well thanks for the offer. But it is 500 lines or so of code that works well on real hardware, so perhaps isn't offending. I was looking for an idea, maybe from Technical, regarding what the error message means so I could move on. You are welcome to have the code but without some idea of where to look it seems a bit pointless as you will get the same error message. My first assumption is that maybe there is a simulator problem. Lets first see what hippy or Technical have to say?
 

hippy

Technical Support
Staff member
Not sure I can help without the program code to discover what provokes the simulation error.

The way I'd approach it with the code, which you could try yourself, is to comment out all lines which aren't labels and check it simulates, which it should because it will effectively be an empty program.

Then start taking out those comments a block at a time until it stops working. When it stops it should be the error is in the last block you uncommented. Comment them out again, then uncomment a line at time until it stops. That's probably the culprit.
 

geoff07

Senior Member
Thanks hippy. It is not my intention to burden people with my problem, so thanks for the suggestion, I will do that. I had hoped that there might be some inside knowledge of the error message as a clue. I'm assuming that the compilers don't use the same code as the simulator interpreter. Otherwise both or neither would complain.
 

hippy

Technical Support
Staff member
You are welcome to post your code and we can sort it out, find the issue. It's not a burden because there shouldn't be an error and we will resolve that.

You are correct that the simulations use different code to the actual chips. It is technically possible to interpret the actual chip firmware and your compiled code with that but that is incredibly slow so the simulators do it slightly different. I would guess there's something we missed or didn't quite get right which is causing the problem.
 

geoff07

Senior Member
Thanks hippy. This is the code (541 lines). It is an overlay supervisory control system on my central heating (standard 'S'-plan at heart). The purpose is to implement weather compensation using on/off control of the boiler, operate the boiler near to its condensing sweet spot, and generally keep the boiler off as much as possible consistent with comfort. I am improving it at the moment but most of the code has been running for five years or more. It uses four sensing points that have hardware signal conditioning (240v -> 5v); four temperature sensors, and two relays.
 

Attachments

inglewoodpete

Senior Member
It does appear to be related to the way the simulator interprets the code. I got the error message to change from "do_a" to "do_o" by performing a double reversal of the logic in line 271. The fault appears to be related to the simulator's interpretation of the Boolean operator "And" or "Or".

I changed "loop until B_event <> Ev_cleared and B_event <> Ev_null 'exit comes here" (gives error "do_a")
to "loop while B_event = Ev_cleared or B_event = Ev_null 'exit comes here" (gives error "do_o")
 

hippy

Technical Support
Staff member
It does look like "do_a" applies to an "and" while "do_o" applies to an "or". Thanks for the source code and inglewoodpete's help in narrowing it down. We can now replicate the issue and provoke the same simulation outcome in easier to analyse and debug code -
Code:
Do
  If w0 = 0 Then
    Exit
  End If
Loop While w0 <> 0 Or w0 = 0
It seems to be related to the EXIT and having an AND/OR condition in the LOOP-WHILE/UNTIL. Remove either and it all works as expected.

Not sure what the issue is but I will log it and we'll take a look at it.

In the meantime, to allow your simulating to continue, you can replace your line 271 -
Code:
     loop until B_event <> Ev_cleared and B_event <> Ev_null 'exit comes here
with -
Code:
   #IfDef SIMULATING
     If B_event <> Ev_cleared and B_event <> Ev_null Then
       B_temp = 1
     Else
       B_temp = 0
     End If
     loop until B_temp = 1
   #Else
     loop until B_event <> Ev_cleared and B_event <> Ev_null 'exit comes here
   #EndIf
or, I think, if I've got the logic right -
Code:
   #IfDef SIMULATING
     If B_event <> Ev_cleared and B_event <> Ev_null Then : Exit : End If
     loop
   #Else
     loop until B_event <> Ev_cleared and B_event <> Ev_null 'exit comes here
   #EndIf
 
Last edited:

geoff07

Senior Member
Great work guys, especially for a Saturday.
The code in question (event monitor) constantly scans for something to do, and only exits the loop when something is found that needs action (i.e. an over-temperature or whatever). The null event is a temporary option to distinguish from 'cleared' . I can simply remove it for the simulation and remove the AND.
 
Top