How do galvo speed limits work, actually?

I have an SG7110 galvo head. The tab to request info from laser reports a max speed of 7000mm/s. LB won’t let me enter a higher speed to see what would happen. I don’t see a bypass- I’m a curious experimenter, I can imagine how this might be a risk to the equipment, but this seems unlikely. So… can’t I “overclock”?

But… speed is actually angular velocity of the galvo mirror. The lens determines distance. How does speed have any meaning without knowing the lens?

The most “standard” lens is 110x110 work area (F100, iirc).
So I got curious and went into laser config and entered it as a 55mm work area, but I DIDN"T actually change the lens. I scaled my test graphic dimensions by 50% and moved to the new work area center.

But it lets me set the raster layer speed at 7000mm/s, which is now twice the angular velocity- this is now commanding 14,000mm/s on the mirrors.

Actually raster wasn’t that bad, this might be tunable. The SHX font became more like cursive. I found this odd because I’d only set it at 300, which is now 600. And it actually seems to be burning deeper, melting even, which makes no sense.

I’m not 100% sure what happened. Actually, the BJJCZ may have limited the angular velocity in hardware, but the TCON/TCOFF timing should be in the real time units based on where LB thinks the start and end points happen in time - and the end point is reached much later than it should because it limited the angular velocity.

I’m curious what happened. And I can see something’s wrong here. The mfg’s specs are the start of the prob- 7000mm/s is not a speed without knowing a lens.

The max mirror speed is probably based on an assumption of the 110x110 lens.
LB isn’t scaling the max speed with the lens. It allowed me to enter an illegal speed. A 55x55 lens would be limited to 3500. I’m not really complaining, you could just enter a legal number if you had a <110x110 lens.

But, I realized LB won’t let you use the right limit when you use a WIDER lens. The 300x300 can move at 19,090mm/s, right? Same mirror velocity as the 7000mm/s @ 110x110. LB’s going to limit it to 7000mm/s which would be a real problem.

Part of the markcfg7 and/or one of the core files loaded into the controller figures out the relationship of distance/speed. Don’t know how much Lightburn has to do with it, but Oz advised they know this information. Since the controller doesn’t appear to store these through a power or reset cycle. I’m sure when I load the right Lightburn device file for a lens, this gets used somehow.

You’ve made a few comments on how the JCZ control board works, is this inside knowledge?

:smiley_cat:

I’m making educated guesses about how the BJJCZ works. Actually throwing out some preliminary conclusions with the hope someone will pop up and tell me where I’m wrong.

yeah changing the lens would have more reaching consequences overall. i guess right now you’d have to make a whole new machine profile for each lens. but then constants like tcon tcoff would have to be manually copied across the configs. and jump speed and jump delays aren’t constants inherent to the hardware, you may get better results when you go with higher or lower jump speeds but there’s different calibration numbers for each jump delay that goes in as a set. delay would be the same number but the jump speed would have to be scaled for the lens because it’s in distance not angle

i am coming up with a test for jump delay as well
it seems the key is to lower the freq so they make separate marks, then you can zero the delay first, raster as bidir with small and very large LI and count the marks made as it rings down the raster line. the number of marks is an absolute measure of time to settle

jump speed radically affects the overall raster speed, even when mm/s is the same. i did calcs and noticed the jump delay is going to have relatively little effect on the net runtime. whereas a low jump speed brought the 7000mm/s raster to a crawl

i am thinking the end tc should be zero when everything else is adjusted correctly. the beam should stop when it reaches the endpoint when tcoff is correct. in which case it won’t matter how long you wait with the mirrors stopped on the endpoint

1 Like

That’s what I’ve been doing.

I create a new device and import the mark7cfg file. I think this has all the details of the controller type, delays and so forth. I then import the core file for the new lens correction values.

Lightburn keeps them straight, so I have 4 devices because I have four lenses.

OK, that explains it.

:smiley_cat:

This might add some good context https://forum.lightburnsoftware.com/t/rotating-table-support/91769/16

The speed setting is indeed based on the surface speed. Ultimately it’s converted to “angular bits per second” where the full available range of the rotating mirror is represented as a value from -32767 to +32767 (or 16 bits of total range).

If you had a 200mm field lens and changed to a 100mm lens, it would double the angular rate of the mirrors to hit the same speed.

2 Likes