Configuration in JSON instead of GCODE
-
@Phaedrux very simple, "a client" brings me a printer with issues, going through all the gcode that can change the config is not super easy but is rather straight forward, you now add a second path that can influence config - not very welcome IMHO ...
wrt configurator, imho it needs to be able to
- store configuration locally as whatever structure X
- it needs to be able to export that structure X as a GCODE config
- it needs to be able to parse GCODE and execute it modifying internal structure X
- it needs to be able to connect to printer and query config to update local structure X (using GCODE imho but I could not care less about what protocol it would be using and what data format, but only "one way", from printer to config, not from external app to printer)
I'm not doing it so whatever you guy's do you probbly know why you are doing and I for sure won't move to klipper from RRF because you add this type of behavior... I just kinda see it as a potential source of a lot of grief
-
@arhi I think you're jumping to some conclusions that aren't warranted. Gcode as it's used now isn't going away.
-
@Phaedrux said in Configuration in JSON instead of GCODE:
@arhi I think you're jumping to some conclusions that aren't warranted. Gcode as it's used now isn't going away.
Exactly what I was going to say. There's been zero internal discussion about replacing gcode config with OM. @Phaedrux was referring to making the configuration tool better, perhaps not realising the extent to what @BoA was suggesting.
An OM json output could also aid troubleshooting.
Ian
-
@droftarts I don't see how would RRF's ability to read json config make the configuration tool better. If you are not going to generate the GCODE config it will make the tool worse, if you are going to leave in the GCODE config generation why bother wasting time developing this addon to RRF so it allows you to change the same thing in 2 different ways.
@Phaedrux being a developer for more than 35 years I'm not inventing a hot water, just remembering stuff that already happened. But since most of the ppl working on RRF are not new to the game I don't feel the need to "push" on any of that, I said what I think and I'm done, whatever is decided is decided, my level of involvement is so insignificant that makes even this reply unwarranted... but when I'm already replying .. lemme put it like this ... when you have 2 ways of doing same things you give yourself twice as much work to maintain that code, every time you change thing you need to do it twice, every new implementation needs to be done twice using up twice the time to develop and twice the time to test... after a while a feature will come that's super easy to do one way but hard to do other way so you will implement it in first way and not in second "just to test and see and we'll implement in other path too next week" and you start to diverge and very soon after that you become having problems, the paths diverge more and more and.... I'v seen it in many projects in different products in past 3+ decades, granted, my work is usually solving problems so most projects I do see are the ones with problems (if the project is going on ok they don't need to call me in to organize fixing it
) ... and I'm telling you, just like designing API call that return a list/array and does not support paging is bad idea even if you are sure there will never be more than 10 items, making 2 separate paths to change configuration without a real need for it is a bad idea. -
@arhi The goal is the improvement of the configuration tool. Beyond that we are both just speculating. Stay tuned for more details, but from the perspective of the end user, nothing will appear different.
-
@Phaedrux said in Configuration in JSON instead of GCODE:
@arhi The goal is the improvement of the configuration tool. Beyond that we are both just speculating. Stay tuned for more details, but from the perspective of the end user, nothing will appear different.
in order to improve configurator you need to be able to
- export config from RRF (attm that's possible)
- load that config into configurator (not possible attm)
IMHO it is waaaaaaaaay better to implement G-Code parser into the configurator so it can both
- read your .g files from the sd card and form internal config structure
- send G-Code to the printer and parse the result to fetch the config and form internal config structure
than to add json to the mix.
The ability of RRF to load json config generated by the configurator is making configurator worse, not better.
The end-user, well depends how you look at it .. but I said my piece really nothing to add
-
@arhi said in Configuration in JSON instead of GCODE:
IMHO it is waaaaaaaaay better to implement G-Code parser into the configurator so it can both
read your .g files from the sd card and form internal config structure
send G-Code to the printer and parse the result to fetch the config and form internal config structurethan to add json to the mix.
We already have a GCode parser in RRF, and a way of converting that to JSON i.e. the object model. It wouldn't make sense to write the whole thing again, and have two separate GCode processors that have to be kept in sync.
The ability of RRF to load json config generated by the configurator is making configurator worse, not better.
We have no plans to do that.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 said in Configuration in JSON instead of GCODE:
The ability of RRF to load json config generated by the configurator is making configurator worse, not better.
We have no plans to do that.
Well that's the only thing I'm against. But that's what original post is about:
possible to configure firmware using json representation
I believe that is coming soon as part of the move to the object model.
-
@arhi to be clear the idea is once you have a representation of a machine in the object model, the way to get that representation into the config tool will be JSON, not through having the config tool parse gcode. Output from the config tool, i.e. gcode files, to use on the duet is not planned to change.
-
-
@arhi sorry for leading you astray. I said he was on the right track not that everything he said was 100% going to happen. All I was confirming was that the config tool is planned to become more flexible.
