I’m not seeing that. On my 2mm jump test is appears to be maintaining CV while turning off and on. Jump delay does not affect it but TCON/OFF does. Comparing the 2mm jump to the “Back to start>change directions>wait for Jump delay>Start moving>Laser on” and also your tests where you add the sacrificial bar.
Agree
oh but i think you ARE seeing it
look at your OFF gap. see how the end of the raster feature over burns? that’s because it’s braking to a stop there it shouldn’t because there is more raster content on that line to do . i specifically included those bars on the left and right to give it content ahead of and after the calibration dash
you could make that overburn go away by reducing toff. but if toff is zero, then it has no wait after the end of the vector before jumping so you don’t see much overburn. i think there’s still a small drop in speed just because it stops as it processes the next vector.
they do still have function. if you zero out ton toff to keep the raster line running smoother, then the start of the raster line will be wobbly. that will happen in the margin bars and settle before scanning through the calibration dash
it looks like the best way to work around LB’s flawed raster method is to zero out ton toff and set jump speed the same as the raster speed to try to keep it CV. But the start points may be wobbly, and this does cause additional quality issues on vectors if that timing is used on a vector layer.
My Bad, sort of. Still don’t think in a straight line with a gap Jump delay stops the mirrors, it just delays the laser from firing.
3 tests, one with 4000-500-750-2 and one with 4000-0-0-0 and one 2000-000 both bidirectional
So slowed the jump speed down to 2000
eye yi yi.
EDIT I don’t see burn in with a straight jump.
Is there any way to control which way these lines draw? This is one reason I want to test with raster. The Preview window can be stepped through to understand what went from where to where, but it can’t be documented from there- a screenshot would be nearly meaningless.
Like this one:
I first ASSUMED these tails are the TCOFF period where it’s jumping to the other segment collinear with it. But it could be the start point, for all I know.
Or, maybe not? The new TCON/OFF tower test gave me this result. START on left, END on right. Again, this is where unidirectional leftgoing and rightgoing rasters meet.
A few notes:
First, the clearest fact here is the on the END gap on the right. There’s overburn there. At the end. So it didn’t coast past the endpoint.
I played with this again. Reducing TOFF delay (which makes it shut off sooner) doesn’t move the line- not at first. it rolls back the overburn. if you roll it back further, the overburn disappears, then the line starts to move.
So it looks like… hmm… theory, it may be coasting past the stop point at cv, but only by a very small amount and that amount is hardcoded into the bjjcz. So if you have it right, the beam OFF happens when it coast past at CV and no overburn. Go further and you get overburn, but the line will only move a little bit before it has the beam waiting at the motion STOP point
If that’s true… oh snap. Doesn’t that mean the beam has coasted past the motion STOP point, so even if we land beam OFF on motion STOP perfectly… if this is finishing “segment 2”, but then there’s only one white pixel then a black (segment 2), the mirror is past the motion START point for segment 2… it’s already overshot! so it will have to reverse itself to get back to the start point for segment 2?
Next point: if I reduce TON delay, the beam ON happens before the motion START point. But it’s not overburn, not when I have JUMP DELAY at 0. There’s just more overlap. So it never waited at the motion START point.
Lemme think how to test this
Another thing that’s bothering me- I’ve been focused on raster. Let’s think vector. Let’s say it’s a 90deg corner. The POLYGON_TC says after it burns from x0, y0 to the commanded coords X1, Y1 and waits POLYGON TC while the beam stays on (AFAIK). So it didn’t do “try to jump to X1, Y1, but just keep driving there until you coast past, then brake”. The overburn would show the beam overshooting the corner, then make an overlapping line as it moves back to X1, Y1 and waits before it heads on on the second side.
So, the BJJCZ does have an idea of how to initiate a brake ahead of reaching X1, Y1. How does it know that?
Well, it doesn’t actually know when it’s reached X1, Y1. If POLYGON_TC=0, it will round off. POLYGON_TC is NOT about turning off the beam at all. It doesn’t even involve the beam.
OK, the bjjcz is told “jump to x=0,y=0 (beam off), fire to x=0 y=20 at 3000mm/sm, then fire to x=20, y=20”.
So if the mirrors are like a voice coil against a spring, the analog DC current sets a static point of deflection it will eventually rest at. The bjjcz could calc that current and blindly drive it with a DAC, and calcs “20mm of motion at 3000mm/s is 6,666us. So just tell the DAC to move from (0,0) to (0,20), wait 6,666us, then tell the DAC to move to (20,20)”
But acceleration must happen. It’s not at 3000mm/s for the first half mm or so. So they revised it to “tell the DAC to move from (0,0) to (0,20), wait 6,666us PLUS dwell with the DAC target at (0,20) for a user-specified POLYGON_TC, then tell the DAC to move to (20,20)”
That would require no additional calibration inside the bjjcz. But if that’s what it is, then the time dwelled for POLYGON_TC would be excessive when running lower speeds.
I can test for that. But, what if this isn’t actually a fixed time constant? The dwell time needs to scale with speed. But the bjjcz was told the speed. It knows it. It probably DOES scale POLYGON_TC by speed… in which case, it was never really a “time constant”. If so, POLYGON_TC=100us never actually meant 100us. Nor is it a distance. It’s an acceleration factor.
So the code would be:
fire from x0,y0 to x1,y2, then fire to x3,y3. segment distances are precalculated as vector sums v0 and v1. vo=sqrt((x1-x0)^2 + (y1-y0)^2)
is
“if LASER_TC is negative, set LASERON=1, wait LASER TC”
“now set DAC=x1,x1”
then
“if LASER_TC is positive, start a countdown from LASER_TC_ON and fire the laser when it reaches zero” and simultaneously "start a countdown timer at LASER_TC_ON and fire the laser when it reaches 0. and "start motion countdown timer= “(v0/SPEED plus POLYGON/TC*SPEED)``" for the mirror to reach what we assume is x1,y1. then once the "set DAC for x3, y3" and "set countdown timer for ((v1/SPEED plus POLYGON_TC*SPEED)-LASER_OFF_TC))`, turn off laser when it reaches zero”. That would mean larger LASER_OFF_TC turns the beam off sooner. This is the way the sign worked in my testing.
END_TC would apply to x3,y3 somehow. Does it control how long the beam stays on? I don’t think so. Sounds like it replaces POLYGON_TC if the cut vector is followed by a JUMP instead of chaining with another vector.
So my guess is POLYGON_TC and END_TC only affect the motion part. LASER_TC_ON and OFF only apply to the laser fire command
NEW TEST VERSION
I had the corrections twice as big as they were intended. Half the time they will still converge, but half the time it just oscillates. green numbering changed. DELETE THE OLD TEST
Also changed the instructions a bit
tcon_tcoff_test_v04.lbrn2 (1.9 MB)
The tails are TCON. It can be shown. The polygon starts bottom left and goes CCW, first fill line up goes left to right. Second fill line up is going right to left. Both rectangles are filled or what you call raster as a group, creating the jump. I just increased the line increment on the fill to 0.5mm to get a better look AND to differentiate overburn from overcrowding affecting the material in a way that mimics overburn.
.
I’m going to do some more testing later when I have a minute. And after I’ve had time to dissect your latest dissertation! 
From another video, EZCAD Jump delay.
My test 4000-0-0-0
No Bi
All TC=0
So Jump Delay pauses at the start in LB, but at the stop in EZCAD.
Lemme stop you right there and blow your mind.
Jump between raster lines, at least on bidir where it takes two line-interval 90 deg hops before reversing, uses POLY_TC. On LB. Not sure about EZCAD.
I don’t have the photos I took on this PC. Set TCOFF very high and or TCON very low (negative), high LI (1mm or more) and the beam won’t turn off at all during these short hops.
With POLY_TC at zero, the raster lines don’t corner, they make a loop on the turnaround. Add some POLY_TC and it turns into corners.
On unidirectional or rotation, that will change the manifestation of defects. The endpoint won’t show curvature because it’s coming from a transit reversing at almost 180 deg. POLYGON_TC affects mirror MOTION, the trajectory plan, NOT beam on/off timing from the corner except that the corner point in time happens earlier is POLY_TC is zero.
So zero POLYGON_TC on a unidir would fail to wait for the mirror at the second line’s start point. If it doesn’t affect beam timing, I assume it declares the start point is happening while the mirror is still going to the start point so it could catch a “tail” for the reversal and the reversal point will be short of the correct point because we didn’t wait at the “corner” to stabilize or even reach it
Man, I ran a lot of tests do not see it running by and looping. I don’t want to burn a a lot of server space with 20 more images but POLY did not affect the Bi directional 1mm fill reverse direction. Start and Jump did.
Closest I could get for run by and loop
Need to see your images.
Ah… I believe I did that testing with the new “release candidate” for LB.
Are these not actually machine parameters that get stored on the machine? Are they just a driver software thing and LB just chose to try to make it work like EZCAD?
Maybe they are defined in the machine and auto-applied when the right scenario comes in from the PC, and it’s because LB is sending the job with “different” ways to use the available low-level commands the BJJCZ uses. And that’s triggering the application of some parameters inside the machine differently.
If so, I need to repeat all this with the main LB release and not the RC. I didn’t realize they could be fundamentally different at lower levels
The reason I got attached to the RC is that Image mode has rotation options that don’t exist in the official release yet
I have both on the machine, next time I’ll run it with the new candidate.
The latest RC didn’t make any difference in my overrun/ overscan tests. Really like to see what you were talking about.
Here’s where I lowered the freq so basically I can measure time by pulses.
This is a bidir Fill with 1mm spacing and only tall enough for two lines.
The top has PolygonTC set, the bottom has it at zero.
Good timing
Now I think I broke Discourse. Whatever photo I try to upload, it is using the
“endtc100polygontc100” file name and only shows that file. So odd, any way I can think of to work around it still gives me the same file
We have posted about a thousand images between the both of us…
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
