Thanks for finding the documentation on the User-Defined Run-Time Error Trap. I couldn't find it in my panic.
I have updated by test program for both the watch dog timer and the user-defined run-time error trap to include the TRI documentation for these mechanisms.
I have some suggestions on how to make these two mechanisms actually useful for PLC applications:
- Make the error messages written to the PLC "visible" to custom functions.
- If the user-defined run-time error trap has been setup change
the behavior of the current WDT to call the same trap handler that
is used for the run-time errors. If you do this, it would be great
if the WDT timeout mechanism updated the LCD with some sort
of error message that would indicate that the problem is WDT timeout
[/list]
Why? This way the error handler can log the exception that terminated the PLC execution to either EEPROM or the filesystem. This allows debug of PLC systems that are running in the field and not in my lab. I am looking for ways to monitor 25 systems that are running at remote sites in 3 different countries.
To make the error messages available to the error trap provide some "special" access to the text array that your low-level firmware manages for the LCD display. I know that it is buffered on the PLC because it can be accessed via host link commands even if no LCD is physically connected to the PLC.
Maybe one of these access methods could be provided:
- Special case the LOAD_EEP$(n) to return the LCD buffer lines with the n has values such as -1,-2,-3,-4. I think you have already special case LOAD_EEP$(0) to return some string about PLC firmware version.
- Special case the $$[n] string mechanism to return the LCD buffer info for some value of n that is outside of the range 1..26. So $$[-1] might reference the first line of text in the LCD buffer
- Modify the run-time error trap code that writes the error message to the LCD to also copy the error message to Y$..Z$ before executing
the user-defined run-time error trap CF. These variables are "toast" as the CF can't do much other than reboot the PLC.
[/list]
Best regards,
Gary D*ckinson