I have an issue where the pierce delay in Mach3 was much longer than it should be plus the first pierce is longer than consecutive ones.
I fixed the long delay by changing the DoSpin commands that fire the torch to ActivatSignal() commands which made things much snappier.
Then i spent an hour recalibrating my pierce times and entering that data into my tool table.
BUT when I put the first simple job on with only two 0.1s pierce delays, the first one works perfectly and the second one is ignored and the torch fires and starts moving immediately, ignoring the delay completely and piercing on the run.
Useless.
It is the same issue as before, only quicker - the first pierce is still longer!.
Someone else MUST have had this issue on a plasma surely?
Maybe 0.1s delay is just silly and the consecutive pierces are behaving normally BUT the first one is way too long???
1st pierce is longer...
MORE INFORMATION.....
Been thinking all night and just did a test,
this issue is related to the THC somehow, maybe the ArcOk signal?
With THC OFF, my system works ok, turn THC ON and it not only has a longer first pierce/shorter second one BUT also skips the torch-lift at the end of the first cut so it drags the torch along the plate triggering an E-stop.
This is all related to changing the DoSpin commands to ActivateSignal so what is going on??
Obviously i can replace the DoSpin commands but thats not fixing the issue.
Been thinking all night and just did a test,
this issue is related to the THC somehow, maybe the ArcOk signal?
With THC OFF, my system works ok, turn THC ON and it not only has a longer first pierce/shorter second one BUT also skips the torch-lift at the end of the first cut so it drags the torch along the plate triggering an E-stop.
This is all related to changing the DoSpin commands to ActivateSignal so what is going on??
Obviously i can replace the DoSpin commands but thats not fixing the issue.
This seems to be related....
http://www.machsupport.com/forum/index. ... 435.5;wap2
http://www.machsupport.com/forum/index. ... 435.5;wap2
THIS IS DRIVING ME INSANE NOW 
I looked through the Proma leaflet, and it clearly states that NO output will be energised when only the pilot-arc is struck i.e. firing in air.
So i threw in some used consumables, switched to the diag page in Mach and fired the torch in air, sure enough I was getting an Arc-Ok signal, this is WRONG and possibly what is messing up Mach3.
So I noted the voltage displayed when the torch was firing in air (150v) and turned the HV setting in the Proma box down to 140v. This is higher than my highest cutting voltage BUT lower than the pilot voltage as I presume this is how Proma detects Arc-Ok.
But now when I try to run code, the arc will fire but as the torch pierces quickly on the 1.5mm test sheet, it then reverts to a pilot arc before Mach has time to drop the torch to cut height and start moving.
It's a no-win situation, I either have the long, unreliable pierce delays by using DoSpin() and setting the Proma back to instant arc-ok OR have fast on off with activatesignal() and a sensible arc-ok signal but not be able to cut
Anyone please got any ideas?
Yes I do know I can put it back how it was but long pierces on thin metals are bad for various reasons.
I looked through the Proma leaflet, and it clearly states that NO output will be energised when only the pilot-arc is struck i.e. firing in air.
So i threw in some used consumables, switched to the diag page in Mach and fired the torch in air, sure enough I was getting an Arc-Ok signal, this is WRONG and possibly what is messing up Mach3.
So I noted the voltage displayed when the torch was firing in air (150v) and turned the HV setting in the Proma box down to 140v. This is higher than my highest cutting voltage BUT lower than the pilot voltage as I presume this is how Proma detects Arc-Ok.
But now when I try to run code, the arc will fire but as the torch pierces quickly on the 1.5mm test sheet, it then reverts to a pilot arc before Mach has time to drop the torch to cut height and start moving.
It's a no-win situation, I either have the long, unreliable pierce delays by using DoSpin() and setting the Proma back to instant arc-ok OR have fast on off with activatesignal() and a sensible arc-ok signal but not be able to cut
Anyone please got any ideas?
Yes I do know I can put it back how it was but long pierces on thin metals are bad for various reasons.
I've had two completely different plasma systems with the same power unit. Hypertherm 1650.
Rutex was the first THC I used that was totally automatic. I did not have any control over the pierce other than delay. Sheet cam post was modified so that the first pierce would subtract time and the others were unchanged if I remember correctly.
When I moved to CandCNC THC I now have full control over the pierce like a real machine and have, and full control over the THC. The two setups are generations apart and Toms stuff works flawless.
That's not to say there wasn't a few hick-ups here an there, and the learning curve is steep with CNC plasma. So much to learn....!
With that being said the first pierce with both setups act the same. It is slightly longer, I'd say mine is about 350 milliseconds not quite a half a second.
It's a Hypertherm thing I believe. We're going back years now, but I seem to remember talking to Hyperthem about it....
BUT.... with Tom's equipment ( for plasma cutting ) it gives me no ill affect. So what if the first pierce is a little longer. It falls within the lead in and TH Delay which we have full control over; it does not effect anything. It is easily worked around or isn't really noticed except for watching the first pierce..
I may be off base with this reply, most of the time I am on forums, but I seem to remember you talking about this for a while..... Sorry for the post if I'm out of place...
AJ
ajclay@cox.net
Rutex was the first THC I used that was totally automatic. I did not have any control over the pierce other than delay. Sheet cam post was modified so that the first pierce would subtract time and the others were unchanged if I remember correctly.
When I moved to CandCNC THC I now have full control over the pierce like a real machine and have, and full control over the THC. The two setups are generations apart and Toms stuff works flawless.
That's not to say there wasn't a few hick-ups here an there, and the learning curve is steep with CNC plasma. So much to learn....!
With that being said the first pierce with both setups act the same. It is slightly longer, I'd say mine is about 350 milliseconds not quite a half a second.
It's a Hypertherm thing I believe. We're going back years now, but I seem to remember talking to Hyperthem about it....
BUT.... with Tom's equipment ( for plasma cutting ) it gives me no ill affect. So what if the first pierce is a little longer. It falls within the lead in and TH Delay which we have full control over; it does not effect anything. It is easily worked around or isn't really noticed except for watching the first pierce..
I may be off base with this reply, most of the time I am on forums, but I seem to remember you talking about this for a while..... Sorry for the post if I'm out of place...
AJ
ajclay@cox.net
It's mostly for when I use the torch to make marks for later drilling, I get one great big fat divot or hole and the the rest are very nice and neat marks.
On a plain cut all it means is it's slightly harder to set the pierce as you vae to make to consecutive cuts and look at the second cut for the correct pierce delay time.
It just seems odd that there is any difference at all.
On a plain cut all it means is it's slightly harder to set the pierce as you vae to make to consecutive cuts and look at the second cut for the correct pierce delay time.
It just seems odd that there is any difference at all.
I'm not a know it all by any means but usually as with everything, it's more complicated than we believe. It's not just one thing. Mach moves motors and puts torch in place send info to the Hypertherm unit, it takes time to send the info that the arc is established and OK to move more time for mach to process the received info, then it processes that info and sends the commands to the servos to get the motors moving...
Why it's longer on just the first, I don't know.... It's just a lot deeper than I want to go to solve the problem if it is even possible.
My experience, it's just not that much difference. Try going to a smaller torch tip so it will take longer to pierce and not effect the end result as much.
Not telling you what to do, but when I use the torch to mark for drilling holes, I'll make the pierce mark as small as possible. Just a few thousands larger than the kerf dia for the tip being used. Then there is less carborrazation or hard metal to drill through.
If it's something that has to be accurate in location, then that may not be the best procedure to do anyway.
Also if the drill being used is close to the pierce size, well I'd have to re-think the procedure and go to a different process... Replace the torch with a drill or go to a milling machine... just thinking out loud... More accurate in either case...
Hope I've helped in some small way...
Aj
Why it's longer on just the first, I don't know.... It's just a lot deeper than I want to go to solve the problem if it is even possible.
My experience, it's just not that much difference. Try going to a smaller torch tip so it will take longer to pierce and not effect the end result as much.
Not telling you what to do, but when I use the torch to mark for drilling holes, I'll make the pierce mark as small as possible. Just a few thousands larger than the kerf dia for the tip being used. Then there is less carborrazation or hard metal to drill through.
If it's something that has to be accurate in location, then that may not be the best procedure to do anyway.
Also if the drill being used is close to the pierce size, well I'd have to re-think the procedure and go to a different process... Replace the torch with a drill or go to a milling machine... just thinking out loud... More accurate in either case...
Hope I've helped in some small way...
Aj
I tried the hole marking as well earlier this year, I am using a powermax 45 I was getting the same thing happening on the 1st pierce when using the hole mark, I don't notice it on normal cutting though.
I did ask Tom at Candcnc about it he said 'it has to do with the fact that the cycle is longer if the purge air is not on already'
Not sure what the answer is, he may have found a way around it by now I'm not sure I left it since then, I notice he brought out a new post a few days ago, I briefly tried that but there seemed to be a problem (maybe on my setup) so left that well alone for now as well.
Sean
I did ask Tom at Candcnc about it he said 'it has to do with the fact that the cycle is longer if the purge air is not on already'
Not sure what the answer is, he may have found a way around it by now I'm not sure I left it since then, I notice he brought out a new post a few days ago, I briefly tried that but there seemed to be a problem (maybe on my setup) so left that well alone for now as well.
Sean
- Attachments
-
- holemark.jpg (157.27 KiB) Viewed 8962 times
If you're not using 100% of the metal, just have it pierce just outside the part in a dead area.. Or a scrap piece as you mentioned....
Wow, that's a simple solution...
Years ago I was using M-codes to turn on / off my torch with relays and there was a delay because of that... All the pierce times I had to bias longer in sheetcam to make them come out right... So it was easy to just shorten the first pierce in the post..
What Sean mentioned sounds familiar about the cycle time with the air purge... I just cant remember the details.. Too many beers, to many years...
Aj
Wow, that's a simple solution...
Years ago I was using M-codes to turn on / off my torch with relays and there was a delay because of that... All the pierce times I had to bias longer in sheetcam to make them come out right... So it was easy to just shorten the first pierce in the post..
What Sean mentioned sounds familiar about the cycle time with the air purge... I just cant remember the details.. Too many beers, to many years...
Aj
Ok finally getting somewhere I think.
This appears to be a known issue in Mach3, a minor bug maybe. It's the way it handles G4 delays with the arc-ok signal.
If the G4 is zero or shorter than the time it takes to get arc-ok including all the relays and air vales in the system, then you can get random length timings as I am seeing.
If the G4 is longer than these time delays in total then you get the G4 delay as requested.
I'm going to do some testing but it's a known issue at least.
This appears to be a known issue in Mach3, a minor bug maybe. It's the way it handles G4 delays with the arc-ok signal.
If the G4 is zero or shorter than the time it takes to get arc-ok including all the relays and air vales in the system, then you can get random length timings as I am seeing.
If the G4 is longer than these time delays in total then you get the G4 delay as requested.
I'm going to do some testing but it's a known issue at least.
Ok to put a cap on this for the future, there is a known small bug in Mach BUT the main cause is (as mentioned by SeanP above) is because the torch fires a lot quicker if the post-flow air is still running after the first pierce.
I don't know if it's a Hypertherm thing or just general plasma behaviour but the first pierce from the torch when the air is off is always slower/longer.
I can get my sheetcam plasma drill tool to run so fast by setting it to zero pierce delay that the first fire works as expected but subsequent ones do not even have time to energise the torch!
Clearly that's no good so I've set a delay of 0.5s which makes the first one about 1.5s and the rest about 1s.
So there's no solution but at least I know why now
I don't know if it's a Hypertherm thing or just general plasma behaviour but the first pierce from the torch when the air is off is always slower/longer.
I can get my sheetcam plasma drill tool to run so fast by setting it to zero pierce delay that the first fire works as expected but subsequent ones do not even have time to energise the torch!
Clearly that's no good so I've set a delay of 0.5s which makes the first one about 1.5s and the rest about 1s.
So there's no solution but at least I know why now
Update...
There is a solution to this issue, it's caused by the small bug in Mach where it does not handle the Arc-Ok signal 100%
I have modified my M3 macro as below and also added a button and LED to the screen to enable me to do a dry run as the M3 mod blocks this.
Put a VB button on the screen titled "Dry Run" or similar and an LED, i called mine 2244, in the button code...
If GetUserLed(2244) then
setuserled(2244,0)
else
setuserled(2244,1)
end if
That toggles the Led on and off
In the M03 macro:-
If getuserled(2244)=0 then
dospincw()
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
end if
That stops all action from M03 if the "Dry Run" LED is on, or lets it proceed as normal if its not.
What the code does is stops Mach starting the pierce delay timer before a good Arc-Ok signal is received from the THC or plasma unit. Now it does not matter if purge air is flowing or not, the delay will wait for the Arc-Ok signal and then start counting.
It works and it works very well.
There is a solution to this issue, it's caused by the small bug in Mach where it does not handle the Arc-Ok signal 100%
I have modified my M3 macro as below and also added a button and LED to the screen to enable me to do a dry run as the M3 mod blocks this.
Put a VB button on the screen titled "Dry Run" or similar and an LED, i called mine 2244, in the button code...
If GetUserLed(2244) then
setuserled(2244,0)
else
setuserled(2244,1)
end if
That toggles the Led on and off
In the M03 macro:-
If getuserled(2244)=0 then
dospincw()
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
end if
That stops all action from M03 if the "Dry Run" LED is on, or lets it proceed as normal if its not.
What the code does is stops Mach starting the pierce delay timer before a good Arc-Ok signal is received from the THC or plasma unit. Now it does not matter if purge air is flowing or not, the delay will wait for the Arc-Ok signal and then start counting.
It works and it works very well.