GCodes for the next-generation Duet

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.

dc42

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

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

That's a possibility, but it presupposes that B or E is not already used for another purpose by any of the GCode commands affected. Also it potentially makes it harder to identify the device when reading the GCode command, because the B or E parameter might be at one end of the line of GCode and the other parameter at the other end.

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.

At the time I became involved with RRF, GCodes such as M305, M106 and M563 were already defined and generally used P to identify the "thing" (i.e. fan, heater or tool) number that the command was defining. So we're stuck with them now, unless we cause existing users a lot of hassle by changing them. I have tried to be more consistent in GCode commands that I added, for example by using H for heater number and F for PWM frequency.

fma

G-Code 'language' is pushed to its limits... Maybe it's time to create something better... Like it's time to drop STL format...

dc42

@fma, I have been considering the possibility of using a different command syntax for some of the configuration commands in config.g instead of defining yet more GCodes. However, if I do that then those commands would be probably be available only at startup time, which would reduce flexibility.

Another possibility I have considered is putting all configuration commands that would normally be used only within config.g in the M1000+ range. For example, currently the M106 command currently has lots of parameters:

M106 P4 A3 F500 I1 B0.2 L0.1 ; configure fan 4 on heater 3 output, 500Hz PWM, inverted
M106 P4 S0.5 ; set fan 4 speed

This could become:

M1000.106 P0 A"Print cooling fan" D0.3 F500 I1 B0.2 L0.1 ; create fan 4 on board 0 output 3
M106 P0 S0.5 ; set fan 0 speed

Creating a heater would be done something like this (you would need to create a temperature sensor first):

M1000.305 S0 A"Bed temperature" T0.0 B4300 R100000 ; create and configure temperature sensor 0 using thermistor input 0
M1000.307 H0 A"Bed heater" S0 D0.0 ; create heater 0 on output 0 using sensor 0

fma

My point was to create a more powerful language, like ones found in industrial motor controllers. No more 'G1 X100 Y100 F6000', but 'move x=100 y=100 speed=6000'.

But this is something to discuss with the entire community, as slicers also need to implement it. And this for sure won't work on 8bits controllers, as it would require much more power to interpret it.

What about implementing both? At least, the new language could implement configuration commands, so you could either write:

M106 P4 A3 F500 I1 B0.2 L0.1 ; configure fan 4 on heater 3 output, 500Hz PWM, inverted

or:

set fan=4 name=Print cooling fan" heater=3 pwm_freq=500 min_pwm=0.1 pwm_invert=true blip_time=0.2

This command would be internally mapped to M106 one.

Later, printing commands could also have their equivalent in the new language, so slicers could start to use them. Maybe...

deckingman

@fma I like this idea. Perhaps we could have an interpreter, a bit like when I used to write programs for my ZX81 using "Basic" (few people here will be old enough to know what I'm talking about). So "M569 Drive 0 Backwards" gets interpreted as "M569 P0 S0".

deckingman

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

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

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.

That's a possibility, but it presupposes that B or E is not already used for another purpose by any of the GCode commands affected. Also it potentially makes it harder to identify the device when reading the GCode command, because the B or E parameter might be at one end of the line of GCode and the other parameter at the other end.

Are we stuck with having to use a single letter? Is something like "EB" to denote expansion board a no no?

fma

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

[...] I used to write programs for my ZX81 using "Basic" (few people here will be old enough to know what I'm talking about).

I am old enough! That good old ZX81, my very first computer ;o)

I would totally avoid the use of G/M-Codes, as there are so many, now, it is difficult to now what they are doing when reading the config file; using something close to linux shell commands would be better.

To make something really better, this would also require to re-think all commands, instead of translate each G/M-Code: many of them are related, and could be grouped under the same command, with modifier params. Auto bed leveling, for example, is very complicated, split in so many M-Codes that I gave up using it (well, in fact, I don't need it, as my bed is perfectly flat, and stiff enough ;o) ).

But this is a huge work :o/