GCodes for the next-generation Duet

dc42

I am currently specifying how existing G- and M-codes will be adapted to support the next-generation Duet. One of the issues is how to address stepper drivers, heaters, fans, temperature sensors etc. on multiple expansion boards. For example, the M569 and M584 commands both have parameters that represent driver numbers. In the next generation, drivers can be on the master board or any of potentially many expansion boards.

Each expansion board will have an ID. Therefore, a driver number in a GCode command needs to map to the board ID together with the driver ID within that board. The question is, how to represent that in the GCode parameter. Here are a few options:

Driver numbers are allocated sequentially at boot time, starting with all the drivers on the main board, then all the drivers on the expansion board with the lowest ID, and so on. For example, if the main board has 5 drivers:

M569 P3 S1 ; set direction of driver #3 on main board
M569 P6 S1 ; set direction of driver #1 on expansion board #1 (P5 would be the first driver on expansion board #1)

Expansion boards IDs start at 1. To indicate a driver on an expansion board, add 100 * board_ID to the driver number. For example:

M569 P3 S1 ; set direction of driver #3 on main board
M569 P101 S1 ; set direction of driver #1 on expansion board #1

To indicate a driver on an expansion board, use <board#>.<driver#>. This sort of syntax is already used in some CNC GCode commands. For example:

M569 P3 S1 ; set direction of driver #3 on main board
M569 P1.1 S1 ; set direction of driver #1 on expansion board #1

Is one of these better than the others? What are the advantages and disadvantages of each? Is there an even better solution?

Please share your views in this thread. Whatever numbering scheme we choose should apply to heaters, fans etc. too.

gtj0

@dc42 Option 1 is most backwards compatible but option 3 is probably the best from an architectural point of view. Are you thinking that the new numbering scheme would also apply to the current versions? I.E. The second drive on a Duex5 connected to a Duet2 would be 1.1.

On a similar topic, I hope you're planning to separate physical from logical between the drives, endstops, fans, heaters, etc. I.E. The "X" axis could have drives 0.1 and 2.3, endstops 0.2 (low limit), and 1.4 (high limit), etc.

wilriker

@dc42 My personal favorite in this list is number 3. I would in this case also allow to optionally address the drivers of the main board with a 0. prefix to be able to have a consistent scheme if one wishes to do so.

Second choice would be number 2 for me.

I don't like number 1 because on a say 6th expansion board one would have to seriously calculate the number of the driver taking into account that these are indexed zero-based. That might confuse non-CS people too much and is bound to cause trouble.

JoergS5

@dc42 The more drivers, fans and heater you support the more problems with counting ("what is my P8?") will arise. So an optional labeling would be nice, maybe implemented as preprocessor. Then the user can name it as one's will and it can be displayed in the panel. It is easer to recognise "Heater Back Top" than H7.

dc42

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

@dc42 The more drivers, fans and heater you support the more problems with counting ("what is my P8?") will arise. So an optional labeling would be nice, maybe implemented as preprocessor. Then the user can name it as one's will and it can be displayed in the panel. It is easer to recognise "Heater Back Top" than H7.

So in the command you used to assign the name "Heater Back Top" to a heater, how would you specify which heater that is?

projectR3D

I think option two would be my first choice with the third coming next. Also if there will be the possibility to daisy chain more than one expansion would the drivers on the first expansion be 101, 102, 103.... while the next expansion in the line be 201, 202, 203...?

gtj0

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

I think option two would be my first choice with the third coming next. Also if there will be the possibility to daisy chain more than one expansion would the drivers on the first expansion be 101, 102, 103.... while the next expansion in the line be 201, 202, 203...?

FWIW, I think option 3 will result in even more "this is too fricking hard to configure" posts.

gtj0

Oh yeah @dc42, on the new boards you'd better make sure the silkscreen labels match the physical designator scheme. Labelling things with their logical uses on the Duet2 and Duex5 was very confusing for me when I started out.

Labelling them with their physical capabilities would be the best option.
drive
2 pin pwm out (2PO)
3 pin in (3IN)
low power mosfet (LPM)
high power mosfet (HPM)
etc.

JoergS5

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

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

@dc42 The more drivers, fans and heater you support the more problems with counting ("what is my P8?") will arise. So an optional labeling would be nice, maybe implemented as preprocessor. Then the user can name it as one's will and it can be displayed in the panel. It is easer to recognise "Heater Back Top" than H7.

So in the command you used to assign the name "Heater Back Top" to a heater, how would you specify which heater that is?

I would take option 1 in this case to be back compatible. The function is recognisable by the label, you have to assign it only one time at the beginning.

fma

Option #3 is the most intuitive.

To second @gtj0, the naming on the boards should be totally neutral. I mean, don't use X, Y, Z, just numbers, so routing between drives, hotends, endstops is not confusing. I would also put all drivers together, all endstops inputs together, all fans input together... Aslo, if all I/O could have the same behavior, it would be great (on the current board, Duet endstops and Duex ones can't do the same things, like monitoring filament sensor...).

Anyway, I'm sure the next hardware will be awesome!

dc42

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

I think option two would be my first choice with the third coming next. Also if there will be the possibility to daisy chain more than one expansion would the drivers on the first expansion be 101, 102, 103.... while the next expansion in the line be 201, 202, 203...?

To achieve that numbering, you would need to set the ID switch on the first expansion board to 1, and the ID switch on the second board to 2.

dc42

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

Oh yeah @dc42, on the new boards you'd better make sure the silkscreen labels match the physical designator scheme. Labelling things with their logical uses on the Duet2 and Duex5 was very confusing for me when I started out.

