What is slowest scan possible with 200 steps pr

Newbie here, and (ab)using a miniGerbil controller on a K40. I want to be able to scan the laser at ridiculously slow speeds; sub-mm/s values. 0.01 would be fabulous.
I thought maybe i could fool the software by telling it that there are either a lot of steps per mm or very few, but the time to scan a small feature seems not to change.
It also seems that the Line feature has a fixed minimum distance?? i tried printing a sequence of little circles and it just ignored most of them.

On a different engraver, i was allowed to write a series of dots and specify the time - so i could use dot-spacing/(dot-time) to fake a velocity.
Any hints on how i could do this? gcode maybe?
perforation mode really wasn’t successful- made a feature a few times bigger than what i drew. I asked for 0.01 skip &cut, got about 3mm segments.

There’s no practical lower limit that I’m aware of. The problem is that you’re limited by the resolution of the stepper. So if you go very slow you’ll be dwelling at a single position.

In your case you’ll be taking 2 steps for every .01 mm. That means you’ll be at the same position for half a second. Not sure what you’re trying to do but you’ll need to determine if that’s a problem.

The other practical problem you may run into is that GRBL isn’t really designed to run at such slow speeds and so you may get some odd motion control and power behavior compensations at such slow speeds. There was another user on here trying to go very slowly for use on metal engraving. Two issues that I recall from memory: power was being modulated downward and I believe speed floor was higher than expected. I can’t find the forum post at the moment but worth looking for it. I believe the mitigation for the first issue was to use constant power mode. Mitigation for the second was to compile a custom firmware swapping out the motion control algorithm.

I made a POC to do this but was all hand-written g-code. This would be cumbersome to do with complex shapes without writing some code.

Thanks so much for getting back to me.

I’ll check out your code tomorrow. As i only want to make short lines, it sounds like it should work.

I’m not sure what the smallest step size is; I got a mini gerbil with fancier step sticks that are supposed to give twice as many micro steps as the regular ones. So maybe i get 25 microns per step and quarter second dwell times? I often use a slightly unfocused beam, and the thermal mass of the glass is adequate to make the heating more or less even.

It will be fun to try!

I was going from your 200 steps/mm. That would make each step .005 mm or 5 microns.

This is ultimately a function of stepper motor type, microstep division, gear size, number of teeth, and any additional gearing. But if there’s a particular resolution you’re going for it’s just a matter of working out those inputs to get you there.

I think that’s supposed to be 200 micro steps per revolution- i really have not figured out the setup well enough to understand steps/mm yet. Thanks!

Ah. Sorry. I inferred incorrectly it looks like.

Steps per mm will typically be stored in $100, $101, $102 for GRBL based controllers.

Is there some reason for the slow speed?

Just curious… most people want to go faster…

:smile_cat:

I’m using it to melt metal inside glass fibers…and the melt zone can’t move very fast…

Tried using a macro today, but LightBurn didn’t seem to recognize gcode commands such as WHILE , or settings commands starting with $??

It’s not LightBurn that’s interpreting the gcode. It’s the controller on your laser that’s doing that.

I don’t believe minigerbil supports any level of flow control and is limited to whatever GRBL supports.

From GRBL Wiki:

Limitations by design

We have limited G-code-support by design. This keeps the Grbl source code simple, lightweight, and flexible, as we continue to develop, improve, and maintain stability with each new feature. Grbl supports all the common operations encountered in output from CAM-tools, but leave some human G-coders frustrated. No variables, no tool databases, no functions, no canned cycles, no arithmetic and no control structures. Just the basic machine operations and capabilities. Anything more complex, we think interfaces can handle those quite easily and translate them for Grbl.

Emphasis was added by me.

I’m not familiar with $?. What is meant to do?

Thank you

and thank you for your tolerance as i blunder along the learning curve.

I will generate stepwise code for the controller.

The $ commands seem to be setup things-
e.g $32=1 controls whether the laser can turn in with the gantry stationary.

For someone who’s new to this - this is pretty fantastic to read. I think you’re doing great.

There was someone who was attempting to engrave metals with a GRBL controller at a very low speed (and perhaps a YAG laser) last year.

I believe that I saw a variable in the source-code for a lower limit for speed in the motion planner to maintain smoothness.

