User-Defined Runtime Error

[garysdickinson]

I am attempting to debug a problem with an FMD88-10 PLC located in another continent.  My client describes the problem as the PLC being "paused".  The behavior that he is describing is consistent with a run-time error.  

I am working to get more accurate information about the issue from my client. But this will take both time and patience on my part.  I seem to not be blessed with much of either...

So in the mean time, I am trying to "instrument" the clients PLC code to log the problem.  I think that there are a few things that I can look for:

• User-defined runtime Error: defining an interrupt handler for run-time errors using the INTRDEF 100, n statement.
• Watch dog timer.  

So here are my questions about INTRDEF to catch a run-time error

• With the INTRDEF approach, how does the custom function "know" what triggered the run-time error?  
• Because CFs on the FMD88-10 do not accept arguments, you can't pass the error info to the CF.  Is the error stuff stored in some undocumented register that the CF might be able to access, say DM[4001]? Oh that would just generate another run-time error....
• Yes, I know that the error info should be displayed on the 4x20 LCD. How does the CF "read" back what was written to the LCD by the PLC firmware?  

I believe that the only way to access this info is via a host link command.  I don't have enough spare serial ports on the FDM88-10 to allow me to wire the ports together. This way I could issue a host link command(s) to read the LCD display and get the strings spit out one serial port and sucked up by the other port.  

Could I achieve this by using issuing a host link command via Ethernet?

• If I could "read" back the error info can I write it to the extended file system to generate an error log?  How much of the PLC code can I expect to run from the run-time error interrupt handler?
• Is there anything that I can do from the real-time error interrupt handler other than to report the PLC?

On the dead-man timer mechanism.  Is there any way that I could log the events that led up to the timeout?  Or does the system just reset and start over?

Best regards,

Gary D*ickinson

[support]

When a runtime error occurs it will pause and report the location of the runtime error both on the LCD screen as well as virtual LCD screen and via special hostlink command that the i-TRiLOGI can retrieve to report on the runtime error. If you are able to connect to the PLC via Ethernet you should be able to observe the runtime error on the virtual LCD on the online monitoring screen when the runtime error occur and the PLC is set into the PAUSE mode.

However, the runtime error messages are not passed to the TBASIC as the purpose was for the programmer to check the location of the error from iTRiLOGI and diagnose it. Historically when a runtime error occurred in TBASIC the PLC is paused immediately and therefore TBASIC will no longer run and hence there wasn't a need to pass the info to the program since the program no longer could run.

The INTRDEF 100,n function was designed mainly to trap undefined interrupt but subsequently also supports trapping of runtime error as a way out for the PLC to orderly reboot itself in installation where programmer may not be readily available to access the controller to fix the software bug, but yet the process may not tolerate a long downtime. I agree that with this trapping capability the runtime error messages could have been passed to the TBASIC for logging purpose and this should be added to future firmware revisions. For now unfortunately none of your suggested method would work, except for the loop back of the serial port which probably wouldn't make a lot of sense unless the two serial ports are not in use.

[garysdickinson]

Thanks for the great feedback.  

On the LCD display, I noticed that on recent firmware revisions that you added something like Load_EEP$(0) to return a more complete firmware version as a string.  How about Load_EPP$(-1) .. Load_EEP$(-4) to return the the LCD strings 1..4?

I can thing of lots of fun things to do with this capability...

I had great hopes for the INTRDEF 100, N statement.  In the old days, both DOS and UNIX had similar capabilities to provide for a user-defined interrupt handler for run-time exceptions. Both the UNIX and DOS versions made enough information available to the interrupt handler to be useful.

I have been running the client's PLC code 24/7 for months and have never had my test PLCs go into PAUSE or throw a run-time error.  So I was just hoping for a easy way to instrument the client's PLC to see if I could catch it misbehaving.

Gary D.