GCodes for the next-generation Duet
-
@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.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
G-Code 'language' is pushed to its limits... Maybe it's time to create something better... Like it's time to drop STL format...
-
@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 speedThis 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 speedCreating 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 -
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...
-
@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".
-
@dc42 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?
-
@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/
-
@fma I was just thinking that we seem to be stuck with G and M codes, the same way that we are stuck with querty keyboards.
So something along the lines of users being able to use plain language to describe what they want to configure or happen, and which would shield them from having to know all the various G and M codes along with the associated parameters. The "interpreter" would take the plain language file or command, and convert it into the relevant G or M code. -
Another approach would be to use configs variables... More verbose from the user point of view (leading to a longer config file), but maybe easier to handle from the firmware point of view?
KINEMATIC_MODE = CORE_XY
X_SPEED_MAX = 10000
X_ACCEL = 3000FAN_0_PORT = 0.4
FAN_0_PWM = 500
FAN_0_PWM_INVERT = True
...Don't know if all commands can be set this way; some parameters may need to be set at the same time, so more difficult to deal with one by one...
Frédéric
-
I like where this is going but even though the controller is 32-bit, speed and memory are still an issue.
@dc42 have you guys thought about separating the controller from the I/O boards, maybe in a hat or mother/daughter arrangement? This way you might be able to offer a basic arrangement with the SAM platform or more advanced arrangements with something like an i.MX6 SOM.
-
@fma said in GCodes for the next-generation Duet:
Another approach would be to use configs variables... More verbose from the user point of view (leading to a longer config file), but maybe easier to handle from the firmware point of view?
KINEMATIC_MODE = CORE_XY
X_SPEED_MAX = 10000
X_ACCEL = 3000FAN_0_PORT = 0.4
FAN_0_PWM = 500
FAN_0_PWM_INVERT = True
...Don't know if all commands can be set this way; some parameters may need to be set at the same time, so more difficult to deal with one by one...
Yes there are many cases in which it is best to set several parameters in one go.
I am looking for a solution that we can run on the Duet 2 series too, so that I can use a lot of common source code for the Duet 2 series and the next generation Duet. So whatever solution we pick shouldn't use a lot of additional RAM, but it can use more flash memory.
-
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 applicableOther 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.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
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.42numbers become yet another random number everybody has problems remembering and identifying when reading through a config.g file... -
@resam Currently this will extract the number after the letter and will do a
switch() { case... }over it. C/C++ can only do aswitchon integers. There are workaround solutions that can be used to switch onstringas well but they fall into the category of using more RAM - though not too much more RAM, so this might be a solution but I have no overview on how much RAM is left.@dc42 I want to express how great I find the idea that you are a) asking the community and b) start to rattle off some of the rust that has settled on G-/M-Code.
EDIT: One slightly different idea for thought: how about creating a new code prefix for configuration like
CnnnorDnnn? -
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. -
@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.42numbers 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
-
@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. -
@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 applicableOther 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
-
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).
-
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?
