Feature Request

PCW wrote:

The DPLL will be enabled (for the stepgen) by something like this in your hal file:

# latch 50 usec before nominal read time:
setp hm2_[HOSTMOT2](BOARD).0.dpll.01.timer-us -50
setp hm2_[HOSTMOT2](BOARD).0.stepgen.timer-number 1

( The [HOSTMOT] and (BOARD) tokens make be the actual card name and 0
depending on how your hal/ini files were generated )

I would try to get a scope capture when the actual stutter occurs.

I have to admit: I have no idea how to make halscope work. The last time I had to use it with the THC stuffs, I lucked into it.

Here's what I was able to tell on those pins using Hal Meter:

When I start on a freshly homed table, I can bump into the soft limits all I want, and the joint.0.pos-cmd stops at 51.25 which is my soft limit.

When I bump into it the first time after I do the sequence which gets the shutter to start, it goes as follows:
1st bump - 51.24999
2nd - 51.24992
3rd - 51.24993
4th - 51.24994
5th - 51.24995
6th - 51.24996
7th - 51.24997
8th - 51.24998
9th - 51.24999
10th - 51.24992
Etc - this keeps repeating and gets random if I jog further off the axis.
At this point if I rapid against the soft limit, I get a joint following error, hint about switching to joint mode to jog off the soft limit, and an exceeded positive soft limit error.

I'm sorry I cant get you a halscope plot, but that basically describes what I'm seeing with Hal Meter.

snowgoer540 wrote:

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.

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 won't do any changes today but I will make that combo branch for you. Again, thanks for your testing.

phillc54 wrote:

snowgoer540 wrote:

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

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

I won't do any changes today but I will make that combo branch for you. Again, thanks for your testing.

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!

one more thing I noticed. With the Hal meter, X and Y dont go to 0.400.

X goes to 0.3926908
Y goes to 0.3927062

Not sure why that would be?


I am still a bit miffed as to whether or not my stepper table without DPLL and with a 6i25 needs the maxerror stuff or not, but for testing sake I added it and confirmed that while the shutter is less, the Hal Meter does the described behavior of not stopping at 51.25 still. And I can rapid the table past the soft limit in X. Again, Y seems ok. Maybe it's just coincidence, but honestly It did it before with the exact same steps....

snowgoer540 wrote:

one more thing I noticed. With the Hal meter, X and Y dont go to 0.400.

X goes to 0.3926908
Y goes to 0.3927062

Not sure why that would be?

It is set in the component at 10mm then scaled by halui.machine.units-per-mm so it should be 0.3937008. I am not sure why the difference, I'll leave that to smarter folk.

EDIT:

I should clarify, when I said "it came right back", I mean the shutter came back after netting the pins.

That is what I thought you meant.

I have pushed a combo branch for you, it is phillc54/snowgoer540
I deleted the other branches to save confusion.
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.

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

phillc54 wrote:

I have pushed a combo branch for you, it is phillc54/snowgoer540
I deleted the other branches to save confusion.

I'm honored to have a branch named after me! Thanks again!

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.

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?

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

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 day Side note: she usually refers to this forum as "the penguin people"

Should be good to go now.

The only thing with mesh mode is you get a checkbox to switch to mesh cutting which ignores loss of arc ok.

Plus there is the temporary parameter which if set to:
0 - will require arc ok to get started
1 - will not require arc ok to get started
default is 0
All other heights/delays etc remain the same.

Cheers, Penguin Phill

phillc54 wrote:

Cheers, Penguin Phill

Haha she got a kick out of that

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:

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)

I was just wondering if the P1 variable is still also invoking mesh mode?

I was just wondering if the P1 variable is still also invoking mesh mode?

Sorry I forgot about that. Yes it is still valid.