Request (if possible) for greater consistency in G-codes

fcwilt

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

gnydick

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

fcwilt

@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

dc42

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

dc42

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

fma

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

fcwilt

@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