Did you get Estlcam to add gcode line numbers Jason? Or still running an external script?
I was never able to get Estlcam to output line numbers. Itâs odd that the hover help info mentions using <!N> to suppress line numbering for a specific line, but there seem to be no options to add it. Iâm assuming that the GRBL preset just doesnât include it.
Iâm pretty sure I wrote a PowerShell script to add line numbers but I canât find it at the moment. It would be quick to recreate. For my test gcode, it was short so I just did it manually.
I should probably just make a tiny app that could be setup in Estlcam as an external postprocessor. Even if this stallguard thing doesnât work out, Iâd still like to use line numbers.
As a quick workaround, you could probably use this VS Code extension, using a prefix of âNâ and suffix of " ".
Insert Line Number - Visual Studio Marketplace
Estlcam does not add the linenumbers but does count the linenumbers in the controller if you use it. Maybe he means that you can exclude lines from that with <!N>.
1 Like
Not a must have, but it would be nice
This happened to me with 4 +300usd sheets. This 
badly. The luck i had is the damaged sheets worked for other smaller pieces
Well shoot, that seems extremely useful.
I bet we could get Christian to include line numbers as well.
We need a new board now.
2 Likes
What were you intending to do with stallguard? Dynamically up the motor currents if steps got skipped?
No, just stop the job if too many steps are skipped. And wait for a manual fix
Sorry, I was trying to direct that at Ryanâs above comment but it doesnât seem to have shown up as a reply. Weird.
Iâm very much agreed that âstop and wait for operatorâ is the way forward, just curious what Ryanâs original idea was.
Iâm still not sure this is going to work out. Setting an appropriate threshold across feedrates is still uncertain. Iâm wondering if weâd need different thresholds for axes with single steppers vs double (X vs Y). Z being a slower feedrate plus being leadscrews vs belts might be different too. FluidNC is still calculating a value based on the homing feedrate. We could experiment with that by setting the homing feedrate high in the config. Although, maybe setting the threshold high works around that. Either way, if this did work out, it would definitely be useful.
How many can we get accomplished on the current board? Looks like at least X and Y are possible?
Jason, did you ever get
X Axis Stallguard 0
X Axis Stallguard 1
to show up, I turned on debug and lowered interval but not seeing yet. Iâm getting the SG_Val: messages though. They appear to go lower, the more force is on the X stepper, all the way down to <100 when I induce a stall. I can get it in the 100-200 range by putting pressure on X. Above 200 and it is freely moving in air. I have the fault pin connected, but am not using it yet, just tracking SG_Val.
Not seeing the 0 and 1 yet, but did turn on fault pin and connect direct serial,
[MSG:INFO: X Axis SG_Val: 356 Rate: 4000.000 mm/min SG_Setting:15]
[MSG:INFO: X Axis SG_Val: 366 Rate: 4000.000 mm/min SG_Setting:15]
[MSG:DBG: fault_pin 1]
[MSG:INFO: Stopped by fault_pin]
[MSG:INFO: ALARM: Hard Stop]
ALARM:13
[MSG:ERR: Reset to continue]
[MSG:DBG: fault_pin 0]
When purposely crashing into X max
1 Like
No, I looked at the code and it doesnât appear to output that anymore. Seeing the fault pin triggered works though.
Estlcam, if used as a controller, can map one of the inputs to the alarm function of a closed-loop stepper and as soon as the stepper reports back that it could not recover the position it halts the job. Maybe thatâs feasible for FluidNC as well?
1 Like
This is exactly what weâre doing here. Weâre tying the stepper output to a fault pin.
I think the problem with the Jackpot and external drivers in general is that I think itâs using 3.3v logic where the drivers want 5v. Bartâs 6 pack controller has a jumper to switch between those voltages. This is why you canât mix and match drivers. I donât completely understand all of this or what all that effects.
2 Likes
Ran a full 4x8 surfacing pass in the X direction, about 200 cutting passes total, and with SG_Setting:15 it never faulted, which is good I guess. Speed/depth was pretty conservative so it should not of been missing many steps if any.
Next up is a speed test to see when it kicks in with 1/4in bit 1/8 depth. Going from 500-3500mm/min. Should be able to measure and see when steps were skipped if it doesnât kick in
1 Like
500+mm/sec with load? This is going to be fun to watch. Please record
I would suggest you think about what are you cutting, think of a DOC your bit/router can handle and make a cam that matches, start conservative and move your way up using the override section. Find your spot (until it misses steps, dial back a notch, and annotate it and bulletproof your cam) find your limits per different bit type. Make a record and be happy
Oops, make that per min
1 Like
You shouldnât get any issues at 500-2000 with missed steps with good cam (good sharp bits, the correct doc depending on what you are cutting, correct feed&speeds , some materials pardons more than others)
My lowriders 2/3 cuts thru expanded pvc and acm at full depth like butter at pretty high speeds. My new builds of the V4 should be even better.
Now, the subject of the fault pin is instrsting