Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: matttargett4 on February 10, 2011, 07:17:21 AM
-
Afternoon,
I have just changed my plasma cutter to one which has a arc ok signal on it, it seems to activate this signal as soon as the arc has transferred not once the plate has been penetrated, this means that when i have the thc mode set on in mach as soon as the arc transfers the machine starts to move but the arc hasnt penetrated the plate, i need to get some kind of a pause in there so i modified my sheetcam post processor to have a pause at the right time but mach seems to ignore it and as soon as it sees the arc ok signal it goes to the next line which has a machine move in it, any ideas why this happens? or if not any ideas on how i can get round it??
Help would be greatly appreciated
Matt
-
Hi Matt
it seems to activate this signal as soon as the arc has transferred not once the plate has been penetrated
This is correct behaviour.
this means that when i have the thc mode set on in mach as soon as the arc transfers the machine starts to move but the arc hasnt penetrated the plate, i need to get some kind of a pause in there so i modified my sheetcam post processor to have a pause at the right time but mach seems to ignore it and as soon as it sees the arc ok signal it goes to the next line which has a machine move in it, any ideas why this happens? or if not any ideas on how i can get round it??
This is normal procedure. i.e. go to pierce height, fire, wait while pierce, drop to cut height, start motion. Which Sheetcam POST are you using and can you post the few lines of gcode you use at the moment please.
Ian
-
Thanks for the reply,
I dont have the code to hand but i goes along the lines of
g28.1 z3.0
G92 z0.0
G00 z9.4
G92 z0.0
g00 z6.0
M03
P (any number i want to put in)
z3.0
x.........y.......
Im using the mp 1000thc delay fan on pierce count post.
Mach seems to observe the p.... when not using the thc function but not with it, is that correct?
Matt
-
The code for a pause would be...
G4 PX
X would be in either seconds or miliseconds depending on how you have mach3 set. On the general config screen you can select seconds or miliseconds. If you select miliseconds in mach then use seconds in you code, the effect will be almost like there is no delay.
That said, I've noticed the same behavior where the G4PX is completely ignored. It only happens on the first G4 in the program, but it doesn't happen on every program. It's odd because I use the same Sheetcam post to generate all code.
-
Beat me to it about the G4 and the delay either being in ms or s :)
Matt - is that just your memory - or have you actually missed out the G4 in your code.
Also - what do you have in your M3 macro?
This is pretty standard floating head IHS by homing stuff and should work fine. Can't comment on the behaviour of your particular THC as I've never used that one.
Ian
-
Afternoon,
I have just changed my plasma cutter to one which has a arc ok signal on it, it seems to activate this signal as soon as the arc has transferred not once the plate has been penetrated, this means that when i have the thc mode set on in mach as soon as the arc transfers the machine starts to move but the arc hasnt penetrated the plate, i need to get some kind of a pause in there so i modified my sheetcam post processor to have a pause at the right time but mach seems to ignore it and as soon as it sees the arc ok signal it goes to the next line which has a machine move in it, any ideas why this happens? or if not any ideas on how i can get round it??
Help would be greatly appreciated
Matt
Matt I may be wrong(I'm not at my machine) but I think there is a setting inside Sheetcam for pierce delay when setting up your your torch. It gets written into the gcode automattically. I'll take a look over the weekend
Mike
-
Hi,
Mach seems t ignore the pierce delay that you set in sheetcam when you use the thc function to recognise the arc ok signal before moving, is there another way of using the signal?? I have simply instaled mach 3 plasma and when i press the thc button on the signal is used when it is off the pierce delay is used.
Im not totally sure if there is a G4 in my code but all i know is the delay works with the thc button off and is ignored with it on, when i get a moment i will try using a different post or something.
Matt
-
Hi Matt - after having a play, I think you're absolutely right - in a way...
It seems that regarless of whether you're using THC, Mach executes the M3 and THEN executes the G4 dwell. However, IF you're using THC Mach will THEN wait, AFTER the dwell for ArcOK (if it has to). The reason I (and I suspect a lot of others) have never noticed this is that IF the M3 is very quick in turning on your torch AND the ArcOK is very quick and between them the time is MUCH shorter than the dwell, then everything APPEARS to work as it should. BUT - IF the time it takes to turn on the torch and to return the ArcOK signal is pretty close to the G4 dwell time OR worse LONGER than the G4 dwell then there is effectively NO delay. i.e. it's allready done the G4 BEFORE it even got the ArcOK.
This IMHO is clearly wrong and I would regard it as a Mach bug. What Mach SHOULD do of course is execute the M3 and then wait for ArcOK BEFORE it does the G4 dwell.
In reality, the only gcode commands that Mach will not execute if ArcOK is not there (and THC is on) are MOVEMENT commands.
Hope that all makes sense. You can test the above out by doing a "silly" long G4 and you'll see it IS being executed and not skipped.
One make do solution I guess is to add the time it takes the torch to come on + the time it takes it raise ArcOK + the actual pierce delay you need and code G4 for that. Alternatively I guess some suplemental VB in M3 to do a wait for ArcOK - something like:
'untested and crude - i.e. infinite loop if ArcOK never comes.
DoSpinCW
while not isActive(THCON) 'yes annoying isn't it, Mach's signal name for ArcOK is THCON for gawds sake.
wend
Incidentally, a tip: I don't use DoSpinCW - it's slooooooooow, instead I use activateSignal(OUTPUT1) - it's waaaaaay faster to respond.
Ian
-
Matt - don't know if you're still interested in this but I asked Brian if he thought it should be corrected and it seems he doesn't... so the test for ArcOK in the m3 macro appears to be the only way to do this.
Ian
-
Ian,
Thanks for your efforts, i will take your m3 macro addition and try it out, i was hoping for a simple fire the torch, wait for the arc to transfer and then pause for the pierce delay interval then move, hopefully adapting the m3 macro will sort this out.
Thanks again
Matt
-
This is how I do it...
Do While Not isActive(THCON)
x = x + 1
sleep 1000
If x = 3 then
MsgBox("OK To Move Timed Out")
code "M30"
Exit Do
End If
Loop
This will stall until either a good arc is seen or the loop times out. I have it set for 3 seconds.
-
Unfortunately this doesn't improve the situation. No offence intended but it potentially makes it worse.
Just as one example, compare the resultant pierce delay if arcok activates just before the sleep, with what it would be if arcok activates just a few microseconds later after the sleep begins.
Ian
EDIT: I've just thought of another issue about this whole problem but I'll check it out first.
-
Morning,
I tried the modification to the m3 macro and it seems to work for me............
Matt
-
which one Matt?
-
Do While Not isActive(THCON)
x = x + 1
sleep 1000
If x = 3 then
MsgBox("OK To Move Timed Out")
code "M30"
Exit Do
End If
Loop
-
I can see how it could get trapped after the sleep and before the x comparison if x = 3. It's probably never been an issue because it has never taken longer than 3 seconds to light the arc. If it takes longer than that, there is a problem and the arc is not going to light at all, which times it out. If THCON goes on before the sleep and x < 3, you would just see a slightly longer delay worse case. That could be happening, but I haven't really noticed it. Changing it to this should solve both...
Do While Not isActive(THCON)
x = x + 1
sleep 1
If x = 3000 then
MsgBox("OK To Move Timed Out")
code "M30"
Exit Do
End If
Loop
Virtually removes any possible delay where arc lights before the sleep and x < 3000 and reduces the gap to where it could get stuck between sleep and x = 3000 to only 1ms. Still a remote chance it could happen. You could bump the time to 5000. If the arc doesn't light in 5000ms you can rest assured that it's not going to light for some reason.
You could remove the sleep completely, but that you'd have to experiment with the timeout number to get a suitable timeout. I think when I tried it I was using something like 12000.
I actually use this in a separate macro that I insert just after the M3.
-
Hi, I am setting up my cnc plasma table, everything ok except the trigger switching is reversed ie it comes on when it should be off and goes off when it should be on ,any help please,