Configuration in JSON instead of GCODE

BoA

Just an idea.

If configuration g code is reflected in Object Model, it would be possible to configure firmware using json representation of the values in model.

This would also make possible to direct integration/config exchange with RRF config tool.

Phaedrux

I believe that is coming soon as part of the move to the object model. The config tool will be getting an overhaul and will be able to handle more complex configurations more easily. So you're on the right track.

arhi

I hate the idea

I don't mind "alternative ways of changing the config" but the main / primary way of changing config must be GCODE. That's where RRF is in front of everyone else. Move any of it to json/xml/othercrap and you go back to klipper/smoothieware/redeem... way of doing things, and if there's one thing they all envy RRF users is the GCODE configuration

PCR

+1 for gcode based configs!

droftarts

I don’t think the intent is to replace Gcode configuration with json onboard the Duet, at least it hasn’t been discussed, though perhaps it could be offered alongside. It’s more that a OM model can be exported as a json, and imported into the configuration tool to make changes.

Ian

arhi

@droftarts I see it as a recipe for troubles even if available in parallel and not the only way

MikeS

Why not handle G-code configuration on RRF config tool. It shouldn't be so hard to parse the gcode. At least the main configuration can be loaded on the tool and new features to be configured can be highlighted (same way repetier does)

Phaedrux

@arhi said in Configuration in JSON instead of GCODE:

@droftarts I see it as a recipe for troubles even if available in parallel and not the only way

The config tool is very limited right now, allowing it to generate a config using the object model allows for a lot more flexibility on the types of configurations it can create. This doesn't change the normal operation of the duet or RRF, so I don't really see the source of your concern.

OwenD

If the printer were to output a json file that gave any indication of what was connected to it (out of the box) then I can see how that'd be a big help for the configuration tool.
But as it doesn't know what's connected until you configure it, then we have a chicken vs egg scenario don't we?
Using any manually created json file would be a help desk nightmare.
The chances of newbies (to json) getting the indentation right are practically zero.
I'm failing to see the usage case?

BoA

@OwenD IMO JSON is easier to validate than G code, and what concerns indentations - it is not part of JSON format, therefore indentations can be basically ignored.

Also IMO something like this:

{
    "key": "sensors.probes[0]",
    "result": {
        "calibrationTemperature": 25,
        "deployedByUser": false,
        "disablesHeaters": false,
        "diveHeight": 5,
        "maxProbeCount": 1,
        "offsets": [
            -23,
            -34
        ],
        "recoveryTime": 0,
        "speed": 5,
        "threshold": 500,
        "tolerance": 0.03,
        "travelSpeed": 400,
        "triggerHeight": 1.925,
        "type": 9,
    }
}

is more human friendly to read/edit than G code. But perhaps that is just me.

OwenD

@BoA
I stand corrected WRT indentation, however it still requires correct syntax and formatting, so my statement regarding help desk problems for new users would stand.
I agree, reading it (once it is created) is relatively easy, but manually configuring it in the first place is fraught with danger.

arhi

@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

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.