GCodes for the next-generation Duet

dragonn

What about making groups of commands? Like for example:
Hnnn - anything connected with heaters
Snnn - anything connected with speeds
This should not add a big overhead in the software but would be already make it more readable.

fcwilt

@resam said in GCodes for the next-generation Duet:

How sophisticated is the current g-code parser in RRF?
Would it be possible to make the M1000 a bit more self-describing, by adding a string identifier? for example:

M1000.fans P1 ...
M1000.heaters P1 ...
M1000.filament_monitors P1 ...

I fear that all those M1000.1 -> M1000.42 numbers become yet another random number everybody has problems remembering and identifying when reading through a config.g file...

Remember the details can be difficult at times.

I add comments to each line so when I come back at a later date it jogs my memory.

Frederick

wilriker

@dragonn said in GCodes for the next-generation Duet:

What about making groups of commands? Like for example:
Hnnn - anything connected with heaters
Snnn - anything connected with speeds
This should not add a big overhead in the software but would be already make it more readable.

I like this idea! It would take some refactoring but as stated elsewhere, I offer my help for coding. I am a Java and Go developer in my day job and C++ is not my main language but I think I know it good enough to get good results as long as someone more experienced is doing code review.

deckingman

@dc42 said in GCodes for the next-generation Duet:

Here's a early draft proposal for new GCodes to create fans, temperature sensors, heaters and filament monitors. I have used M1000 as the base code for this, but it could instead be e.g. M594 or something else.

M1000.1 Create temperature sensor
M1000.2 Create heater
M1000.3 Create fan
M1000.4 Create endstop group
M1000.5 Create Z probe
M1000.6 Create filament monitor
M1000.7 Create general purpose output (for use by M42, M452, M452)
M1000.8 Create servo output (for use by M280)

Parameters:

Pn Index of the thing being created, e.g. 0, 1, 2...
A"name" Optional name of the thing being created, e.g. "Bed heater"
Dn Input/output terminal ID(s), e.g. 0, 2.1, ...
Fnnn PWM frequency, if applicable
In Invert/don't invert output, if applicable

Other parameters as required for the thing being created.

Thoughts? We could have a "Create axis" command too, however I think M584 does that well enough already.

My opinion probably doesn't count for much but personally, I think this is awful. It's a whole other bunch of codes to have to use and learn and none of them make much intuitive sense. So for us non-writers of code and especially for new users of Duet, it's going to add to what is already becoming too complex. I understand that with increased functionality comes increased complexity but there has to be a better way.

If we are stuck with using existing codes and parameters, do we have to use all alphanumeric characters? How about using existing codes to denote the "what" but with the "@" character to denote the "where"? e.g M305 @ n.n P0.... etc

dc42

Here is some background.

Currently, heaters and fans exist already when the firmware boots up because there is a fixed number of them. Filament monitors have to be created (M591 both creates and configures them), so do axes beyond X, Y and Z (M584).

Configuring additional temperatures to display in DWC or to control fans requires the somewhat messy "virtual heaters" concept. This is because currently, configuration of a temperature sensor is done by configuring a heater that uses that sensor. So in the new firmware I want temperature sensors to be created and configured independently of heaters.

With the next-gen Duet, creation of heaters, fans, sensors and GPIO pins will have to be done explicitly, because some configurations might need a large number of them and other configurations only a few. This means we need a mechanism to tell the firmware to create these items, either using new GCodes or using some other mechanism. From a firmware perspective, GCodes is easiest because the code to parse them is there already; but we could use some other mechanism.

My draft proposal was aimed at making the new codes easier to remember or at least to look up (by making them all sub-codes of M1000) and to use a consistent set of parameter letters within them.

There are ways we could avoid introducing new GCodes. Fans could be created by adding yet another parameter to M106. Heaters could be created by the M307 command, if I added a parameter to specify which temperature sensor to use (replacing the X parameter in M305) . M305 would be used to create temperature sensors, not heaters. But I feel that M106 already has too many parameters, and changing what M307 and M305 do would be more confusing that adding new rationalised GCodes to create items and leaving the old commands doing most of what they do currently (i.e. configuring things that already exist).

fma

Whatever syntax is used, I think it is a good idea to split creation of devices and their usage. M106 should only set the the fan speed. All M-Codes which do both are very confusing to use, and params not easy to remember.

If from a firmware point of view it is not possible to use a more advanced parser with plain english commands/params, then we should stay close to the current G-Code syntax. Using the . (dot) to split (or group) commands/params is a nice idea.

So, using M1000 to create stuff is OK. A question: will it be possible to dynamically remap a device? With M1000? Or another M-Code?

dc42

@fma said in GCodes for the next-generation Duet:

Whatever syntax is used, I think it is a good idea to split creation of devices and their usage. M106 should only set the the fan speed. All M-Codes which do both are very confusing to use, and params not easy to remember.

Thanks, it seems that you agree with me.

If from a firmware point of view it is not possible to use a more advanced parser with plain english commands/params, then we should stay close to the current G-Code syntax. Using the . (dot) to split (or group) commands/params is a nice idea.

The problem with a "plain english" parser is, what exactly constitutes plain English? Whatever definition I adopt, user s are bound to think of different ways of expressing the same thing that "ought" to be accepted, then we have the need to accept both English and American spellings. So I might end up spending a lot of time improving the parser, when it is more important to implement new firmware features. And how much would it help those for whom some form of English is not their native language?

So, using M1000 to create stuff is OK. A question: will it be possible to dynamically remap a device? With M1000? Or another M-Code?

My initial thought was that dynamic remapping would not be allowed; although it could be if it turns out to be useful. There will be some concepts that can be remapped, such as the "print cooling fan" (i.e. the fan whose speed is set by M106 with no P parameter) that can be mapped to different fan numbers at different times.

deckingman

How would we go about defining tools and stuff like mixing ratios?

dc42

I don't see any need to change how tools and mixing ratios are defined. It's things that relate directly to I/O pins that need to change.

deckingman

@dc42 said in GCodes for the next-generation Duet:

I don't see any need to change how tools and mixing ratios are defined. It's things that relate directly to I/O pins that need to change.

Ahh OK. Light is beginning to dawn.......
BTW I like what you are planning to do with temperature sensors being independent of heaters.