meerk40t: [Bug]: Settings not Saved / loaded

Summary Description

The Device Settings wont be saved / loaded correctly

Additional Details

I have configured 2 devices one named K40x an one K40 rotary. Since engrave one type of glas on regular basis I wanted to setup one config for “normal” operations and one for rotary, so i can just switch to the 2nd device without changing all the settings every time.

It saves both devices but not the rotary settings of the 2nd device.

I already tried to change the settings manually in c:\users\username\AppData\Local\Meerk40t\Meerk40t.cfg by changing the following: [lhystudios1] registered_path = provider/device/lhystudios name = LihuiyuDevice extension = egv label = K40_Rotary board = M2 source = co2 user_scale_x = 0.9786 user_scale_y = 0.9786 flip_x = False home_right = False flip_y = False home_bottom = False swap_xy = False autolock = True plot_shift = True strict = False twitches = False opt_rapid_between = True opt_jog_minimum = 256 opt_jog_mode = 0 rapid_override = False rapid_override_speed_x = 50.0 rapid_override_speed_y = 50.0 fix_speeds = False rotary_active = True rotary_scale_x = 1.0 rotary_scale_y = 0.386

When i now start Meerk40t it loads the K40_Rotary device but not the rotary setting as in the cfg.

Crash logs

No response

MeerK40t Version

tested with 0.8.700 and 0.8.600

MeerK40t Type

Executable

Your Operating System

Windows

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 31 (18 by maintainers)

Commits related to this issue

Most upvoted comments

The network protocol for the M2 Nano hasn’t changed in a very long time. It should actually work with massive version differences. Like 0.7.x stuff for the raspberry pi shouldn’t have an issues. It’s literally just sending raw characters of the data that the laser should send. And could almost be stand-alone for that stuff.

https://github.com/meerk40t/meerk40t/releases/tag/0.8.8000

Has the correction too. Since it’s only dealing with bug fixes and no new features will get added to the 0.8.x series it should be fine.

Okay. I pushed 0.9.0006 (0.9.1 Beta 5) and it should correct this issue.

Well, there’s other devices, like if you run an ezcad2 fiber laser it’s not that much more than the rest of the setup and controlled with the regular board. And it has it’s own sorts of commands and doesn’t replace an axis. Some other grbl devices equally can let you run the rotary without taking up an axis. Then you have x, y, and rotary axis each is independent and there’s some paradigm shifts which makes that setup very unlike other setups.

It gets progressively more difficult when thinking about more and more potential setups which sort of lead to decision paralysis and thus the decision to just hack in the axis replacing rotaries at a minimum and deal with the others issues later.