lane_data: Adding lane data module to assist in getting filament loaded in filament changers

[jimmyjon711]

This is another feature requested by AJAX3D to aid in a common API for filament changers so that third-parties like slicers can fetch data about what is loaded and automatically use this data when slicing. AJAX3D has been in talks with Softfever to add this fetch functionality into OrcaSlicer.

This has been tested by multiple testers in a development branch of AFC-Klipper-Add-On.

Signed-off-by: Jim Madill [email protected]

[Arksine]

Thanks. Before I get into a detailed review, have you considered using the Database APIs to store and retrieve this data? There is really no need for an additional component to perform this task, and an additional benefit is that the data is persistent across restarts.

[jimmyjon711]

Thanks. Before I get into a detailed review, have you considered using the Database APIs to store and retrieve this data? There is really no need for an additional component to perform this task, and an additional benefit is that the data is persistent across restarts.

Good point, this did not originally cross my mind when we were discussing this.

[jimmyjon711]

Guess the only real upside to this module is that there will be a documented API that holds a common structure so third-parties know what information is available to pull down and use, and other klipper addons/plugins know what information to push up.

[Arksine]

The documentation could be added to the AFC project directly. Presumably developers would need to refer to it for other information if they want to integrate support for AFC in their front-end and/or slicer. The Database APIs were created for persistent data storage and information sharing between clients, so at this time I believe that the best approach would be to use them.

The database is used in a similar fashion to store common webcam data used by clients. Later it was necessary to add a component wrapping the stored data, as we wanted to extend functionality such as adding webcams in moonraker.conf, testing webcam urls, etc. If in the future some extended functionality is required using lane data I am willing to revisit adding a component.

[jimmyjon711]

The documentation could be added to the AFC project directly. Presumably developers would need to refer to it for other information if they want to integrate support for AFC in their front-end and/or slicer. The Database APIs were created for persistent data storage and information sharing between clients, so at this time I believe that the best approach would be to use them.

The database is used in a similar fashion to store common webcam data used by clients. Later it was necessary to add a component wrapping the stored data, as we wanted to extend functionality such as adding webcams in moonraker.conf, testing webcam urls, etc. If in the future some extended functionality is required using lane data I am willing to revisit adding a component.

We can do this for now, we were just trying to push something out there that was not necessarily tied just to AFC-Klipper-Add-On.

[Arksine]

Perhaps we can provide some documentation in Moonraker for 3rd party namespaces, including specifications for the structure. integrations.md might be the best place to put it, let me give it some thought.