Auto tool change issue?

[DaveCVI]

hi,

I'm guess you haven't seen anything like this before I'm guessing the fault likes with the UC300? I can see some more emails to the manufacturer in the near future.

Regards
Rob

I share your frustration with the problem. It sounds as if the UC300 is not giving the same behavior as the mach 3 parallel port driver.

Problems like this are why I had to limit official MSM support to a few well known and well supported motion devices. We could not afford to act as the test & debug center for other companies products.

I do have an idea - if the device is skipping the first line or couple of lines after an M6, try to see if it is skipping a fixed number of gcode lines. If it is a single of fixed number of lines, say for for example 3 lines, then maybe you could put 3 "no-op" lines after the M6. a goog no-op code would be a short dwell (G4).

And writing that makes me think of another idea... Mach has a problem syncing some sequential operations. Internally it gets confused and forgets to finish one operation before it starts the next. This sounds like it could be what it happening to you... maybe the gcode interpreter is not waiting for the M6 to finish and is going on before the M6 is done. That could show up as some number of lines after the M6 not being executed (it tries, but the internal queues are out of sync).

Consider this little utility I use inside of MSM:

Code: Select all

Sub MachRefWait()
	' ok the following is a mach hack....
	' (relevant to mach 3.x.x)
	'
	' it turns out that Mach reference operations do not wait for the action to be complete before returning to the calling script. 
	' Yet, the calls are commonly used as if they are blocking calls (even though they turn out not to be) - 1024.set also uses them as if they are blocking
	' Add to this the fact that there is no built in API to wait in a script for a reference operation to be complete...
	' and we have a timing hole that the script can fall into.
	'
	' But we can trick mach by inserting a short dwell into the Gcode queue, 
	' the dwell will show up internally to mach as a gcode movement that IsMoving() API ***will*** wait on,
	' AND (this is key) mach will ***not*** start executing the dwell command until the reference op is done.... 
	' thus we can force a wait until the ref (and dwell) operation is completed.
	'
	' The dwell time amount is not important.  I used P0.1, the time unit (sec or ms) depends on the mach config setting.
	' Either way the added delay will not be noticed as part of the overall homing sequence time. 
	Code("G4 P0.1")
	While IsMoving() 
		sleep 10
	Wend
	Exit Sub
End Sub

I'd be curious if a block of

Code: Select all

	Code("G4 P0.1")
	While IsMoving() 
		sleep 10
	Wend

right after the M6 makes the problem magically go away... ?

Dave

[Treb63]

Hi Dave,

I tried a G4 P3.0 yesterday in the part programme straight after the M6 and the problem did indeed go away also M0 or M1 seemed to cure it however MAch3 was also ignoring this line so the dwell would not work or the op stop or stop commands but the M6 did complete correctly yippee..

I agree a fix would be to add a G4 P*.* after every M6 in my post processor if I new how! or is there a more elegant solution by adding it to the end of the M6 tool change macro to call another dwell before finishing? don't care if its 1 to 5 seconds wont hurt my set up at all again not sure how to edit or modify this macro.

regards
rob

[DaveCVI]

Hi,

I agree a fix would be to add a G4 P*.* after every M6 in my post processor if I new how! or is there a more elegant solution by adding it to the end of the M6 tool change macro to call another dwell before finishing? don't care if its 1 to 5 seconds wont hurt my set up at all again not sure how to edit or modify this macro.

Alas, I think the dwell will have to be in the main gcode program.
mach implements M6 like this:
1) running program hits M6
2) mach sees the M6 and makes an up level call to one or more user scripts (Depends on the tool change mode in effect at the time of the M6):
3) mach finds and starts M6Start
MSM uses M6Start to move to the TCP etc...
4) at the end of M6start, mach waits for a cycle start input to continue (this is what the stop&Wait mode does in mach)
5) mach finds and starts M6End
MSM uses M6Edn to do any needed probing as part of the tool change etc...
6) M6End finishes
<< it is here that I think things are getting messed up by the UC300
Not that the system has made recursive calls to itself while doing all of this. Somewhere in that complexity, something appears to be causing the UC300 to get confused (Since it all works OK on a PP or a SS). >>
7) mach continues the main program on the line after the M6
I think step 7 is starting before step 6 ends.
The theory is that the addition of the G4 and the motion wait loop after the M6 resync steps 6 and 7 by forcing step 7 to wait for motion to stop.

