Configuration in JSON instead of GCODE

Phaedrux

@arhi I think you're jumping to some conclusions that aren't warranted. Gcode as it's used now isn't going away.

droftarts

@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

arhi

@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.

Phaedrux

@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.

arhi

@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

dc42

@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 structure

than 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.

arhi

@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.

T3P3Tony

@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

@T3P3Tony I really have no clue what's planned but original post asks for

to configure firmware using json representation of the values in model.

I really can't understand this other than CONFIGURATOR ==(JSON)==> RRF

@Phaedrux said that it is planned and I think that would be a bad idea.

Phaedrux

@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.