Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Davek0974 on August 13, 2014, 10:35:26 AM
-
I am using my plasma torch to make marks for drilling on a job, it has 6 marks on it. It works very well at low power setting and a 0.1s pierce delay. After the piercings I have added a pause in the code so I can up the power and make the following cuts as normal.
However, at the start of each run, the first pierce is always longer, maybe three or four times longer than the rest.
Is there any reason for this in Mach3, I have checked the code and each pierce is identical in duration?
Maybe a setting needs tweaking?
Thanks
-
No-one else notice this??
-
Can't say I've seen this - post your gcode and the contents of your M3 and M5 macros.
-
Thanks
Files below
Dave
-
Nope - they're consistent here. Not accurate - but consistent.
I've never found G4 to be particularly accurate with small values. Your 0.1s actually gives 0.73s. HOWEVER - some of that is down to the delay of executing M3 and M5 because your M3 uses doSpinCW and presumably your M5 uses doSpinStop (you posted M4 rather than M5 so that's a guess). I replace these with direct signal activation/deactivation which makes the macros faster. That won't do anything for inconsistency though - don't know why your seeing that.
-
Hmm, that's odd then,
Where or how does the direct activation code go, is it just placed into the M3\4\5 macros or somewhere else?
Is it just a matter of changing the macro's to this style --- ActivateSignal(Output1) & DeActivateSignal(Output1) ????
I will also take the THC completely out of the loop, just in case that is causing a variation and try that.
Would make sense to replace the M codes with direct signals if you could give a little guidance please.
Many thanks for your time
-
Is it just a matter of changing the macro's to this style --- ActivateSignal(Output1) & DeActivateSignal(Output1) ????
You got it.
-
Thanks, thats a lot snappier now :)
As it means my code is all wrong now (pierce too short) was there a known delay inherent in the M3\4\5 macros that I could simply add to my code or was it just a code delay of unknown length???
Dave
-
Running your code here, the time between the M3 activating and the M5 deactivating is:
1.73 sec using doSpinCW and doSpinStop and 0.32 sec using activate/deativate.
-
Thanks for the info
-
This is not working for some reason!!
Just spent an hour recalibrating my pierce times to take into account the faster response of Mach without the DoSpin commands 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 longer!.
Need help now please?????
-
This is not working for some reason!!
Just spent an hour recalibrating my pierce times to take into account the faster response of Mach without the DoSpin commands 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 longer!.
Maybe the 0.1s delay is just silly and the consecutive pierces are behaving as they should BUT the first pierce is still way too long????
I could try upping the 0.1s to 0.4 or 0.5 maybe and try that but then the first one will still be long.
Need help now please?????
-
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.
-
This seems to be related...
http://www.machsupport.com/forum/index.php?topic=17435.5;wap2 (http://www.machsupport.com/forum/index.php?topic=17435.5;wap2)
-
Anyone know of a way that the Arc-Ok signal can freak Mach out?
Seems like its missing lines of gcode but dont know why, how can it stop the torch from lifting at the end of a cut?
-
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.
-
Don't worry, I'm ditching this THC and ordering an MP3000 from CandCNC.
-
This seems to be related...
http://www.machsupport.com/forum/index.php?topic=17435.5;wap2 (http://www.machsupport.com/forum/index.php?topic=17435.5;wap2)
Not just related - it seems to me to pretty much cover your issue.
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.
As you say - this is incorrect behaviour of your THC. I can only suggest you take this up with Proma.
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.
Ark-OK should be established by a THC when CURRENT is detected in the CUTTING arc as opposed to current in the pilot arc. i.e. when the pilot arc actually transfers to a cutting arc.
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.
This is to be expected. It is not so much the cause of your problems but a symptom of them. Once you have pierced the system MUST start cutting otherwise the arc will start to deviate to find the edge of the pierce hole. Eventually it will not be able to deviate far enough as it widens the hole and will therefore not be conductive. Current ceases and so the torch flips back to pilot. The hole is now too wide to allow transfer so the pilot will remain until timeout.
EDIT: you just posted at the same time - but I'd written it so I'll leave it for your interest.
-
Thanks Stirling, hopefully, using a more recognised and supported THC like the MP3000 will give me a lot less grief, I think it will.
Dave
-
Well, a new THC did not have any effect, the first pierce is still longer.
On a drill op it's the difference between a small peck with the torch or a complete pierce.
This is with an MP3000 from CandCNC.
Arc-ok does not come into it as there is no torch movement, pierce delay is set to 0
The torch does not drop from pierce height, it's simply M3 then M5.
-
Time to post your xml, gcode (shortest sample that shows the problem), M3 & M5 macros and Mach version I think Dave.
-
Time to post your xml, gcode (shortest sample that shows the problem), M3 & M5 macros and Mach version I think Dave.
Thanks but they are already up, post 4 on page 1.
I've tried altering the macros to activate signal instead of do spin but that seemed to upset other parts of the code and wierd things started happening like dragging the torch because it missed the z retract.
I have now changed the THC to a more professional system so it's not that.
I know it's not critical but it's damn annoying, there must be a reason.
-
The code you posted in #5 is NOT the same as you describe in post #19 and you're wrong (IMHO) to dismiss arcok as being of no relevance. You didn't post M5 and you've changed them to who knows what now. You haven't said which Mach version you're using. I'll leave you to it
-
What?
I can't see ANY posts from arcok in this thread, how did I dismiss anyone as being irrelevant?
The first part of that code is the drill op that highlights the issue.
I will post a cutdown version in a minute that holds just the drill op.
I am on v067 of mach and the m03/4/5 macros are now back to bog-standard dospin ones, as I said I tried the activate output version but did not work so reverted back to the factory codes.
I can't see how I've been offensive or dismissive to anyone in this or other threads, I'm just a frustrated user that's all, my apologies if it seems I have been short with anyone.
-
Code attached for the drill op only, 1st strike is always longer by about 4-5 times the duration
As i said, M macros are all back to standard and I'm running V067 as its the only one recommended by CandCNC.
-
What?
I can't see ANY posts from arcok in this thread, how did I dismiss anyone as being irrelevant?
...
...
I can't see how I've been offensive or dismissive to anyone in this or other threads, I'm just a frustrated user that's all, my apologies if it seems I have been short with anyone.
;D ;D ;D
Have you had your coffee yet this morning Dave? "arcok" is not a person - it's a signal from your plasma cutter. I was commenting on your statement...
Arc-ok does not come into it as there is no torch movement
-
D'oh!, what an idiot :)
Yes I had coffee, maybe not enough;)
Anyways, I still don't see what arc ok can do if the torch just fires and stops, I thought arc ok would only be relevant before a torch move?
This new system is a proper current monitoring arc ok signal so should be accurate, it's passed all the tests recommended by CandCNC anyway.
If there is some test I can do to narrow things down I will do it, but the delay seems to be the same if I'm doing a series of quick bursts or a series of long cuts, the first activation is longer.
Thanks
-
OK - take a look at your 6 "drills" in the code you just posted. It's not only the first that takes longer it's also the 5th...
-
Is it the F1000 at the end of the line between the m3 & m05 ??
I guessed that was just setting a feed rate but as there was no feed, it did nothing?
If it's not that then what?
-
Is it the F1000 at the end of the line between the m3 & m05 ??
It is.
I guessed that was just setting a feed rate but as there was no feed, it did nothing?
It takes time for the interpreter to process the line. There's more to interpret so it takes longer - doesn't matter that no movement results (in this case because of the axis already being at z=3).
So what's the result of making them all the same? Do you get consistent timings now?
Now back to arcok. It's important REGARDLESS of whether you're using THC or not.
Consider your...
G00 Z3.0000
M03
G01 Z3.0000 F1000.0
M05
(With or without the in-line feedrate). The TIME your torch is actually cutting (piercing, "drill marking", whatever) is totally in the lap of the gods. You have NO idea when it transfers from pilot to cut arc. You're just hoping/assuming that it does what you want. You may want to give your SCAM POST a lookat.
-
Arcok, who's that? ;)
Ok, I'm hoping to get some time tomorrow to pull that code apart and do some tests.
If it went
M03
M05
I guess that is the absolute shortest bite it can give?
Is there a delay in going from pilot to main arc?
I mean, if the metal is clean, the torch is at pierce height and then fired, surely the delay is microscopic and of little relevance. Does it not move to main arc as soon as the pilot arc touches the sheet and current starts to flow?
If the cycle time is so short, does it even get a chance to transfer to main arc?
Will do some tests on this.
Thanks
-
If it went
M03
M05
I guess that is the absolute shortest bite it can give?
Whatever a "bite" is.
Is there a delay in going from pilot to main arc?
I mean, if the metal is clean, the torch is at pierce height and then fired, surely the delay is microscopic and of little relevance. Does it not move to main arc as soon as the pilot arc touches the sheet and current starts to flow?
Your...
M3
M5
keeps the torch on signal active for 0.1 seconds (here). So let's look at what you "hope" will happen in that 1/10th of a second.
Your THC see's the (torch on) signal go active, it turns on the relay (so mechanical), the plasma cutter fires the pilot arc and opens the solenoid valve (mechanical again and even slower than a relay) that allows the air to flow. The air blows the pilot arc out of the nozzle, the arc touches the metal, the plasma cutter detects the circuit and switches from pilot to cutting arc, only NOW does it even START to "bite" PLUS "some" time to "bite" to whatever extent you'd like it to. What do you reckon? - all in a tenth of a second?
So how the hell long does all this nonesense REALLY take?
The answer is, you don't give a toss. You WAIT for arcok - that's when it's just started to "bite". That's why the nice people who make THCs (or THC interfaces) give you an arcok signal - because it's really useful. Once you determine your timings from this you're home and dry.
(and DON'T call me Shirley)
-
Very interesting stuff, so without an arcok system, a straight M03-M05 should be so fast as to not give any action at all? Probably just make a relay quiver somewhere.
Ok, so we switch on, wait for arcok, then switch off, is that the correct internal sequence?
Inside Mach there is a loop following the M03 that waits to see an arcok signal BEFORE processing the next command which in my case is M05, but I guess could just as easily be a move etc?
If that is so, then yes there is a long loop involved in getting that signal, in my THC it's created from a Hall effect trigger on the plasma ground lead so the current has to build to trigger point before it's sent, and as you said there are gas valves, relays, even the blowback start cartridge in the torch.
This all explains why a zero pierce delay is never really zero I guess.
Thanks for all this by the way, it's much appreciated.
-
The correct sequence is to switch on, wait for arcok, introduce any required delay then do whatever... which may be drop from pierce to cut height as in a "regular" cutting process or in your "drill" marking - switch off.
However - there's a Mach bug which makes this more tedious to implement than needs be. For a discussion of this, see the thread you linked to earlier in reply 13.
-
Thanks, just re-read that thread again.
So, if I were to set a realistic delay (longer than the electromechanical delays in the system combined) say 1sec then I would likely see stable timings in the G4 but because my zero delay request is far shorter than the inherent delays (allied with the mach bug) then I am seeing seemingly random timings possibly caused by the arc ok arriving later for the first fire or some other micro variable delay?
I think that makes sense.?
I see you had some vb code for the M3 that might help but, as you said then, it could cause cause an infinite loop if the arc never arrives which is possible so I think I will leave that alone for the present.
I'll have a play as soon as I get some quiet time.
-
Results are in.
made a job that was just 4 pierces in a row, first test was no pierce delay
This set the code to a straight M03/Mo5 and I get one good mark and three where there was not enough loop time to actually fire the torch.
second test i set a 0.5s delay between each M03/M05
This time I got one deeper mark and three good ones
reduced to 0.4s delay
Result was slightly less depth than the previous test.
Then i realised the there was another factor at play - after the first pierce the torch air was still on its post-flow stage
The next test i made each pierce one at a time, allowing the air flow to stop between each firing
result - 4 perfectly equal marks.
Conclusion - there is a cumulative loop delay required of about 0.4s to get a reliable arc start on the torch PLUS if the air is still flowing then the pierces WILL be quicker.
Summary - Not a lot i can do about that really, there is no way to stop the post-flow and no way to pre-trigger the air flow so the 1st pierce will always be longer.
Damn interesting test though and thanks for all the help.
-
My conclusion only applies to using the torch as a drill though, where there is no movement code following the M03, for normal cutting it will not fail to fire but it wll give a longer pierce dwell on the first cut providing the cuts are close enough together to be started with post-flow still running.
-
None of this would matter if you base your timings on arcok. I know I'm sounding like a scratched record but there it is.
-
None of this would matter if you base your timings on arcok. I know I'm sounding like a scratched record but there it is.
Yes possibly but what if the arcok is delayed on the first pierce but arrives faster when the post-flow air is on?
Surely the result would be as it is now - were waiting for a signal that arrives at varying time periods??
No real way to tell without some serious measuring equipment I think.
But I do now know that Mach IS consistent and that the pierces WILL vary if post flow is on.
Without a method of triggering the air earlier I doubt there's much can be done, but at least I have a reason now.
Thanks for all the discussion.
-
Yes possibly but what if the arcok is delayed on the first pierce but arrives faster when the post-flow air is on?
Surely the result would be as it is now - were waiting for a signal that arrives at varying time periods??
AAAAAGGGGGHHHHH!!!! ;D
Maybe I'm just crap at getting my point over but here's one last shot then I'll get back in my box.
It's the LENGTH of time the cutting arc is ON that matters NOT when it STARTS. arcok signals the time cutting STARTS. It matters not one jot If it takes one second or half a second to establish arcok. It's ONLY when you get arcok that metal is starting to melt.
-
:) :)
Ok, I think I see it now, nothing happens until we get arcok.
Now, looking at the issue then, what could cause the variation?
There definitely IS a variation and the only difference is the post-flow air being on or off.
The response is the difference between getting a solid pulse of the torch OR not getting enough signal to even trigger the torch.
Hang on a minute, looking at that last sentence, i was not even getting an arc on the latter part of that test as mach was not triggering the relays long enough to do it - straight M03-M05 is too fast UNLESS its the first trigger is with air OFF.
Now i'm really confused ;)
-
Now I KNOW you're taking the piss.
-
Sorry but I'm not, obviously I am not seeing the point and I apologise for having a high specific gravity ;)
I ran a test - four pierces in a row, no delay between M03 & M05
The first pierce worked perfectly, the last ones did not even get to fire the torch as the signal duration was too short, I'm not even sure if the relay clicked.
Arcok could not even come into the equation for the last ones as the torch did not fire.
Please explain the reasoning.
-
Going back a few posts, there was mention of a small bug in Mach that made waiting for arcok difficult, if this is the point I am missing then I get it - it does not wait as it should.
I'm probably still wrong. :(
So......why is the first one always longer?
-
Going back a few posts, there was mention of a small bug in Mach that made waiting for arcok difficult, if this is the point I am missing then I get it - it does not wait as it should.
hallelujah - (actually no one said difficult - you made that up).
So now go back and READ this thread again - or at least posts #31 to #39. Notice post #37 ?
Then this time, read ALL (not just the first page) of the thread YOU linked to in post #13 and maybe look at my first comment about that link in post #17.
-
***Insert facepalm smiley here***
D'oh!
Right, I'm on the ball now, i think :)
To be honest, in that linked thread, it comes up as an archived one i think in a format thats hard to follow, i didnt even notice there was more than one page before!
Anyway, is it worth my trying this for fun or has it later been proved fruitless....
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
Inside M3 after the DoSpin()
Also, once its configured, is ArcOk ALWAYS present or does it disappear when THC is turned off?
Any views or should i just go back to bed;)
-
Well, I've tried it and yes, consistency CAN be achieved if you wait for the ArcOk signal (if only someone had said that earlier ;) ;) )
Using the code above inside the M03 macro means that even without a G04 P0.?? dwell, you can mark predictable points on the sheet without piercing through.
But as suspected, this now means you can't run a job if the torch is turned off - I do this a lot with a new job file to test the layout etc, just a dummy run through.
Also when using the CandCNC MP3000 stuff you can have a tool defined as no THC, this also upsets the action of this code.
Here's what i would do if only i knew how..
Add an LED and screen button titled "Dry Run" or something similar, the button would flip the LED on or off.
Inside the M03 macro the status of this LED would be tested and if off then none of the M03 code would run - no torch fire etc.
If on then the M03 would act as it is at present - fire the torch then wait etc.
Adding the button and LED is OK but how to toggle the LED state is unknown by me at present.
Anyone care to chip in with some code? :)
Of course, if anyone has a better version then I'd love to see it but as it is i think the code above fixes 99% of the issue.
-
Got it, I think...
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.
I'm not sure of any pitfalls in this code but it seems to do what i want.
Any views?
-
So progress...<phew>
If it's all working as you'd like then great - however, instead of your LED monitoring etc. maybe you could have just put a block delete on your M3 calls? Then just turn block delete on when you want to dry run?
-
I'm all for trying different ways, how does a block delete work?
I gather that would then me reloading the code for the real run?
Interesting stuff.
Can you see any issues with this M03 edit??
Thanks
-
Ignore my last post, too late to edit it now.
I see block delete is built in function triggered by a line starting with "/"
It was the title "block delete" which made me think it altered the code, however the code my post outputs has line numbers and I have no idea how to get the / code in front of them - from what I've read it must be the first character on a line.
Anyway, my method works ok, at least the option part, as yo the rest of the macro code, time will tell I guess.
-
Question:-
If "ArcOk" is configured in ports & pins and the signal is being sent to Mach from the plasma system, is it ALWAYS present inside Mach OR does it get turned off when "THC Off" is selected on screen????
I'm just thinking through traps that might stop my revised M03 macro from working and not having permanent access to "ArcOk" would be one of them, this would cause a time-out and stop the job from being able to run.
-
From a reply by Tom at CandCNC it seems that when THC is turned off in Mach, all three inputs - ArcOk, Up & Down are ignored by Mach.
That means I cannot run code without THC using my edited M03 macro (above).
Oh well, it's better as it is, at least I get predictable pierce timings now.
-
Well I thought I'd leave you to just try it but anyway...
You've misconstrued what Tom has told you. (not like you Dave >:D)
ArcOK, Up and Down ARE indeed ignored by Mach's THC system when Mach's THC is turned off. That however does NOT mean they aren't present. Just because Mach's internal THC ignores them doesn't mean your macro will.
As long as Tom's THC still send the signals even when Mach's THC is off (which it darn well should) then you're fine.
-
Aww c'mon, that answer was ambiguous and vague, even on a good day ;)
I saw the point that mach ignores the inputs if THC is off and took 'mach' as being the whole software system, easy mistake.
Anyways, thanks again for your patience and the reply.
That little bit of code in the M03 macro makes a massive amount of difference, at least in my impression of the whole system. Have been running stuff all afternoon and it's performing drill marks, cuts and pierces perfectly :)
Dave
-
;)