Feature Request

phillc54 wrote:

snowgoer540 wrote:

Is that determined by the placement of the M## P1

Yes, and also the type of command

M62 P1
M3
Motion G-Code
M5
M63 P1

^would ignore Ok-to-move on startup

No, M62 is synchronised so wouldn't happen until the "Motion G-Code" began, between the M62P1 and M3 you should have your G0 rapid move to position to sync to.

M3
Some motion
M62 P1
Some more Motion
M5
M63 P1

^would ignore Ok-to-move after the arc is started and motion is under way, until the end of the cut

Yes, but to be safe you should use M65 at the end as there is no motion to sync to or use M63 P1 and have a G0 rapid move to sync to.

my fault they should have been M64 and M65's I think. Still first cup of covfefe here

M64 P1
M3
Motion G-Code
M5
M65 P1

^would ignore Ok-to-move on startup

M3
Some motion
M64 P1
Some more Motion
M5
M65 P1

^would ignore Ok-to-move after the arc is started and motion is under way, until the end of the cut

Is that right?

phillc54 wrote:

M64 will probably work ok there, M65 is fine at the end.

Personally I think it is best to use M62/M63 if at all possible. That way you can see guarantee exactly in the code were it is going to happen. I would do the first one:

M62 P1
G0 to position
M3
Motion G-Code
M5
M65 P1

and the second one:

M3
Some motion
M62 P1
Some more Motion
M5
M65 P1

Yea, that does make more sense to me. I'm excited to get to test cutting the stuff on my list now.

Thanks again!

Ok, so I got to some cutting/testing today. I'll start with the good in this post...

M62 P1 works great!

I spent some time doing experimental cuts on 1/4" thick steel, cutting a 1" circle. Here were the scenarios:

Hole #1: Perpendicular lead in (.1"), no lead out
Hole #2: Perpendicular lead in (.1"), arc lead out (.25") - This required M62 P1 before the lead out arc to prevent a pause due to lost arc
Hole #3: Arc Lead in (.25"), no lead out
Hole #4: Arc Lead in (.25"), arc lead out (.25") - This required M62 P1 before the lead out arc to prevent a pause due to lost arc

Results:
Top of plate:

Bottom of plate:


It may be hard to tell it in the pictures, but Hole #4 is probably the best quality. At any rate, I didnt try cutting an overcut at all, maybe that would yield better results. Also, this wouldnt be possible in a non-interrupted fashion without being able to ignore the arc-ok via g-code. I intend to fine tune further. I remembered at my last job we ran a big HD plasma table, and the company insisted on arcs on both the lead ins and lead outs. I guess their controller must have a way to tell they are cutting an area that has already been cut and to ignore any flame-outs, but now we can do the same thing. So I think this is mission accomplished. Thanks again Phill!

Ok, now the issues I ran into:

1. The offset jiggle is back, but it's only in the Z axis. Jiggle Video (Sound On) I can invoke it two ways:

Jog the torch down from the home position and run a cut. Let it probe, and start to make the cut. Stop the program. It should jiggle after that.

It Jiggled sometimes after a paused motion during torch enabled cutting. Fault condition occurred, I pressed stop to keep it from trying again, Jiggle sometimes ensues.

2. Clicking "Start Cut" several times, results in several instances of the "Start Cut" to be active. In other words, you click "Start Cut" 5 times, you have to press stop 5 times, and motion will resume between some of them. Start Cut Glitch

snowgoer540 wrote:

2. Clicking "Start Cut" several times, results in several instances of the "Start Cut" to be active. In other words, you click "Start Cut" 5 times, you have to press stop 5 times, and motion will resume between some of them. Start Cut Glitch

Ran into the same issue today.

phillc54 wrote:

That is the same as the X/Y "jiggle", you are jogging back up to the soft limit. I purposely dodn't disable the offsets on Z like I did with X/Y to see if this would appear. I am surprised that it took so long to find. I will do the same with Z, disable offsets unless they are being used.

Oh, testing me to see if I would notice are you?! What do I win now?? I may not have noticed had I not accidentally started a probe with the torch lowered. Normally I don't jog the Z axis much after a failure. The spring action was entertaining. Made me chuckle, but then again I'm pretty simple sometimes.

Regarding the offset, I think we said this was a bug in the LinuxCNC core? If so, did it ever get reported?

phillc54 wrote:

I was interested to see if it would happen, as it has not been reported before. (that I can remember)

I do remember trying to get it to happen with the Z axis, but I never could. *shrug* guess I had a stroke of brilliance today? lol

You get to keep your job.

Sweet! I enjoy it.

Now I know why I said somewhere in the docs to not jog the Z axis.

haha, I did say it was an accident at least when someone else makes the mistake it wont do a springy maneuver haha.

Regarding the offset, I think we said this was a bug in the LinuxCNC core? If so, did it ever get reported?

It is not a bug, it is the way external offsets works. It is mentioned in the external offsets docs to stay away from the soft limits while offsets are active.[/quote]
OHH, I missed that part. Ok sounds good then. Just making sure.