Here’s the pattern I was talking about.
I have to come to the conclusion that the guides about setting TCON/TCOFF specifically are not doing it correctly due to a fundamental misunderstanding of what it is.
It is not there to prevent overburning where it’s accelering/braking at starts/stops/corners.
It’s timing of the pulse energy vs the time framing of the XY galvo.
Neither LB nor EZCAD nor the BJJCZ implement overscan for the start point. For a lone linear vector, it jumps to the start point, brings the mirrors to a stop, issues a fixed-power fire command, starts accelerating down the vector, reaches the constant velocity specified in the user’s settings.
Since it doesn’t use an overscan area to speed up to the commanded speed at the start of the vector, and it can’t scale back the power while speeding up, the acceleration zone is GOING to be overburned.
The overburn is going to be deeper the faster you go. If you do “the same” burn by using 5x the speed and 5x the freq with the same q-pulse and power, the pulse delivery should in theory be the same. Raising freq and speed together mean the pulses per mm should be the same.
But the faster will see much more overburn at the start. At low speeds, the galvo may accelerate to the commanded speed before even encountering the second pulse. At high speeds and mor
Trying to compensate for this by skewing TCON would create more problems.
I’m unclear on exactly how it stops- I do clearly see the overburn around the start point, but the endpoint is a tail the narrows a bit. So it doesn’t look ahead and start braking before the end of the vector- not for singles. It does come to a stop (and overburns) for vectors chained together because they share endpoints (corners)
I’m not sure exactly how the BJJCZ does it trajectory planning, but clearly for single vectors it lets the mirrors scan past the endpoint and just turns off the beam when it should be passing the endpoint.
In a raster context, TCON/TCOFF shift where ALL features start and stop, not just the start/stop of the raster line. e.g. if you are rastering a bunch of 1mm dashes with the beam going left to right, increasing TCON will shift all the start points to the right. This narrows the dashes.
Increasing TCOFF shifts the stop points to the right. The dashes get longer.
If you add the same amount to both TCON and TCOFF, the entire raster line will shift to the right without distorting the dash lengths.
TCON/TCOFF is critical for all rasters that use bidir, cross hatch, or rotation. If you increase TCON to reduce the overburn on vectors, simple unidirectional rastering (graphics or fill) won’t look that bad at first, the features are just narrowed a bit by the delayed start every time it encounters something to fire for.
But once you click Bidir, then the left-going line and right-going lines do not line up. If we do a simple horizontal raster on an aligned rectangle, both left and right sides will be jagged. Some may try to fix this by using rotation, which then spreads the timing errors all over the place and it will “smooth” the edge and make it appear blurry, but generally not jagged. This isn’t the right way to do it, it will not be crisp and small features will disappear.
Also, the linear size of that error will be reduced proportionately by rastering slower. This leads to a widespread belief that the rasters are just less accurate at higher speeds, and settle for unnecessarily slow rasters. That’s not the case. The common SG7110 should be pretty accurate all the way up to 7000mm/s. Just FYI, if we go with 0.015mm as the focal spot size, at 7000mm/s is still 2us per spot size. The interesting point is the q-pulse is in nanoseconds, so the q-pulse time of even 500ns is still significantly smaller (1/4th) than a spot, so it can’t “smear” the pixels by taking too long. Also of note, the center of the energy output would only shift over by about 1/8th of a spot if you switched all the way over to a 2ns q-pulse. This explains why timing seems to be unaffected by q-pulse choice.
TCON/TCOFF should not be calibrated by vectors, but by raster. What I did hear is create vertical reference vector lines. It won’t matter much what is already in TCON/TCOFF, that would only shift the line’s endpoints up or down, it can’t shift them left/right. You can zero them out before starting if you want, or not.
This test takes only a tiny space, and gives an instant, objective, precise measured answer for the correct TCON/TCOFF.
The raster must by unidirectional (not bidir), oriented horizontally, with no rotation, single pass, standard LI (probably 0.015mm for a 110mmx110mm lens), that does all the shapes at once (not individually). I use left-to-right travel. Higher raster speeds, ~3000mm/s, are best since any TC error will shift the features more measurably. I’d recommend freq=speed/LI although I didn’t follow that here.
We want want to keep the line narrow, so use the shortest q-pulse that makes a mark.
All we’re looking for is the raster rectangles line up with the tick mark- and the correct tick mark in both start and stop point. It’s fairly easy to calculate from speed, the large rectangles and the tick marks are 1mm apart and then halve over and over.
Don’t look at the leftmost or rightmost rectangle. As we’ve been discussing, there is no overscan, so the mirror is accelerating for a bit before it reaches a constant velocity at the commanded speed. This region is not what TC should be tuned for.
Example: at 3000mm/s, the left side of the rectangles is shifted one tick mark on the third row of tick marks from the bottom and the stop point is shifted right by one tick mark on the fourth row.
3000mm/s =0.000333333 sec/mm=333.3333us/mm
Ticks are mm, 0.5mm, 0.25mm, 0.125mm
Start TCON is one tick of third row=0.25mm too high.
333.333us/mm * 0.25mm= reduce TCON by 83.3us
Stop TCOFF is one 0.125mm tick too high
333.333us/mm * 0.125mm=reduce TCOFF by 41.67us.
Or, putting that together, one full tick’s correction in us is 1,000,000* 0.5^(row number-1)/(speed in mm/s).
This will make all rasters beautiful. In my testing so far, timing does not seem to vary significantly with speed or q-pulse type.
tccal.lbrn2 (25.1 KB)
