PLC hanging

[Joel Moore]

I'm using an FMD88-10 in a very basic application as a 2-axis stepper pulse generator.  We have some manual buttons, limit switches, and beam sensors all working together in a physical relay network to provide the PLC with "RUN" and "DIRECTION" inputs for each axis.  It's a very simple program, basically just STEPMOVE and STEPSTOP in response to these inputs.

A few times now the system has stopped working and upon connecting to the PLC I am presented with dialog box that says:

"Run-Time Error in Fn #5.
 Error: DM32[] index out-of-range".

In the ViewVariable dialog I can see the following message being printed to the virtual LCD display:

"Undef. Interrupt
CF #0005:006E"

Other info:
- Custom function 5 is simply the command "STEPSTOP 1".
- I don't have any interrupts defined.
- I don't use or refer to DM[32] anywhere in my program
- The PLC's firmware is version r76A

Thanks for any advice you can offer.

Edit: Corrected typo in error dialog message

[garysdickinson]

Joel,

I am pretty good at writing code that misbehaves and breaks the PLC.  

Your issue with the runtime error about DM32 index values would be easy to fix if you were using DM32.  

I assume that TRI is working with you to figure out the actual problem.

You can search the forum for "F8” and you will find a bit of info on debugging of run time errors and some hints from TRI.

Best regards,

Gary D*ckinson

[Joel Moore]

I haven't heard from TriPLC yet.  I was going to give them a chance to start their morning in CA before I contacted support directly.

Thanks for the tip about F8.  I'll need to trigger the error again before I can check if it can tell me anything useful since I stripped out some unused code since posting my message and I think the original address (006E) probably isn't valid anymore.
 
I did wonder though if FN #5 refers to FN #5 as seen in the code editor (which starts at 1) or is it the function index in the actual source file (which is 0 based).  Maybe the F8 key will clarify that point for me.

[support]

It may be caused by an actual undefined interrupt that was triggered when the STEPSTOP command was executed. STEPSTOP disables interrupt channel and if this was done in a untimely manner it could result in the CPU chip throwing an undefined interrupt exception because of some internal register conflicts. It doesn't happen most of the time but it is one of those time when "all stars aligned" that the undefined interrupt exception was triggered.

The earlier firmware versions (r76 was released in 2010) did not build in enough software mechanism to protect against the undefined interrupt that could result from untimely disabling of interrupt. We believe the subsequent firmware has mostly fixed such issues.

You can either upgrade the firmware (r76 it is not field upgradable so it will need to be sent back for factory upgrade) or you can define an interrupt custom function using INTRDEF 100, n, 1   where n is the custom function number that is used to trap the Undefined Interrupt. Within this error trap custom function you can save the data you need and then issue a REBOOT command to restart the CPU and recover from the undefined interrupt so that the controller will not stop operating.

[garysdickinson]

Joel,

I am glad that TRI was able to give a better answer.  I have been working with a similar problem with PLC systems in the field "hanging" after running without issue for years.

I have been working with code to act as an interrupt trap and then REBOOT the PLC.  Simply rebooting the system may be enough to make the PLCs appear to be reliable.  Unfortunately the message that describes the run-time problem,

"Run-Time Error in Fn #5.
Error: DM32[] index out-of-range"

and

"Undef. Interrupt
CF #0005:006E"

are not available to PLC custom functions.  So the interrupt trap code cannot log the reason that the PLC was REBOOTed.   This makes it impossible to figure out what the real problem is and impossible to actually fix.

Best regards,

Gary D*ckinson

[Joel Moore]

Thanks, support and Gary.

I've added a custom function that reboots the PLC when an unhandled interrupt is thrown.  Hopefully that'll take care of the unresponsive PLC issue.

However I did find that I was still having issues with the stepper motors "running away" despite the input I'm using as a "Run"signal being off.  After further investigation I think this input can be very intermittent or bouncy at certain points which probably resulted in quick successive and intermingled calls to STEPMOVE and STEPSTOP.  Maybe that's what was causing the interrupts.

So now I'm using the "Run" input to latch a relay which is what initiates the STEPMOVE and the relay doesn't get cleared until STEPSTOP is called.  I'll probably add some additional debouncing elements to further filter out unstable inputs.

[garysdickinson]

Joel,

I am glad that you are making progress on debugging.  

Noisy mechanical contacts can be troublesome.  Your solution with setting a RELAY on an input going active and clearing it only after some event has occurred seams reasonable.

I, often, condition noisy mechanical contacts by using the noisy INPUT to control a TIMER with a SV of 1 (0.1 seconds).  I use the TIMER's contact in the rest of the ladder program.  This introduces a small bit of a delay in response to the input but filters out any false signals.

Gary D*ckinson

[Joel Moore]

That's exactly what I just implemented.  Let's hope that puts it to bed.