Repeat marking is still glitchy and I can define what I’m experiencing. Repeat marking is flagged to reset to zero after each run. Lets say I have 20 stations, 18 degrees apart. If I run 2 items instead of all 20, the next time I bring up repeat marking, the dialog box says I’m at 36 degrees, not zero even though the rotary did indeed return to zero. If I reset to zero without closing the dialog box, it backs up 2 stations before starting the run. The only way around this is to reset to zero, close the dialog box and re-open it before commencing the next run. Win11 machine, latest upgrades on all software, Ruida controller.
Thank you for reporting this issue — I will log it with our developers.
1 Like
Here is a video explaining the situation.
I realize it’s been a while since reporting this, however this bug has now been fixed for 1.7.00.
For what it’s worth, if you didn’t reset the position back to zero, it would just start where it was and run from that position forward.
The repeat marking window does relative moves with the rotary axis, so it doesn’t have “wrap around” behavior, so the “return” move sends a relative (negative) move back to the start, which is why when you exit and come back the axis is showing a non zero value.
Oz, does the repeat marking fix you mentioned coming in 1.7 also resolve the Set Zero issue where repeat marking has to be closed and reopened to properly take effect?
I’m using an IndexX linear table with 1.6.00. If I open repeat marking, do a small jog movement to offset away from the end stop, press Set Zero, then start the job, it first reverses back to the original position and starts from there instead of the new zero. Closing and reopening the repeat marking window before we start the job starts from the new correct position.
I may have just explained exactly the same thing as the OP. 
My observation is that it reverses to the “non-zero” degree value and starts from there.
Yes. Repeat Marking in LightBurn uses all relative moves, which technically aren’t a thing. Before each move, I issue a “reset to zero” instruction, then issue the move in relative steps. If you close and re-open the repeat marking window, you’ll see the result of the last relative move.
That said, wherever you start from is what LightBurn treats as zero, so you don’t need to zero it at all - you can just start working and leave the slightly odd values in that position window, but I did also fix that bug, so if you Set Zero, it resets the internal position correctly and doesn’t issue that first move anymore.
Thanks Oz. I made a video yesterday showing the offset move bug after zero, but it sounds like you’ve already fixed it. Here’s the link anyway if you’re interested.
Hello, I have a 900mm M6 Course linear rail that I want to use on my 5w UV Laser and I’m trying to figure out the repeat marking. How do you calculate the degree increments to go a specific distance say for this example I want to move 50mm at a time, and It’s 1mm per rotation?
It’s been several months since I reported this and I’m currently running v1.7.04 (January 2025). The problem persists. Unless I select “Set Zero” before closing the Repeat Marking dialog box, the next time I open it, the position is not zero, but rather the increment or jog number. I use Repeat Marking for long runs of 20 position, double sided parts so I’m constantly closing and re-opening the Repeat Marking feature. It should be noted that when I finish a run of 20, the position reads zero, but when I close the dialog box to adjust which layer it will engrave, it is no longer zero unless I selected Set Zero before closing. Please look into this again.
Why not click ‘Set Zero’ after you open the dialog, as that’s what it’s intended for.
For me, when I run a repeat marking job, it doesn’t matter what the “Pos” value is - when I start the run, it starts from wherever the rotary is positioned, and returns to that position at the end.
Are you saying it’s not doing that for you? I made one change to the code that handles this when you initially reported it, and that change is in the current release.
I can work around the behavior that I’ve reported and videoed. I prefer to drop the subject.
I’m trying to understand if it’s actually a problem, or it’s just showing the “Pos” value differently than you expect.
The Repeat Marking window was updated to use all relative movements, which means it never has to “rewind”, meaning that you can do much longer runs than you could in the past without having to wait for the rotary table to rotate the opposite way all the way back to the start.
When you first open the Repeat Marking window, the current position is recorded, and all moves are done relative to that, so it should work as you expect if you just ignore what the ‘Pos’ value is set to. It’s only really meaningful if you reset it.
I think it’s more of an inconvenience rather than a problem.
When setting up a job there is often a few open and closes of the repeat marking window to adjust or change something in the layout. If the table is not at the original zero position when the window was closed, pressing ‘set zero’ on opening makes the origin in the wrong place. Because the position value has changed the ‘go to zero’ doesn’t go back to the right spot either, so you have to manually realign or jog back to the first position.
For rotary tables where every position is identical and the starting position can be anywhere, it doesn’t really matter. For linear tables, or for processing double sided items where you need to keep track of the physical origin (first marking position), it would be a lot better if the the current position was retained on closing and reopening the window. As far as I can tell it re-opens with the reference position from one move prior to last.
Once the job is setup and running, repeat marking works brilliantly.
Here’s a video which might show it better with some context.
I don’t know if it is indeed a problem or a matter of interpretation on how I expect the rotary to act. I have a numbered 20 position fixture that change names each time the rotary indexes. When I finish a run, I remove the items and place them in labeled boxes starting at number 1. However, you are correct in stating that it shouldn’t matter because I could remove the items starting at any fixture number by looking at the names instead of the number. Your software has made me a lot of money because I can take jobs suitable for rotary index fixtures that read a CSV file for it’s data. Thank you for your effort to communicate how this should work.
1 Like
In the case of linear axis output, where we absolutely do need to “rewind” at the end, this makes sense, so I’ll need to think about how to address this better.
Using repeat marking with a rotating table, I don’t want to have to rewind at the end if I can avoid it, because it wastes time. I have to figure out what the range of the actual internal step counter in the hardware is. It looks like it’s 31 bits, with a sign bit.
If that’s true, then with 128,000 steps per rotation, you’d be able to do 16,777 full rotations before you hit the limit and it wrapped around. If you ever do hit that limit, you’d have to wait for it to rewind all 16,777 of those, and that’s what I’m trying to avoid.
If the hardware only internally stores 24 bits for the count, then the limit would drop to 131 full rotations before having to rewind (again with the 128,000 steps per rot). With a decently large bulk job, I can actually envision someone hitting that and being surprised by it.
Most don’t have their motor step counts that high, so if you’re using 12,800, for example, all the above limits multiply by 10 (167,770 and 1,310, respectively).
I know this is getting into the weeds a bit, but I have to think about stuff like this because some people actually do use these things like this and we have to try to make it general enough to work for all the weird cases.
I might actually be able to let the user choose, or I could just have a “reset position” button in the window that you could hit to re-zero it if the numbers get out of hand, but I’ll need to mess with it and see what works.
2 Likes