Request (if possible) for greater consistency in G-codes
-
Hi,
Consider:
M118: Send Message to Specific Target
It takes parameters (not all are listed):
- P which specifies message type
- S which specifies message to send
M291: Display message and optionally wait for response
It takes parameters (not all are listed):
- P which specifies the message to display
- S which specifies the message box mode
I know it is hard to change things that have been out there for sometime but it would be nice if somehow parameter consistency could be improved.
Perhaps it could be done via new commands that do the same but with consistent parameters.
Thanks.
Frederick
1Hardware: A Duet equipped FT-5 with all of the 713 upgrade bits is now working well. My current project is a D-Bot CoreXY, much modified, and is now printing well. The two deltas have been retired, they didn't work as well as they should.
1 Reply
-
@fcwilt I'm definitely like minded on this, but having been a software developer for 20+ years, it's just not going to happen. Keep links to documentation handy, build tools to abstract the ugly if you have to.
-
@gnydick said in Request (if possible) for greater consistency in G-codes:
@fcwilt I'm definitely like minded on this, but having been a software developer for 20+ years, it's just not going to happen. Keep links to documentation handy, build tools to abstract the ugly if you have to.
I too was a programmer - 35+ years. Started on 80 column punch cards - Fortran and Algol. Ah... those were the days - NOT!
Frederick
1Hardware: A Duet equipped FT-5 with all of the 713 upgrade bits is now working well. My current project is a D-Bot CoreXY, much modified, and is now printing well. The two deltas have been retired, they didn't work as well as they should.
1 Reply
-
@fcwilt , we try to be consistent in all new GCodes we allocate. For example, all GCodes involving heater numbers that I have introduced use H for the heater number. Unfortunately, we have to be compatible with other firmwares, so maintaining a logical use of parameters isn't always possible.
0Duet 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
2 Replies
-
@fcwilt said in Request (if possible) for greater consistency in G-codes:
Started on 80 column punch cards - Fortran and Algol.
Luxury! (spoken with a Yorkshire accent)
-
@dc42 said in Request (if possible) for greater consistency in G-codes:
Unfortunately, we have to be compatible with other firmwares, so maintaining a logical use of parameters isn't always possible.
Well, the most important is to be compatible with slicers... I mean, you need to implement G-Codes the way they use them.
On the other hand, G-Codes which are used for configuration, or special stuffs slicers don't directly handle, and where people have to manually define in custom scripts (servo usage, for example, as we discussed a few days ago), I'm not sure it is a good idea to always follow other firmwares; It is sometimes better to define new standards.
-
@dc42 said in Request (if possible) for greater consistency in G-codes:
@fcwilt , we try to be consistent in all new GCodes we allocate. For example, all GCodes involving heater numbers that I have introduced use H for the heater number. Unfortunately, we have to be compatible with other firmwares, so maintaining a logical use of parameters isn't always possible.
It's just my OCD talking.
Frederick