Feature Request

phillc54 wrote:

If it is done correctly by the developer and the gcode creator, then pretty good...

I can’t speak for the g code creator, but I have confidence in your abilities! I’m willing to take a stab at doing whatever will need to be done to the post processor. Shouldn’t be too much more different than what’s done for the thc, and if there’s anything I can handle coding wise it’s borrowing someone else’s code and manipulating it to fit my own needs lol

snowgoer540 wrote:

I’m willing to take a stab at doing whatever will need to be done to the post processor. Shouldn’t be too much more different than what’s done for the thc, and if there’s anything I can handle coding wise it’s borrowing someone else’s code and manipulating it to fit my own needs lol

Because you are such a diligent employee I have pushed a branch for you to test named phillc54/mesh-mode.
Mesh mode is selected by either:
A checkbutton on the run panel
Gcode with the motion.digital-out-01 pin (M62/63 P1 for syncronized or M64/65 for immediate)

Mesh mode disables THC and ignores lost arc during a cut. You still need a valid probe and arc ok to begin the cut.

Have fun...

Edit: this branch does not include cut-recovery, it is based on 2.8

Edit2: I think this will only work on very thin material but I have an idea that may increase the thickness a bit.

It's like waking up on Chrismas morning! Thanks Phill! I'll jump back and forth between testing the cut-recovery (want to do some of that today), and Mesh Mode.

Curious, I can fathom what Immediate mode is, but where would I use synchronized?

Also, why will this only work on really thin material? Whatcha thinkin there?

snowgoer540 wrote:

It's like waking up on Chrismas morning! Thanks Phill! I'll jump back and forth between testing the cut-recovery (want to do some of that today), and Mesh Mode.

Curious, I can fathom what Immediate mode is, but where would I use synchronized? ?

For mesh mode immediate is probably ok, at the beginning and end. Synchronised would be for something like torch off so it would turn off when the next motion segment began.

Also, why will this only work on really thin material? Whatcha thinkin there?

I am thinking that there will be no preheat in the material from piercing. It may require a slower cut feed rate. I was also thinking maybe a slight pause when it sees the next arc ok may be in order, but that may be too late depending on cut feed rate and machine response

phillc54 wrote:

I am thinking that there will be no preheat in the material from piercing. It may require a slower cut feed rate. I was also thinking maybe a slight pause when it sees the next arc ok may be in order, but that may be too late depending on cut feed rate and machine response

I'm not really following. I was thinking that you'd use the ignore the arc-ok (and disable THC) in the areas where you are pretty certain it's going to flame out but don't necessarily care if it does. Example would be at the end of a hole, where you put a lead out to get rid of the dimple, but know at some point it's going to lose the arc-ok and you don't care.

Perhaps we are dreaming up different scenarios?

User button.

rodw wrote:

If you are going to ignore arc Ok behaviour, why insist on it at the beginning of the cut?

I can forsee that a user might resort to some trickery to get a a probe height. eg place a sheet of thin material on top of the mesh and remove it before the torch starts. I do this sometimes if I have to restart a cut now if the material has burnt away and won't support a second restart.
But if you want to cut some weldmesh, it implies you must start the arc on top of a metal rod and that rod will have to be on the top of the mesh and this is probably not always going to be possible. Are you really going to be able to align your material to the start position that accurately? What about when you cut a hole? You are going to have to make sure every pierce starts on a piece of mesh material. Thats not going to happen!

I do not think there should be any conditions or restrictions on this feature. If you disable arcOK, you disable ArcOK effective right from the start of the cut. Its up to the user to create an appropriate tool with start delay and velocity to use it.

I think it's just proof of concept at this point. I can see it both ways, I guess. For me, I want to make sure things got established and got moving, I just dont really care what happens near the end of the cut, not enough to pause motion. I think it's a good place to start for testing. I think in your scenario for expanded mesh metal, you could still use the scrap material to probe and get going. It's probably necessary.

I didnt get to do any testing today, the mill took up all of my time, but I did try F9 and jogging, and discovered that I still have the issue where I cant jog anymore after I press escape to stop the torch. The arrow keys instead select the X Y or Z axis highlight in the touch off/homing area. No amount of clicking makes it go away. I have to kill LinuxCNC and start over to get it back.
EDIT: I cant get it to do it again, I was trying to find the exact steps to reproduce, it seems to be intermittent, which I know is the worst kind.
EDIT2: Not sure if it's related, but I cant get Cut Recovery to come up when it's paused anymore either


Also, I was talking to CBEAR tonight, and he noticed that the change consumables button no longer works. If you pause a NC file (during a rapid, etc), and try to jog, you get a bunch of trajectory errors. Further, if you press Change Consumables, nothing happens.
EDIT: I got this to work as well. It moved all the way to the X home position (no other axis which I think is normal). Everything worked as it was, but I also experience where it didnt work at all.
EDIT2: If I pause it at the end of a rapid move, prior to where the M3 is, then change consumables doesnt work anymore.