Alas, I expect it's not just the order of the gcode - it's also which part of things the gcode belongs to (The M6Edn or the main program) that matters. So I think the G4 has to be in the main program instead of at the end of the M6End.

If you are generating code from a CAM program, the thing to do is to edit the post processing to add the G4.

Each Cam program has a different way to handle post processing - so I'm not sure I can be of any help there as I'm only familiar with the few cam programs I happen to use.

What Cam program are you using?

Dave

[DaveCVI]

Hi,

I agree a fix would be to add a G4 P*.* after every M6 in my post processor if I new how! or is there a more elegant solution by adding it to the end of the M6 tool change macro to call another dwell before finishing? don't care if its 1 to 5 seconds wont hurt my set up at all again not sure how to edit or modify this macro.

Alas, I think the dwell will have to be in the main gcode program.
mach implements M6 like this:
1) running program hits M6
2) mach sees the M6 and makes an up level call to one or more user scripts (Depends on the tool change mode in effect at the time of the M6):
3) mach finds and starts M6Start
MSM uses M6Start to move to the TCP etc...
4) at the end of M6start, mach waits for a cycle start input to continue (this is what the stop&Wait mode does in mach)
5) mach finds and starts M6End
MSM uses M6Edn to do any needed probing as part of the tool change etc...
6) M6End finishes
<< it is here that I think things are getting messed up by the UC300
Not that the system has made recursive calls to itself while doing all of this. Somewhere in that complexity, something appears to be causing the UC300 to get confused (Since it all works OK on a PP or a SS). >>
7) mach continues the main program on the line after the M6
I think step 7 is starting before step 6 ends.

Theory 1: The addition of the G4 and the motion wait loop after the M6 resync steps 6 and 7 by forcing step 7 to wait for motion to stop.
if this is what is happening, alas, I expect it's not just the order of the gcode that matters - it's also which part of things the gcode belongs to (The M6Edn or the main program) that matters. So I think the G4 has to be in the main program instead of at the end of the M6End.

Theory 2: If the G4 without the wait loop fixed things, then it may not be a sync problem but just that the next line of gcode is getting lost somehow. You could test this by putting any gocde there and seeing that it is indeed ignored (UH, be a bit careful... just in case it NOT ignored... maybe a G0 Z-1000 is not a good line of code for this test ) But the line getting lost is in the main program, so the dummy sacrifice line needs to be in that stop in the program also.

If you are generating code from a CAM program, the thing to do is to edit the post processing to add the G4.
BTW, it does not seem to matter what the dwell length is - as long as it's non-zero, so ti can be a short amount of time.

Each Cam program has a different way to handle post processing - so I'm not sure I can be of any help there as I'm only familiar with the few cam programs I happen to use.

What Cam program are you using?

Dave

[DaveCVI]

Hi,

I agree a fix would be to add a G4 P*.* after every M6 in my post processor if I new how! or is there a more elegant solution by adding it to the end of the M6 tool change macro to call another dwell before finishing? don't care if its 1 to 5 seconds wont hurt my set up at all again not sure how to edit or modify this macro.

