Resume from M0 inside motion program?

[jackvoxel8.com]

I am having some trouble using M0 inside my program. Here are some example NC files demonstrating my confusion:

 

Works as expected:

G1 X0.1 F1

M0

G1 X-0.1 F1

 

Works as expected:

G1 X0.1 F1

M0

G4 F1

 

Does not work as expected:

G4 F1

M0

G4 F1

 

Does not work as expected:

G4 F1

M0

G1 X0.1 F1

 

On the two cases that do not work as expected, the UI reacts as I would expect: the status bar says it is IN FEED HOLD, the cycle start and abort button are highlighted and the feed hold button is flashing.

 

However clicking cycle start does not continue the program. (The status says RUNNING and the Feed Hold button does become highlighted again)

 

The above simple programs are just dummy programs but I have a real application that has been exhibiting this behavior.

 

Any insight would be helpful.

[bradj23]

I tested this issues this morning and I was unable to replicate the problem.

 

I ran all the above codes and everything displayed expected behavior. That being said, it's a fairly common problem for users to upgrade their NC-16 HMI without upgrading the corresponding PLC's and motion programs. Every NC-16 program ships with a working sample PMAC project, I suggest comparing the sample project with your current files to make sure you have the latest upgrades to the motion programs. This includes files in the folders Global Includes, Libraries, Motion Programs, and PLC Programs. Most files have a change log on top and the last revision should have been 11/30/17.

[jackvoxel8.com]

Thanks for testing Brad. I confirmed that our HMI and PLCs are in sync. I wonder if some code we wrote broke this?

 

Do you know how M0 works with the HMI to pause? If I look at the implementation it calls `stop` which should not be resumable, but somehow cycle start in the HMI starts mid print.

[maxvoxel8]

FYI, I think we found the cause of the problem. It seems that in firmware version prior to 2.4.0, if a program has built up a non-trivial following error before the pause, it will not resume from the pause. If such a following error is present, subsequent programs did not reset the following error, and also would not resume from pause. Resetting the controller would reset the error and allow pause to work again until the error increased.

 

After updating to 2.4.0.180, the following error seems much less for the same program, and resuming is always successful.

 

I think this is related to the line in the 2.4 release notes, "When restarting a motion program after a Q (pause), S (step), or breakpoint stop, positioning axes do not have to be in the same position as they were in when the program was stopped."