Another plasma component...

More
27 Jul 2019 08:26 - 27 Jul 2019 08:26 #140726 by thefabricator03

but how does linuxcnc know when to turn off the torch early before M5? (before the overcut)


Not sure, From my experience it does not turn off. The point of over cut is to continue cutting past the start point.

The problem we have been having is the torch is staying on when the delay is set and it is still firing when the z axis is retracting.
Last edit: 27 Jul 2019 08:26 by thefabricator03.

Please Log in or Create an account to join the conversation.

More
27 Jul 2019 08:39 #140727 by rodw
Replied by rodw on topic Another plasma component...

but how does linuxcnc know when to turn off the torch early before M5? (before the overcut)


I think there are 2 issues being discussed here. One is the delay at the end of a cut before turning of the torch. That can be done in HAL.
The other is what thefabricator is doing and turn the torch off while still moving.

As far as knowing when we get to the end of the cut, there is a pin motion.distance−to−go but I think it is just for the current line segment. I have not played with halscope and a sim to see what it really does.

Please Log in or Create an account to join the conversation.

More
27 Jul 2019 08:54 - 27 Jul 2019 10:03 #140728 by phillc54
The online version of PlasmaC has a problem where the Z axis retracts before the torch off delay has completed.

A version I completed this afternoon uses M62 P3 to turn the torch off and M63 to enable turning it back on. This version has not been pushed yet.
Last edit: 27 Jul 2019 10:03 by phillc54. Reason: Wrong P#

Please Log in or Create an account to join the conversation.

More
27 Jul 2019 09:14 #140730 by robertspark


The problem we have been having is the torch is staying on when the delay is set and it is still firing when the z axis is retracting.


ok, that sounds like the sequence of code is wrong within plasmac (bear with me not trying to pee on anyone's parade and all may become clearer with a bit of explanation)

from what I understand is plasmac is fully controlling the z-axis from m3 to m5, where m3 will tell plasmac that it needs to do a touchoff, retract to pierce height, fire the torch, wait for arcOK (if puddle jump is not set) drop to cut height, and begin XY motion controlling the Z axis relative to the THC inputs ( voltage / THC up or down, and inhibit z-axis correction if xy actual feedrate relative to set feedrate drops below the set parameter, as well as finally detecting kerfs to inhibit z-axis motion)

at the other end is M5 which tells the torch to extinguish, but also retract the torch to safeZ

I suspect that you need to consider how m5 actually works.... M5 is done OUT of sync with motion.... same as M3. whilst this may at first seem minor you need to consider what this means with G64

when an m5 comes along g64 is ignored by the planner and motion comes to a stop before m5 is enacted. so there are actually 2 parts to my, and I suspect that maybe plasmac is only looking at one part.... plasmac needs to look at both m5 and motion stopped BEFORE stopping the torch from firing and retracting the torch.

I suspect that plasma is just looking at the one m5 input which is actually used by the planner to decelerate the axis to a stop before actually running the actual code with the m5 macro file.

note I am not a linuxcnc user so some of my terminology may be off.

the fix will be to use an AND statement for m5 and motion stopped pins / inputs. I suspect you may need to allow a delay to allow for plasma to implement the hidden m5 z-axis and torch off control or linuxcnc will move to the next line after my very fast with will probably move the torch to the next part before the torch has retracted

Please Log in or Create an account to join the conversation.

More
27 Jul 2019 09:22 - 27 Jul 2019 09:24 #140732 by robertspark

The online version of PlasmaC has a problem where the Z axis retracts before the torch off delay has completed.

A version I completed this afternoon uses M62 P3 to turn the torch off and M63 to enable turning it back on. This version has not been pushed yet.


I'd probably suggest or recommend not doing it that way around as it will lead to some confusion (but each to their own)

I'd suggest using an option ....
M3 must always be issued to start the torch, and perform the touchoff etc, but then if you want to turn off the torch early you need to issue an M62Px anywhere after m3 and where you want to turn off the torch an m63Px..... motion will then continue until m5 where the xy axis decelerates to a stop and the z-axis is retracted.

this is because M62 is output on and m63 is output off.... yes I know the signals can be inverted, but if you forget to add an m62 later your torch probably won't fire..... unless you automatically reset m62 at the time of m5
Last edit: 27 Jul 2019 09:24 by robertspark. Reason: autocorrect m3>me

Please Log in or Create an account to join the conversation.

More
27 Jul 2019 09:23 #140733 by robertspark
autocorrect is changing m3 to me!!!
The following user(s) said Thank You: rodw

Please Log in or Create an account to join the conversation.

More
27 Jul 2019 09:29 #140734 by robertspark
yes there are two things being discussed here and they are not the same

one is m5 which is not working correctly (motion must stop before enacting m5)

and the other is the ability to via sheetcam issue an m63 (or m62 if that is the way you want to go) before the overcut to stop the torch firing before it decelerates to a stop which will prevent the overburn divot at the end of the cut where m5 is implemented

Please Log in or Create an account to join the conversation.

More
27 Jul 2019 09:46 #140735 by docwelch
Phill,

You probably already have this covered, but before you release the M62/63 version, just a reminder: When I mentioned the use of M62/63 codes for turning off the torch at the end of cutting a circle last week, Rod mentioned the concern below:

You have to include M5 to turn torch off becasue if its left to M62/3/4/5 if you hit estop, the torch will continue to spew fire which is not pretty if the breakaway activates and the inverter is on the opposite side of the table to you. Ask me how I know?
It would be possible to AND2 the motion pin with a digital pin to enable the torch on relay but that breaks the sheer simplicity of plasmac. there is a motion.distance-to-go pin but I suspect it is for a specific segment, not the whole movement from M3 to M5


Steven
The following user(s) said Thank You: tommylight

Please Log in or Create an account to join the conversation.

More
27 Jul 2019 09:58 - 27 Jul 2019 10:18 #140736 by phillc54
Rob. Thanks but I have done a fix that works fine in a sim, just waiting for one of the guys to test it on a machine before pushing.

Steven, yes, that is under control.

Sorry about the edits but I am not good at using a phone for this. :(
Last edit: 27 Jul 2019 10:18 by phillc54.

Please Log in or Create an account to join the conversation.

More
27 Jul 2019 09:58 #140737 by rodw
Replied by rodw on topic Another plasma component...
I think the decision for plasmac becomes whether it remains nice and simple and works off M3/M5 or whether it should add an additional command to enable/disable the torch from Gcode. One way or the other M3/M5 must be part of the torch enable otherwise the torch can remain firing after you hit estop!

When I reviewed some of the material Phill said he modelled some features off, other commercial systems do use gcodes to enable the torch so the gcode can disable the torch independent of M5. I did wonder at the time why Plasmac did not include the gcode torchenable.

Phill's got two commercial testers. John only cuts thin material around 2mm. Stefan cuts anything up to 20mm. I kinda think Stefan is finding some issues that were not discovered earlier by John. I know that the few parts I cut from 16mm did open whole new can of worrms.

I'm not sure I've cut enough to make a recommendation one way or another except to say Stefan has probably discovered why commercial systems can enable/disable the torch from g code. It not that difficult to add this feature using hal components without changing the core plasmac code. Its just that Phill has been spoiling us

Please Log in or Create an account to join the conversation.

Moderators: snowgoer540
Time to create page: 0.395 seconds
Powered by Kunena Forum