Integer Stack Overflow

[njlaw]

Hello All,

I'm having a rather confusing problem on a Nano-10 that has me thinking I'm just overlooking something simple.  One of my PLCs keeps giving an "Integer Stack Ovrflw" error.  I know what a Call Stack Overflow is and what an Integer Overflow is, but I'm not familiar with an Integer Stack Overflow.

The actual error output is:

Code: [Select]

Integer Stack Ovrflw
CF #0008:0D20
And the code listing indicates that it's happening in my calculation of DM32_LUTOutput:

Code: [Select]

0CF9 | IF (DM32[Jmid+1] - DM32[Jmid]) = 0 THEN
0D09 | RETURN
0D0A | ENDIF
     |
0D0B | DM32_LUTOutput = DM32[Imid] + (DM32[Imid+1] - DM32[Imid]) * (DM32_LUTInput - DM32[Jmid]) / (DM32[Jmid+1] - DM32[Jmid])
     |
0D43 | RETURN
The funny thing is I've tried populating the same LUT in a lab Nano-10 as in the problem unit and I have no problem calculating DM32_LUTOutput.

Any pointers would be appreciated!

Edit

Apparently changing the calculation to

Code: [Select]

N = (DM32[Imid+1] - DM32[Imid]) * (DM32_LUTInput - DM32[Jmid])
O = (DM32[Jmid+1] - DM32[Jmid])

DM32_LUTOutput = DM32[Imid] + N / O
caused the issue to go away.  Why, however, I have no idea.  With the way the compiler writes the instructions, is there a specific integer arithmetic stack that is overflowing?  It also doesn't explain why the same code seems to work perfectly on another Nano-10 that is also r84J.  As an aside, is there a way to retrieve runtime exceptions via Modbus?  It would be very nice to report on those automatically.

Nathanael

[garysdickinson]

Nathanael,

I can’t answer your main question with any authority.  I think that if breaking the calculation into multiple statements gets you the correct answer without crashing TBasic you are pointing at a problemS ( or limitations) with the arithmetic expression parsing.

My guess is that the run time arithmetic expression evaluation is coded  using a recursive descent algorithm.  Most of these algorithms are stack based.  Intermittent values and return addresses get pushed onto a stack.  The use of parentheses to force evaluation order will result in things being pushed onto a stack. You may have written code that exceeds size of this stack structure.  I have broken tBASIC many times, however, your issue is new to me.

The TRI people will get you the correct answer.

I can answer your question about runtime exceptions. The short answer is No.  There is no documented way to access any information about a runtime error. The information is only available if you have a LCD plugged into the PLC and you are staring at the PLC OR if you are running online monitoring when the error occurs.

The error messages are stored in a buffer on the PLC and are accessible via the TRI host link protocol.  However, the host link commands are not documented.  The buffer is not accessible from tBASIC.

Runtime errors, normally halt the execution of the ladder logic.  You can set up a CF to act as an exception handler. If this is done the designated CF is called rather than halting execution.

Because you can’t access the LCD buffer memory in the CF, it is not possible for a user written exception handler to "know" what exception was caught.  I use the run time exception handler to reboot the PLC as there is nothing else that it can do.  It allows the PLC to restart without having to physically cycle the power.

I use the PLC watch dog timer in the same manner as the exception handler.  I just reboot the PLC.

I have explained these issues with TRI and suggested ideas on how and why to provide access to the runtime errors, but have been unsuccessful in persuading them to add this capability.  Perhaps you will be more persuasive.

Best regards,

Gary Dickinson

[support]

For efficiency reason, the integer math operands are pushed and popped from a separate 32-bit integer stack (since all integer math are 32-bit) rather than on the byte-oriented PLC program execution stack. A separate stack pointer is used to keep track of the int32 stack. The integer stack size is 16 which is very unlikely to be exceeded in regular (non-recursive) expression.

Is your integer stack overflow issue repeatable?  Is this part of the routine occurring in an interrupt service routine?

As for the runtime error it is not retrievable via Modbus.  If you trap the runtime error using the runtime exception handler as mentioned by Gary, you can either reboot the PLC or you can turn on a relay flag to indicate a runtime error and your Modbus host can monitor it via Modbus mapped relay bit.  The PLC thereafter may enter an endless loop  using statements such as   WHILE 1 : ENDWHILE  and wait for user to reboot it.

The LCD readout is actually accessible via a hostlink command but is not accessible via Modbus. Since the PLC is supposed to PAUSE after a runtime error to let user review what went wrong, only iTRiLOGI is provided with the information so that it can feedback to the programmer. 

In the next generation of PLC that we are working on we certainly are going to add a lot of useful suggestions to the PLC. In fact a user and system log utility that is available in the next PLC and i-TRiLOGI will be a very very useful feature for programmers.  Stay tune - it is going to be exciting.