Feature Request

More
12 Aug 2020 11:05 #178025 by snowgoer540
Replied by snowgoer540 on topic 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.


:blush: 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?

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

More
12 Aug 2020 11:12 - 12 Aug 2020 11:13 #178026 by phillc54
Replied by phillc54 on topic Feature Request
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
Last edit: 12 Aug 2020 11:13 by phillc54.

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

More
12 Aug 2020 11:18 #178027 by snowgoer540
Replied by snowgoer540 on topic Feature Request

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!
The following user(s) said Thank You: phillc54

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

More
16 Aug 2020 21:00 #178428 by snowgoer540
Replied by snowgoer540 on topic Feature Request
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!
Attachments:
The following user(s) said Thank You: phillc54

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

More
16 Aug 2020 21:15 #178429 by snowgoer540
Replied by snowgoer540 on topic Feature Request
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

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

    More
    16 Aug 2020 21:31 #178431 by tommylight
    Replied by tommylight on topic Feature Request

    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.
    The following user(s) said Thank You: snowgoer540

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

    More
    16 Aug 2020 23:06 #178434 by phillc54
    Replied by phillc54 on topic Feature Request

    tommylight wrote:

    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.

    Oh, did I forget to mention the Multi Cut feature. :laugh:

    And I thought I was going to have a quiet day. :)


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

    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.

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

    More
    17 Aug 2020 01:00 #178440 by snowgoer540
    Replied by snowgoer540 on topic Feature Request

    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. :laugh: :silly:

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

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

    More
    17 Aug 2020 01:13 #178444 by phillc54
    Replied by phillc54 on topic Feature Request

    snowgoer540 wrote:

    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?!

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


    What do I win now??

    You get to keep your job. :laugh:


    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.

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


    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.

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

    More
    17 Aug 2020 01:26 #178448 by snowgoer540
    Replied by snowgoer540 on topic Feature Request

    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. :laugh:

    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 :laugh: 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.
    The following user(s) said Thank You: phillc54

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

    Moderators: phillc54
    Time to create page: 0.189 seconds
    Powered by Kunena Forum