Jump to content
OMRON Forums

Motion program aborts if Soft Limit occurs?


Recommended Posts

In a motion program, I am using a P-Variable to indicate status/progress through the program. ie; I start out with a status of 1, and then increment it as I progress through the program so that the user interface can track progress. And I have status codes for successful completion and other less successful outcomes.


However, if during a move in the motion program a soft limit occurs, the program aborts without completing.


So all my nice logic that I employed after the move to determine whether the program completed successfully or not and some other cleanup is never scanned if the motion program aborts due to soft limits being hit.


Am I missing something? Is there something I can do to make it complete the rest of the program, basically the cleanup?


The problem is, I have set the status value to 2 for program running and if it aborts, the status value is still 2, program running.


Is there some way to positively detect that the program has aborted?


How do others positively track the progress of a motion program through completion in order to determine whether it ran to completion or not?



M. Shaver


Link to comment
Share on other sites

  • Replies 3
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

I generally build any diagnostic routines into a background PLC. As a matter of fact, I have a dedicated PLC just for this purpose. Motion programs can be disabled for any number of reasons; soft limits, run time errors etc. Lookahead (if you're using it), blending etc, can also make performing discrete actions in a motion program somewhat cumbersome.


Having said all that, DT has built in some nice commands and status elements that make tracking what is happening in a coordinate system easier. First, I would not use P variables, instead use synchronizing line labels. There are two coordinate system elements that you can monitor when using these: Coord.Nsync and Coord.Ncalc. Read the help file or users manual for more detail on how each of these work. Note that these will be set to zero once the motion program stops running. Also, remember that a motion program can run in multiple coordinate systems at the same time, using a P variable in this case could lead to some confusing values, depending on the state of each coordinate system.


Normally I'll use a background PLC to monitor Ncalc to track progress through a program. Coord.ProgRunning will be set to 1 if the coordinate system is actively running a program (ProgActive is set to 1 if the program is active, again, see the manuals for differences between active and running). So, between ProgRunning and sync labels, you should be able come up with some pretty detailed diagnostic logic in your PLC.


One other thing I do..at the beginning of the program I set a specific global variable to the number of the motion program, at the end it gets set to the negative value of the program number. So for program #10, the variable gets set to 10 at the very beginning and to -10 at the end of the program. In combination with the status elements listed above, this is an easy way to see if that particular program is running and/or successfully finished.


Hope all this helps.


Link to comment
Share on other sites

All of kmonroe's advice is sound. The sequential synchronous nature of motion program calculations makes it easy to program defined sequences of motion and related tasks. However, this means that they, by themselves, are not suited to detect asynchronous events such as fault conditions.


Most people will use scanning PLC programs, whose calculations are asynchronous to the programmed motion, to monitor for unsequenced events such as fault conditions and operator intervention. (Others do the equivalent by querying repeatedly from the host computer and performing the logic there.)

Link to comment
Share on other sites

I did as kmonroe suggested, implementing a watchdog routine in a free-running PLC that ends up detecting the aborted motion program in question and setting an error code to failure since the motion program cannot.


Then later, unrelated to my original issue, I discovered by accident that a PLC program can also abort "silently". I had a PLC program doing some initialization upon power up or reset. Noticed that certain variables were never getting initialized. Realized that the PLC program was aborting partway through due to some obscure syntax error that I don't think the compiler was catching or maybe the compiler was aborting and just not compiling the rest of the plc program.


I'm used to industrial controllers having a form of exception handling whereby instead of quietly aborting, such errors will cause the execution to jump to a designated error handling routine whereby one can implement whatever form of error handling one wants or needs. Does the PPMAC have such exception handling capability?

Link to comment
Share on other sites

This topic is now closed to further replies.

  • Create New...