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