Corrupt "M" codes

[Tom Ferriter]

I am a new Delta Tau user. I was told by an independant rep that the use of M00 "program stop" code is the reason my CNC programs are randomly stopping after executing simple commands. Even programs without "M" codes stop at various points, but only after running a program with an M00 command. The controller accepts the "M00" and continues on after pressing cycle start, but then will stop at other areas usually after it completes a move. Does this make sense. I've never had any problems using M00. The tech says to use M01 for now. This works so far (small sampling) but I am suspicious. Does anyone have any thoughts on this? I would appreciate it. Thanks.

Tom

[steve.milici]

The “M00” code is the normal “end of program” M-code. This code is not known to have any issues. I will respond to your Techsupport E-mail question in greater detail.

[Tom Ferriter]

Thanks Steve. I appreciate your help so far on this subject. I will be at the plant tomorrow to perform additional tests. I will let you know when the system is online. Thanks again.

[curtwilson]

M-codes in a PMAC are simply subroutine calls, because every machine requires a different implementation of these codes. Mxx specifies a jump to PROG 1001, line label Nxx000. M00 is therefore a jump to PROG 1001, line label N0, and there is an implicit N0 at the top of a program, so an M00 code will cause the code in PROG 1001 from the top to the first RETURN command to execute.

 

The M-code subroutines are typically written by the system integrator for the machine, and will vary from implementation to implementation. If the system is one of our PMAC-NC systems, using our CNC HMI software on the PC, integrators usually start with our template for the M-code subroutines.

 

Typically, there is very little in an M00 end-of-program subroutine, as PMAC handles most end-of-program issues automatically. Some users will put an explicit STOP command in the program, so if the M00 is not at the end of the part program, it will still halt execution. Some users will put a DWELL command in to make sure that any pending synchronous outputs are fired. Others will make sure that certain outputs (e.g. coolant) are turned off, even if the part program "forgets" to do this. But that's about it.