If you’re using GRBL 1.1f source code from the Github site you may have some success lowering the speed further.

The dirty hack of course is belt reduction and re-scaling.

Oh. I thought you meant specifically $?. Minigerbil should absolutely support $ configuration changes. Try typing $$ in Console to get a list of the current configuration.

i feel a trifle guilty posting here,as i’ve moved to using UGS. To my utter amazement, I can type commands in the middle of file execution and they are recognized. So I can change laser power on the fly.

I use code posted for the minigerbil test fire as a macro to make sure my alignment is good, then load a file of step and pause commands to draw the line. The proof of concept dot mode listed earlier in this thread got me going.

As was pointed out, the mini gerbil doesn’t do loops, so i wrote a short Octave (it’s free) program to write the gcode commands into a text file. Excel would work as well, I’m just not a fan of a thousand rows.

I’ve been assuming 320 micro steps /revolution and the ability to recognize a 4 micron (.004mm) step, and an 8-50 msec pause. i had expected 50microns/sec speed, but the file takes 90sec/2mm, (on UGS) which is about half that.
I had decreased the feed to F1, but still think the pause portions dominate the speed determination.

I am able to watch the melting of an alloy core silica fiber, and don’t see any obvious jerkiness, but the silica adds a thermal mass that slows things down.
The video was not an allowed format but i can send you a link if you’re really interested in strange mixtures melting inside a silica glass shell - way more limited interest than the code above, I’m guessing. :grin:

==========
% program to create input for g-code dumb enough for K40
% with high res (320 microsteps per rotation stepper sticks)
% should be greater than .003 mm
% if stock K40, use steps greater than 6 microns

% input step length desired (deltax)
%step =input (" desired steplength, mm.“,“s”);
step =0.004
distance =0;
%fprint(“teststep”, step)
%Length=input (” desired scan length, mm.",“s”)
Length = 2.0
iter=int32(Length/step)
scantime=0.001
pause = 8 % pause length in milliseconds
junk=iterpause
velocity = 1000
step/pause% microns/sec
scantime= junk/1000 % sec

%designate file to store output
filename = “K40scan.txt”;
fid = fopen (filename, “w”);

fprintf (fid, “$32=0 (allow firing while stationary) \n”);
fprintf (fid, “G91 (RELATIVE MOVES) \n”);
fprintf (fid, “F10 (Feedrate mm/s) \n”);
fprintf (fid, “M4 S150 (LASER ENABLED – power setting S is out of 1000) \n”);

for i= 1:iter;

distance = distance+step;

fprintf (fid, "G4 P0 ")
fprintf (fid, “%d “, pause);
fprintf (fid,”(PAUSE FOR P0 msec) \n”)

fprintf (fid, “G1 X +”);
fprintf (fid, “%d “, step);
fprintf (fid,”(leave laser on during translate) \n”);
endfor

fprintf (fid, “M5 (laser off) \n”)
fprintf (fid, “$32=1 (only allow firing while in motion)\n”);

fclose (fid);

=======

(output gcode looks like this:)

$32=0 (allow firing while stationary)
G91 (RELATIVE MOVES)
F10 (Feedrate mm/s)
M4 S150 (LASER ENABLED – power setting S is out of 1000)
G4 P0 8 (PAUSE FOR P0 msec)
G1 X +0.004 (leave laser on during translate)
G4 P0 8 (PAUSE FOR P0 msec)
G1 X +0.004 (leave laser on during translate)

…… hundreds of times

G4 P0 8 (PAUSE FOR P0 msec)
G1 X +0.004 (leave laser on during translate)
M5 (laser off)
$32=1 (only allow firing while in motion)

1 Like

ps - the octave code was never tidied up. anything that starts with % is a comment

Awesome progress. I wrote that “dot mode” POC a while ago hoping I could use it for something useful. Never came to anything but glad to see you could leverage the idea from it.

By the way, I for one would love to see the video of what you’re working on.

is there a way to share a link with just you? not really wanting to post it for the world…

Generally we like to discussions to be open publicly so others can get help…


You can click on the name and there is an option for message… that should allow you send someone a link you don’t want public…

Good luck

:smile_cat:

Thanks! The code is shared…

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.