Feature Request
That worked the shutter was gone once I did those three steps.
However, after "net plasmac:offset-enable plasmac.offset-enable", it came right back.
OK, hopefully that is the answer. I will wheel my table out on the weekend and do some testing and if it does the same then I will need to disable the offsets unless we are actually using them. At the moment they are enabled all the time.
I should clarify, when I said "it came right back", I mean the shutter came back after netting the pins.
The thing I don't quite understand is that this only affects my X axis when induced using the previously laid out steps... It used to affect both. But I confirmed with Hal Meter that I don't have the issue in Y anymore, it stops right at 51.25 like it should, I can run it up to the offset until I'm blue in the face. So, I'm not sure if that bit of information helps you at all, but I figured I'd pass it along in case it does. In case maybe you did some wizardry to X that didnt make its way to Y
I think it does, because originally when this all started, I was not testing CC, just Cut Recovery. But the issue is way easier to reproduce with CC, so I've stuck to that to induce it.It should do the same after a cut recovery move as well. Unless it needs a reasonably large original offset to cause the issue.
I truly appreciate you doing that! No worries on the testing, I enjoy it. Thank you for working to make improvements/give me something to test!I won't do any changes today but I will make that combo branch for you. Again, thanks for your testing.
Please Log in or Create an account to join the conversation.
I'm honored to have a branch named after me! Thanks again!I have pushed a combo branch for you, it is phillc54/snowgoer540
I deleted the other branches to save confusion.
Ok, this will be neat to play with. I'll have to look back in the thread to see the other features that came with the Mesh Branch as I never got to switch over to it with the Cut Recovery testing... M62/M63 with the P value to ignore Arc-OK will work independent of whether or not mesh mode is not on, correct?The combo has the latest consumable change, cut-recovery and mesh-mode plus the latest conversational.
I added a temporary parameter named plasmac.mesh-arc-ok, it is for Rods suggestion of not wanting arc ok to begin a cut which seems like a good idea for mesh mode.
The default is to probe, move to pierce height, fire the torch, wait for arc ok etc. etc.
If you set this pin to 1 then it will probe, move to pierce height, fire the torch and then continue on without needing the arc ok.
You can try both ways and see which is better. If it is better without needing arc ok then I can make that happen when mesh mode is enabled and get rid of the parameter.
No worries, I'm not sure I will get to do any testing until either later tonight, or tomorrow/Sunday anyhow. Today's a rare day when both the lady and I are off for the whole dayEDIT: I hope I got it right, it was fun merging four branches into one... NOPE: summit is wrong.
You can use it if you comment out the two lines for wizards in the ini file, I will fix it in the morning.
Side note: she usually refers to this forum as "the penguin people" 
Please Log in or Create an account to join the conversation.
Haha she got a kick out of thatCheers, Penguin Phill
Thanks for fixing! Tomorrow I’ll be busy lol
Can you believe mesh mode was 11 pages ago hahaha. At any rate then you had said:
I was just wondering if the P1 variable is still also invoking mesh mode?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)
Please Log in or Create an account to join the conversation.