Alas, I think the dwell will have to be in the main gcode program.
mach implements M6 like this:
1) running program hits M6
2) mach sees the M6 and makes an up level call to one or more user scripts (Depends on the tool change mode in effect at the time of the M6):
3) mach finds and starts M6Start
MSM uses M6Start to move to the TCP etc...
4) at the end of M6start, mach waits for a cycle start input to continue (this is what the stop&Wait mode does in mach)
5) mach finds and starts M6End
MSM uses M6Edn to do any needed probing as part of the tool change etc...
6) M6End finishes
<< it is here that I think things are getting messed up by the UC300
Not that the system has made recursive calls to itself while doing all of this. Somewhere in that complexity, something appears to be causing the UC300 to get confused (Since it all works OK on a PP or a SS). >>
7) mach continues the main program on the line after the M6
I think step 7 is starting before step 6 ends.

Theory 1: The addition of the G4 and the motion wait loop after the M6 resync steps 6 and 7 by forcing step 7 to wait for motion from step 6 to stop.
if this is what is happening, alas, I expect it's not just the order of the gcode that matters - it's also which part of things the gcode belongs to (The M6Edn or the main program) that matters. So I think the G4 has to be in the main program instead of at the end of the M6End.

Theory 2: If the G4 without the wait loop fixed things, then it may not be a sync problem but just that the next line of gcode is getting lost somehow. You could test this by putting any gocde there and seeing that it is indeed ignored (UH, be a bit careful... just in case it NOT ignored... maybe a G0 Z-10000 is not a good line of code for this test ) But the line getting lost is in the main program, so the dummy sacrifice line needs to be in that spot in the program also.

If you are generating code from a CAM program, the thing to do is to edit the post processing to add the G4.
BTW, it does not seem to matter what the dwell length is - as long as it's non-zero, so ti can be a short amount of time.

Each Cam program has a different way to handle post processing - so I'm not sure I can be of any help there as I'm only familiar with the few cam programs I happen to use.

What Cam program are you using?

Dave

[Treb63]

Hi Dave,

A great day today after some testing to confirm that even a G4 P0.1 dwell sorts out the problem, two minutes editing my part programmes today and a full days production with not one error

I am using Solidworks 2013 with HSM express, I have demoed quite a few packages and this one came out on top for me with only a little background in code generation but 35 years building and servicing CNC tools I needed something I could jump straight into so far very pleased with it, if only I could afford the HSM works add on

I will have a look at the post options Im sure there is something on the web on how to edit it..

Many thanks

Rob T

[DaveCVI]

hi,
That's good news.
And now you have a specific test case that shows that the UC300 has a bug that can cause skipping the gcode line after an M6.
If you would report that to the UC300 folks that may help someone else from getting bit buy this bug.

I hear that SolidWorks + HSM is a nice combo. I've not been able to justify Solidworks for my part time needs so I'm using Alibre + OneCNC.
However, ever since Alibre turned into Geomagic (that's pronounced "Geo-crap-ic" around here ), things have gone down hill fast in terms of both price and customer service... Solidworks may yet be in my future...

Dave

[Treb63]

Hi Dave, I have the full OneCNC suite from my employer however as I have to train myself I just couldn't make inroads into the basic stuff like I could with Solidworks, plus if I leave my employer I loose the licence so needed something for ever so to speak.
I tried a hooky copy of HSM works and it looked quite good for a while but was a bit flaky so preferred to keep things legitimate and registered for the free HSM express. Does everything I need so far and I suppose if I ever need true 3d I can export from Solidworks to OneCNC then try and learn the coordinate assignment bit......
I've tried to contact the UC300 manufacturer and he suggests trying to see if the fault exists without the MSM screenset as he doesn't have it so can't recreate the fault. As the issue only seems to happen after a M6 and the standard Mach 3 screens doesn't include the macros it could be a bit tricky for him to trace, will see if he can suggest another way to recreate the issue.

Rob

[DaveCVI]

Rob,
The UC300 guys can download and install the MSM PRO trial version - that will give them 30 days of debugging.
If they want to contact me, I'd also be willing to arrange to get them a complimentary copy of MSM Pro. If they will fix the controller bug, I'll help by providing the test environment for them.

Dave

[Treb63]

Hi Dave,

Sent the guys for the UC300 a message will wait to see what happens,

PM sent

Rob T