Standard GRBL does not. Or at least documents it as unavailable. It’s possible that other implementations have extended this.
Using 255 to never idle but higher values to represent longer but terminal values is an odd choice.
You are right, in standard grbl, this setting can’t take any values higher than 255, since it’s an 8bit variable:
uint8_t stepper_idle_lock_time; // If max value 255, steppers do not disable.
So there are no higher values available. But I can imagine that grblHAL extended this.
Reading thru the recommendations on GitHub for GRBL laser (Grbl v1.1 Laser Mode · gnea/grbl Wiki · GitHub) and the best way to describe the problem is the machine is acting as if $32 was set to zero which makes the machine pause every time the S value in the gcode changes. Clearly my $32 value is set to 1.
The page also recommends most grbl-compatible lasers have $33 (pwm frequency) value of 1kHz. My $33 value is set to 5kHz. Does anyone think this could be a potential cause? I am using K20 laser from lasertree and couldnt find any recommendations on their page on pwm frequency.
The number of GCode lines/mm decreases as the tone gets lighter, so would tax the controller less.
Just leave the PWM at 5kHz - I doubt this is a factor to be concerned about as the ESP32 should easily be able to produce that signal, and if you require a resolution that produces discreet power changes at less than 0.1mm intervals at a speed greater than 200mm/s - that would require at least 2kHz by my calculations.
Try running the same test I sent you but set min and max to 0, this will retain all the small G1 movements but remove the S power instructions. Observe the motion…
I only can tell for Sculpfun laser heads, I discussed with the developers, and they told me that 1500 Hz is the optimal value for their laser heads. I doubt that’s going to help much here, but you might try a lower value as your 5kHz.
So gave this a try and to my surprise, it still behaved the same way as before when min and max both set to 0. Confirmed by looking at Gcode that all movements were G1 but every step still had S0 or S0:0 power settings.
Okay so I think I finally figured out what might be the root cause here… And it may actually be the USB not keeping up with the buffer… As I had mentioned, I am using X32 blackbox controller but what I forgot to mention was that I also use the Openbuilds Interface where I run the jobs by plugging in a USB that has my gcode. When I do this, I get stuttering effect that we are discussing here.
And I wondered if everything looks good, must be my hardware (although everything for my milling/carving jobs, never had any issues) and might as well try sending the gcode with some other method as I have encountered some issues with couple different gcode senders in the past.
Long story short, connected the X32 blackbox controller directly to my laptop and ran the job using Lightburn and issues went away - YAY!!
Then instead of connecting my PC directly to X32 blackbox controller, I figured would connect the PC via the interface and while the job ran well for say 10 sec, immediately ran into problems - see below:
These errors so far I have only encountered with going via the interface and is a consistently repeatable error. Any thoughts as to whats going on??
Anyways, to summarize:
- Seems like running the job thru gcode on USB connected to interface has problems likely from the data transfer rate limitation? (will have to try out a USB with faster read/write speeds sometime and will report back)
*Connecting PC via the interface and sending gcode directly via Lightburn- stuttering issue goes away but the machine returns “GRBL Error 2” say 10-20 secs into the job. Unsure whats causing this issue? - Running the job by sending the gcode directly from Lightburn - run was successful! See results below:
Think I like the 12000mm/min with 90% max power with 300DPI better.
Let me know if you all have any other troublehsooting tips on the above otherwise in the meantime I would have to continue to run the job directly from PC connection.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.