MCodes & Slow Down etc

[matthewd]

Ok,
i am new to this forum and maybe this post is in the wrong place, anyway...

I am writing a CNC Interface for the Galil Controller. This is not a hobby.
My question is related to using M Codes within a G Code program.

Should a CNC machine stop motion before activating an M Code ?

By that i mean if i have a lot of move segments and then there is say an
M Code to turn something on, should motion decelerate to a stop before
executing the M Code or should it be done "on the fly" ?

I am a programmer, not a CNC operator and the dnc files i have to work with
could come from anywhere.

I have seen dnc files where the feedrate is high and then in the middle of bunch of move segments there might be an M Code which should turn something on, so i am not sure if it is the norm to pull up the machine
at the target position before the M Code, then run the M Code, then move on.

Anyone who has experience in this your advice would be appreciated.

thanks
Matt

[Al_The_Man]

This often can be set by choice in the controller as The M code function executed after the move command or The M code executed at the same time as the move command.
Either way the it is common for the M code to register that it is done by waiting for a finish signal from the logic processor, and originating from the controlled action, For e.g. if an M code is not required to wait for any finish, like turning on the coolant, then a finish signal is returned automatically.
The next block of code is not processed until the FIN signal is received.
Either way, a move command should not be stopped or held up, once started, by an M code.
I do alot of Galil programming in native language and use methods that download whole programs or segments, so the program run time is not really affected by the host PC.
The one drawback as far as I can see with many of the existing programs that mate with Galil, is the use of downloading code, one instruction at a time.
This appears to be the bottle-neck to speed.
A modern off the shelf package uses two processors, or muti-tasking processes, one for the CNC and the other taking care of the Machine functions, M codes etc.
Also, feed-rate overide should take effect by perception, immediatly, and the Fin signal also applies to S & T codes.
Al.

[matthewd]

Hi Al,
thanks for the reply.
So if i had a dnc file etc with the following code....

......
F500
X1000
X2000
X3000
M10
X4000
X5000
.......

So the machine is travelling fast at a feedrate of 500.
We encounter an M10.
Should the M10 code be configurable in the software to either slow down to
a stop at X3000 and execute the Mcode or execute the mcode on the fly whilst travelling at a feedrate of 500 or both ?

Maybe this means an MCode needs to be configurable to do several things..
1. Do we need to stop motion before executing the MCode or do it on the fly.
2. Do we need to sigal a complete as the mCode is executed or after it has finished?

I also do A LOT of native Galil programming and have for about 8 years.
I fully utilize the onboard buffer in the controller for moves and MCodes are run in the Galil controller and not on the PC but there is synchronization between the two. 3 Axes corner speed control as well. I also have a very nice interface with realtime 3d toolpath display etc etc.
Have been testing for quite some time and currently the software is in use
in a few installations but i have always had concerns over how the motion should be affected when encountering an MCode on the fly.

your thoughts ?

[Geof]

For what its worth: I run Haas machines using Fanuc protocol; they would stop after processing the X3000, process the block with the M code and then continue motion at the X4000 block. If the M command was in the same block as a G command the G would be processed first then the M and motion would stop until the M was complete.

[Al_The_Man]

The normal method is to specify a block of code e.g.
N10 G01 X100 Y50 M10
The G01 specifies am interpolated move of the X & Y axis, I favour the method of completing the move before implementing the Mxx code.
The M code will wait for a finish signal before performing the next block
N15 etc etc, otherwise it will hang at this point or output an alarm after a pre-determined time period.
As long as the programmer is aware that the instructions are performed sequentially in any block.
Is this a commercial product you are working on? I would be interested in the results when you are done, are you working on a Lathe package?
Al.

[matthewd]

Thanks Geoff.
To me that sounds backwards given the MCode is after the X3000 in the file.
But if thats the way it is who am i to argue !

Al,
i have seen a lot of files the way i have shown with an MCode all on its lonesome on a line with moves before and after the MCode.
Clearly if we need to stop to do the Mcode then vector deceleration on the segment before the Mcode (and previous segments if decel requires it) needs to happen. This what i do now, but was wondering if i may need to do it "on the fly" without decelerating to a stop before hand. I can do both if i have to though. I just wondered what was the norm.

Getting back to your comments about using 2 processors, is that necessary for most CNC machines ?
By that i mean i can execute an MCode in the motion controller within say 30mS after stopping motion by sending a command to execute a block of code in the Galil Controller say "#M10;SB1;WT100;CB1".
Is that not fast enough for "most applications".
I mean if your turning coolant on who cares if the axes stop and 30mS later the coolant turns on or the relevant MCode is executed ?

I am sure there are a lot of exceptions but i havent come across that sort of speed requirement.

The bottom line for us is the Galil has plenty of I/O available and as im streaming moves into the move buffer, the Galil controller is essentially asleep doing nothing in its application space.
As long as i keep the Galils buffer topped up fast enough all is well.

By the way i preprocess the complete G Code file in memory including calculating all the corner speeds etc etc. This means mimimal PC processing whilst streaming moves down.

Yes, it is a commercial product. Not so much interested in Lathes at the moment but that may come if theres enough interest. I dont see what would be so hard about it. As you know the Galil Controller is a very capable controller and now with the Accelera Series its very fast.

regards
Matt

[Al_The_Man]

I think the bottom line is you only need to do what makes sense in the real (CNC) world.
The conventional CNC processes code a Block (not instruction) at a time, i.e anything between two carriage returns.
The option is to set up wether the M code is processed concurrently or after the motion code. Either way the M code has to complete before the next BLOCK of instructions are operated on.
The only other instruction that does not operate on this premise is the G31 where the Block and motion will terminate prematurely on a skip signal.
In the Galil, the operation is on a per command basis, and sure you can blast through motion code leaving I/O in the dust.
But usually in the real world, the machine control is very much slower even switching on coolant, where you do not customarily wait for an acknowledge signal, there is a relatively long delay before coolant is available.
Almost all M,S & T codes require to hold up the Motion until they acknowledge they are complete.
In Galil If I want something to occur concurrently, I will use another thread.
Al.

[matthewd]

Originally Posted by Al_The_Man In the Galil, the operation is on a per command basis, and sure you can blast through motion code leaving I/O in the dust. Al.

Yes the Galil controller is on a per command basis.
But, the Galil controller has a move buffer with which i stream move data into.
That is done from the host PC. There is no Galil code in the controller running except on thread watching the segement counter "CS".
When the right segment has completed the output is turned on.

....

#LOOP
JP#LOOP,_CS < 100
SB1 'Turn on Output
....

This means the reaction time is quite fast, say a few mS.

This works for me but i would understand if faster reaction times are needed
then another processor would be warranted.
For the majority of applications i can think of the way i do it will be fine
and doesnt mean the customer needs to buy an additional I/O card.

Thanks for your advice.

regards
Matt