I am experiencing a very large difference in run time for what should be the exact same markings and would like to know why. In other words, there is supposedly no change in anything (scan angle, no rotations, etc…) that would account for this large difference. Other than changing the focus of the program window in Windows, I cannot see anything different happening. (In other words, clicking to work in email, or browser, or excel, etc… and letting LB run “in the background”.)
Given that we cannot see those designs, it’s difficult to find the reason for any differences.
Based on nothing more than the information you provide, I expect the two designs differ in some way you think doesn’t matter, but which force the controller (or LightBurn’s path planner) to process quite differently.
Upload the two *lbrn2 files so we can see what’s going on.
I have not made myself clear. Apologies for that. To clarify - there is no “other” design. There is no “other” file. This is marking the same file, repeatedly. And without changes of any kind or manner.
As well, to further update - I have continued to run the file and tested the results. If I do nothing but continue to run the file by hitting the foot pedal/switch ( and not touching the computer ) the results are within 1 second of each other. However, if I continue marking by hitting the foot pedal/switch and then changing the screen of the computer by working in another program window ( like reading an email received earlier in the day, or reading an already opened PDF ) LB will take SIGNIFICANTLY longer to accomplish this exact same task.
So to make sure that I’m understanding you correctly - you think that the other programs on the computer are bound to the processor and are taking priority of the key processor resources in such a way as to make LB run with less, and thus slower. Do I have that correctly?
Kind of. I’m saying your CPU may be heavily utilized and thus behaving differently if running in the background with other applications taking precedence.
I’m just speculating as one possible cause to the behavior you’re seeing. Checking Task Manager should quickly either refute or support the hypothesis.
Thanks for the insight and explanation. I will make some tests shortly and report back. I am going to lean heavily against it being that, as when this occurred the computer was definitely NOT heavily utilized. This machine happens to be my main CAD/CAM/Business computer, is over-configured accordingly, and there were only four program windows open at the time. However, I am glad to test this theory.
As well, I continued to test yesterday afternoon with only Lightburn, email, and a browser open. Triggering LB to begin and waiting, the marking took a predictable 14:22. Once in a while it would take 14:23. Triggering LB and then simply changing focus window to read emails (no sending, recieving, or even composing) causes LB to increase time required by nearly double. (approximately 90%) The same results for reading a web page that is already loaded, with no inputs or network traffic occuring. (ads blocked, no scripts running, static page, etc…)
Having said all of that, I ran the test just now. Nothing to report of any consequence in Task Mgr. CPU never went above 3% and memory never over 11%. Regardless of which way computer screen focus was oriented. (LB or other program) However, LB still takes nearly twice as long when not left focused in LB. Also tried it with CAD & CAM open and running and this has no noticeable effect.
Just seems very odd to me and want to find out why. How now Brown Cow?
It does seem that way. (has reproduced the few times that I have consciously tested it)
That’s a good question. Initially, the run times were indeed noticed due to the displayed run time from within LB. ( as exemplified in the original post’s pics ) However, the reason that I even bothered to look at them was because after I felt that certain amount of time had elapsed, it became clear that I was still hearing laser sounds when I expected that they would have been completed by that time. This was then verified in following tests, using my wrist watch. ( do people still use those? )
That’s a very good question. One that I do not have an answer to, because I have not been visually watching the burn. However, I can say that during one of the times the slowing happened, I did switch back to focus on LB and the resultant time was indeed longer than the “normal” time, but similarly less than the time used when I left focus on another program until LB was finished. ( was that stated clearly enough? )
I will have to check on that one for you.
It is a 30W galvo fiber with Max source and BJJCZ board, connected via USB. We’ve had it a few years and it has always run very solidly if I take the time to learn things. It was purchased as a complete machine, but is not one of the common distributors. There was one anomaly when new that I doubt has any relevance to this but I will mention it in the interest of being thorough. When originally purchased (with EZCad2) the seller was a scammer that scripted some kind of ransom/pay for use into a non std version of EZCad, so there was a nag screen after 20 initial uses. We uninstalled that version, rolled the (previous) computer back to pre-installation, and installed a real version after. Never had any issues ( other than my own ignorance ) after that.
I cannot speak to EZCad function, as it was not reinstalled when we acquired these computers. We had already switched to LB so had no reason to have EZCad installed again. I will run another set of timed tests to verify for you and post the results. To clarify - when you say “wall-time” I am assuming that you mean some external time keeping device and not the displayed time within LB. Correct? ( So my wrist watch is an acceptable indicator. )
If this happens only when using the rotary, then yes, I can understand why this happens, but it’s a bit technical to explain why.
It’ll be worse when using tiny split sizes. Basically, each slice of the job sent to the rotary gets run by the machine, then the software waits for that to complete, tells the rotary to move, waits for that to complete, sends the next slice, and the process repeats. Each time the software waits it is awaiting for messages from another thread, and because of the way windows works, the thread waking up to check for that event will take longer if the application is not the one in focus. It’s probably on the order of 30ms of time difference, possibly longer, because of how Windows handles time slicing and wait states, but because the split size is so small those delays will add up.
With a slice of 0.03mm, every millimeter of job takes ~33 slices, and 30ms of extra wait for each of those would be an extra second, then double that because there are two “waits” per slice (one for the laser and one for the rotary).
(Edit: the extra wait time might be higher depending on how many cores your machine has, how much RAM, how much it has to swap out to disk, and numerous other things - a task switch can be nearly instant in some cases, or seconds if the machine is busy)
Something that I plan to change in the way, Lightburn is architected is having the moves for the rotary managed by the same thread that sends the slices to the machine, so that it’s not bouncing back-and-forth between two different threads, and that will improve the performance.
Thank you. I appreciate the efforts. It’s running an “out of focus” test right now. ( while I type this ) and it is indeed running WAAYYYYY behind. ( longer run time ) We’re past 22 minutes already and still running. Time matches my watch.
Okay. Question answered then. Thank you. My main intent was to make sure it isn’t something dumb that I am doing to cause this, and it is a known issue. Basically we need to make sure to stay in LB and not multi task other work in the shop to maximize marking times. I’m sure it’s no small feat to change the architecture as you’ve described, but have you got any guesstimate as to when you might be able to accomplish this? Easy to see how this can really throw a wrench in the works when one might have 100 - 500 of these to accomplish. Actual marking time goes from 24 hours to 48 hours just for 100 pieces if one doesn’t maintain that focus. Thank you. I appreciate the efforts and resposes.
Yes. I don’t mean strictly a wall clock. I suspect that’s an industry convention of speech I picked up at some point and never adjusted.
But this is moot given Oz’s explanation.
Does this mean that performance for this is OS dependent then? Meaning that Linux or Mac would likely behave differently here based on how thread priority is managed?
The simplest way to reduce the effect would be to increase the slice size. Even going from 0.03 to 0.1mm would reduce the number of waits by a factor of 3, so you’d see a considerable reduction in the time difference.
The architecture changes to push everything into a single thread are significant and will require a lot of testing, so it’s not going to happen quickly. I’m hoping within a couple months, but this isn’t a “feature” and the overall impact isn’t going to be massive, so it’s not a huge priority for us.
)
)