search

p3p / MarlinSimUI

Marlin Simulator UI
Other
9 stars 11 forks source link

More API updates, configurable HAL path, etc. #30

Open thinkyhead opened 1 year ago

thinkyhead commented 1 year ago

- A few more updates to match Marlin case / API changes. - HAL path configurable by a build flag and MARLIN_HAL_PATH macro, for easier adaptation to any future Marlin HAL path updates. - Define missing LCD_PINS_EN as LCD_PINS_ENABLE for compatibility with old and new Marlin. - Replace follow_mode numerical constants with FollowMode enumerated constants.

thinkyhead commented 1 year ago

Once confirmed to be good, changes in the MarlinSimUI/bugfix-2.1.x branch should be merged to the main branch and given a new version tag that we can use in the native.ini file. This way Marlin can simply refer to the version tag, ensuring that forks of Marlin won't break as upstream/bugfix-2.1.x acquires changes that haven't yet been propagated to forks. This also spares us the additional release step of having to to edit native.ini to point to the latest MarlinSimUI version tag, as the INI file will already be pointed at the appropriate version.

That said, there probably won't be any more changes that would require a new version for a long while. This particular code is doing well for all our needs, especially for LCD UI fixes and updates. Thanks again for creating this very helpful simulator!

p3p commented 1 year ago

The MarlinSimUI/bugfix-2.1.x branch is here to follow Marlins bugfix branch because any change to Marlin can break the build. A fixed release will probably only work for a month or two.

p3p commented 1 year ago

Cherry picked the fixes, I don't want to mix Marlin state and physical state in the component list, as the component list is showing what the state Marlin should be detecting is, not what Marlins state is.

We should probably add a new panel for all the interesting internal state.

thinkyhead commented 1 year ago

The MarlinSimUI/bugfix-2.1.x branch is here to follow Marlins bugfix branch because any change to Marlin can break the build.

Our INI files currently just point to the HEAD of the MarlinSimUI "main" branch, so as that HEAD changes it breaks all the versions of Marlin that are floating around. If there are version tags on MarlinSimUI so that our INI file can specifically refer to the version tag that is working, then we can guarantee non-breakage of older versions of Marlin as the MarlinSimUI "main" branch changes. That also applies to bugfix-2.1.x. We can keep updating our INI to point to new version tags so we stay in sync with one another.

We should probably add a new panel for all the interesting internal state.

Yeah, I was thinking the same thing. Then we can see internal and sim state at the same time and easily see discrepancies. That will especially help with motion system development.