Naming conventions

[dandancheeseandham]

Just to start a thread on naming conventions as lostapathy has mentioned it.

I'll start with an easy one, the breakout macros from config.g In this I second lostapathy's comment on M98, and will formalise it by proposing M98 naming conventions as:-

type-name.g

1) always in lower-case with a hyphen separator. 2) "type" is a general name for the type of equipment being called. e.g. endstop, probe, heater,fan (it might be nice to list these and get a standardised list too) 3) "name" is a unique name for the specific piece of equipment that identifies it simply, therefore abbreviations should be avoided.

e.g. probe-ir.g probe-bltouch.g tools-dualnozzle.g thermistor-secondbed.g

The first lines in file should also identify exactly the type of equipment it is supporting (or what it is doing if it's not equipment specific) e.g "IR Probe from Duet3D" or "Official BLTouch by ANTCLABS Inc."

[JohnOCFII]

I like it.

Here's one:

probe-piezo.g ; Precision Piezo Orion Z-Probe from Precision Piezo UK

[JohnOCFII]

How should we deal with port selection? Some are very easy to determine. Others we'll have to arm wrestle.

[natewalck]

For the ports, I'm thinking we include a section in the README.md for the given part. For a probe, this documentation would live in sys/probes/README.md. Note what port to use for the config line in probe-whatever.g and also note if you use a different port, the command will need to be updated to match the port in use.

[lostapathy]

How should we deal with port selection? Some are very easy to determine. Others we'll have to arm wrestle.

We should probably try to do this in a way that minimizes the amount of customization required for end-users. As in, if your new probe type can use the same port as is the standard used for every other probe thus far, use the same port in the default config here. That should make things more predictable and safer both for the new device AND less likely to conflict with somebody already using that port for something else.

[JohnOCFII]

We should probably try to do this in a way that minimizes the amount of customization required for end-users.

True - but (and this is clearly optional, but popular) if you want to thermostatically control your hot-end fan, you need to plug it in to a different spot than the "always on" spot in the default setup.

[lostapathy]

That's probably a good argument for picking a standard port for a thermostatically controlled fan and then avoiding it for other uses.

We should probably setup a list of all the I/O ports on the duet+duex and list the "customary" uses of each.

[lostapathy]

I started a branch to capture this ticket at https://github.com/lostapathy/configs/tree/patch1/duet

Table of standard connections is obviously incomplete but figured I'd start something concrete for discussion.

[dandancheeseandham]

Yeah, it's good to make a start! I like the use of Pascal Case for macros.

I also noted - M98 P"wifi.g"

In RepRapFirmware, quoted strings are permitted anywhere a string parameter is expected. This allows file names, WiFi passwords etc. to contain spaces, semicolons and other characters that would otherwise not be permitted.

However they aren't used much by others or myself (for me, due to the old and bad habit of not using special characters where possible anyway) so my M98 would've looked different :smile: However, it made me realise that it would be good to codify the practice to always use quoted strings where a string parameter is expected, regardless of whether needed or not? This will obviously be beneficial to people that do not realise where they are needed.

Not much else I can add otherwise :+1:

[JohnOCFII]

As a person with a space in my home SSID password, it's a good idea to use quoted strings I think.

[natewalck]

I think all P strings should be quoted as a standard. I think it helps readability and makes it more clear what the file name is:

M98 Phome.g

vs

M98 P"home.g"

Someone might assume the file name must be named Phome.g for it to work.