Labelling them with their physical capabilities would be the best option.
drive
2 pin pwm out (2PO)
3 pin in (3IN)
low power mosfet (LPM)
high power mosfet (HPM)
etc.

We're planning to label the connectors Motor0, Motor1, Out0, Out1 etc. Some of the Out ports will have a higher power capability than others, but all will be configurable as motors, fans or general purpose output.

dc42

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

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

I think option two would be my first choice with the third coming next. Also if there will be the possibility to daisy chain more than one expansion would the drivers on the first expansion be 101, 102, 103.... while the next expansion in the line be 201, 202, 203...?

FWIW, I think option 3 will result in even more "this is too fricking hard to configure" posts.

Why do you think option 3 is harder than option 2? They are logically the same, but for option 2 you need to do the (100 * board_id + device_id) calculation yourself.

Just to be clear: if you don't have any expansion boards then you will just need to specify the device number on the main board as now; although if we adopt option 3 then I would allow "0.1" as an alternative to "1" and so on.

keyz182

I think option 3 is by far the cleanest. If labelling is added too, it becomes even more clear, e.g. if you set the label of expansion board 1 to "MyAwesomeExpansion" and one of it's drives to "ZAxis", you get super easy to visually parse
M569 S1 PMyAwesomeExapnsion.ZAxis

Qdeathstar

I think option 3 is best. If only because that is an existing standard.

gtj0

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

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

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

I think option two would be my first choice with the third coming next. Also if there will be the possibility to daisy chain more than one expansion would the drivers on the first expansion be 101, 102, 103.... while the next expansion in the line be 201, 202, 203...?

FWIW, I think option 3 will result in even more "this is too fricking hard to configure" posts.

Why do you think option 3 is harder than option 2? They are logically the same, but for option 2 you need to do the (100 * board_id + device_id) calculation yourself.

Just to be clear: if you don't have any expansion boards then you will just need to specify the device number on the main board as now; although if we adopt option 3 then I would allow "0.1" as an alternative to "1" and so on.

Sorry, I meant option 2 would result in more "this is too...". I'm totally on board with option 3.

fma

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

I think option 3 is by far the cleanest. If labelling is added too, it becomes even more clear, e.g. if you set the label of expansion board 1 to "MyAwesomeExpansion" and one of it's drives to "ZAxis", you get super easy to visually parse
M569 S1 PMyAwesomeExapnsion.ZAxis

Some sort of device tree overlay could be used to make the labeling...

gtj0

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

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

Oh yeah @dc42, on the new boards you'd better make sure the silkscreen labels match the physical designator scheme. Labelling things with their logical uses on the Duet2 and Duex5 was very confusing for me when I started out.

Labelling them with their physical capabilities would be the best option.
drive
2 pin pwm out (2PO)
3 pin in (3IN)
low power mosfet (LPM)
high power mosfet (HPM)
etc.

We're planning to label the connectors Motor0, Motor1, Out0, Out1 etc. Some of the Out ports will have a higher power capability than others, but all will be configurable as motors, fans or general purpose output.

YAY!

keyz182

@fma Could be an interesting idea, especially it the DTO is stored on the expansion (seeing as they're getting more intelligent, with CanBus). Plug'n'Play

Danal

Another vote for option 3.

And another vote for neutral naming on the silkscreen, and exactly matching the silkscreen number to the gcode number.

And... EVERYTHING should use a CONSISTENT index origin. The first thingie should always be the zero-eth thingie. Always. In a all silkscreen, configuration addressing, documentation, DWC text, etc, etc.

pawPrinter

I like #3, but could a 4th idea be an additional parameter? eg. P for board, Q for it's driver. Maybe that complicates it more...

fcwilt

Hi,

#3 for sure.

Frederick

Pilotltd

We're planning to label the connectors Motor0, Motor1, Out0, Out1 etc. Some of the Out ports will have a higher power capability than others, but all will be configurable as motors, fans or general purpose output.

Labelling as you are planning - Option 3 is fine if this is aimed at CNC machining users but not sure how a slicer would cope - post processors seem to be sadly missing from the usable ones.

deckingman

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

I like #3, but could a 4th idea be an additional parameter? eg. P for board, Q for it's driver. Maybe that complicates it more...

I like this idea but why can't we use "B" for board or "E" for expansion board.

So e.g M569 B0 P0 means drive 0 on board zero. The default if no "B" value is present would be the main board so M569 P0 would mean the same thing and would be backwardly compatible for the majority of users with just one main board. Then M569 B1 P2 would mean drive 2 on (expansion) board 1.

Come to that, why the hell do we have to use "P" for drive number? Why not "D" M569 B1 D2 would make a lot more sense.

Some consistency of letters within gcode commands would make a lot of sense too. e.g. when referring to heaters, in M143, M570 M307, we use "Hn" which is fine. But in M305 we have to use "Pn" to refer to heater number. In M563 we have to use "Pn" to define tools. Why not "Tn". We use "Tn" in gcode files, why do we have to use "Pn" to refer to the same thing in configuration files? In M106 we have to use "Pn" again to refer to fan number. Why not "Fn"?

No wonder new users get confused and frustrated.

dc42

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

We're planning to label the connectors Motor0, Motor1, Out0, Out1 etc. Some of the Out ports will have a higher power capability than others, but all will be configurable as motors, fans or general purpose output.

Labelling as you are planning - Option 3 is fine if this is aimed at CNC machining users but not sure how a slicer would cope - post processors seem to be sadly missing from the usable ones.

My intention is that only GCodes used for configuration (and normally used only in config.g) would use the <board_id>.<device_id> format. So a slicer would have no reason to use it.