I have the problem that the speed for move commands in the move window is reset to 0 each time I start the program. I have seen that this issue has been reportet already several times, but could not find the solution in these reports. Where can I find it ?
Many thanks and kind regards
Franz
Jess,
I was sooooo hoping that was it, but no joy. I turned the switch on, set the Speed setting in the Move window to 2500 mm/m, saved the currently open file, and exited. Upon reopening of LB v2.0.05, the Speed setting in the Move window, was again Zero. No change when reloading the saved file either.
Please escalate or document as a bug so it gets fixed in a future release.
Mikey
P.S. I am curious if anybody else has a case where the Speed setting is modal between instances.
I’ve had the same problem since I switched to the new setup. When I changed computers, I started having this same problem that I’ve already reported somewhere, but I haven’t yet looked into the cause intensively.
I’ll check if the cause is the option you suggested.
Thank you Jess.
I had this button not active, but unfortunately, it did not change anything. The move values are reset to 0 on each new start on my computer, since I made the update to the 2.0.05 version. However, I left it active now for a possible future solution. It is not a big deal, but would of course be nice if it worked again.
Kr Franz
@bernd.dk is correct. I just checked RC9 and the Speed setting was saved. It appears it has been fixed, we just have to wait for the production release. 
So, this weekend I follow the Jess’s suggestion but LB doesn’t save the speed setting.
The problem lies in the speed, which always fails to save the specified value when LB is terminated. In other words, when LB is started, this field is set to 0 (0 speed), and when attempting to move the laser head, an error occurs, requiring a value to be entered in the “speed” field of the “Move” window every time LB is initiated.
The speed holds for me as well, I just checked and it’s still the same as when I posted the image above
The values in the move window are saved in the perfs.ini file,
which is then backed up as perfs.ini.old file,
which is then moved to the backup/perfs folder and saved as date_time.lbprefs file ***
You can open the perfs.ini file with any text editor (Notepad, Notepad ++).
You can find this file in LB by going to File > Preferences > Open Perfs Folder.
Once the file is opened do a Find/Search for the word “distance” and you’ll find
"MirrorX": false,
"MirrorY": false,
"MoveJogDistance": 25,
"MoveJogFromOrigin": true,
"MoveJogSpeed": 100,
"MoveJogZDistance": 10,
Change the value after “MoveJogDistance” to what ever number you prefer (keeping the same format) then save the file and see if this works for you.
*** I find this annoying because if you don’t clear this folder one can have hundreds if not thousands of .lbperfs files
That sounds like a good tip!
Thank you very much!
I forgot to mention that the #100 below is a percentage
"MoveJogSpeed": 100,
I’m guessing that the speed setting may be related to this screen.
I believe 100 is 100mm/s. If you want to set the speed to 4000mm/m you have to set it to 66.666… And if you have more than one device you have to find the correct one…
You might be right and I’m wrong.
I played around with all those numbers and nothing changed in the Move Window
I found this in my Prefs.ini. You need a Magic Decoder Ring to make sense of the file. The numbers in bold below exceed the measurements for any of my machines:
“LastProjectPath”: “C:/LightBurn/Projects/Boxes/Garage Key Holder 3mm”,
“LastUpdateCheck”: 120,
“LoadDefaultCutLayers”: false,
“LockAspect”: true,
“LooseColorMatch”: true,
“MachineSettingsPosX”: 442,
“MachineSettingsPosY”: 96,
“MachineSettingsSizeX”: 485,
“MachineSettingsSizeY”: 605,
“MatchToolLayerColors”: false,
It seems that continuous jog is the culprit.
If you have speed Jog speed issue try disable Continuous jog, set a distance and speed. Don´t enable Continuous jog again or it will clean the speed.
THAT explains why it would sometimes save and sometimes not, but I could never pin it down.
@LightBurn , @parsec deserves some sort of reward for this one. And please fix it in the next release?
Interesting, nice spotting @parsec!
Well the good thing is that it is not reproduceable in the latest public release candidate so it’s definitely on it’s way out.
Confirmed!
