Shouldn't upper() gcode sent to printer #248

New Issue

2019-07-08T13:40:02+01:00

CapnBry commented

2019-07-08 13:40:02 +01:00

(Migrated from github.com)

Describe the bug
I use Klipper firmware and tried adding a gcode command to the Enclosure Plugin. The gcode command didn't work when sent because the gcode is converted to uppercase before being sent (such as SET_PIN). Names in Klipper are case-sensitive and therefore the gcode should be sent exactly as entered by the user. This is true for every firmware, for things like M117, where this would change what is displayed on the LCD.

To Reproduce
Steps to reproduce the behavior:

Create a new gcode output
Set the gcode value to anything in lowercase, e.g. M117 Button pressed
Use the Enclosure Plugin button to send the output
Observe in the OctoPrint terminal that the gcode has been converted to uppercase

Expected behavior
Do not change what has been configured to be sent.

Additional context
Don't do this here or anywhere else the user has said "Send this".

**Describe the bug** I use Klipper firmware and tried adding a gcode command to the Enclosure Plugin. The gcode command didn't work when sent because the gcode is converted to uppercase before being sent (such as `SET_PIN`). Names in Klipper are case-sensitive and therefore the gcode should be sent exactly as entered by the user. This is true for every firmware, for things like M117, where this would change what is displayed on the LCD. **To Reproduce** Steps to reproduce the behavior: 1. Create a new gcode output 2. Set the gcode value to anything in lowercase, e.g. `M117 Button pressed` 3. Use the Enclosure Plugin button to send the output 4. Observe in the OctoPrint terminal that the gcode has been converted to uppercase **Expected behavior** Do not change what has been configured to be sent. **Additional context** [Don't do this](https://github.com/vitormhenrique/OctoPrint-Enclosure/blob/master/octoprint_enclosure/__init__.py#L1046) here or anywhere else the user has said "Send this".

vitormhenrique commented

2019-07-11 17:41:30 +01:00

(Migrated from github.com)

do you think i should just remove the upper? of have the ability for user to select how to send? can't remember why I did the upper....

CapnBry commented

2019-07-11 18:47:22 +01:00

(Migrated from github.com)

I'm not sure why it is there either, although I am sure given the state of 3D printer firmwares there's got to be at least one that expects everything in uppercase. You could make it an option, but I always err on the side of fewer options. You'd be a better judge of what to do, but I'd say just send whatever the user enters and if their firmware doesn't take it, it is easy for them to change the gcode to uppercase.

I know that OctoPrint will uppercase the first letter of a G, M, or T command sent from the terminal tab, but leaves the rest alone. I asked foosel and she said they did experience some compatibility errors with some firmwares and users typing stuff in lowercase in the terminal tab. All regular (streaming) gcode is sent as-is. Haha she just said "I even would have uppercased all of it if it weren't for M117 [for compatibility]".

So I would think most-compatible case it would be work like OctoPrint's terminal tab, but I think it is safe to just rely on the user to uppercase it themselves if needed.

I'm not sure why it is there either, although I am sure given the state of 3D printer firmwares there's got to be at least one that expects everything in uppercase. You could make it an option, but I always err on the side of fewer options. You'd be a better judge of what to do, but I'd say just send whatever the user enters and if their firmware doesn't take it, it is easy for them to change the gcode to uppercase. I know that [OctoPrint will uppercase the first letter of a G, M, or T command sent from the terminal tab](https://github.com/foosel/OctoPrint/blob/master/src/octoprint/static/js/app/viewmodels/terminal.js#L361), but leaves the rest alone. I asked foosel and she said they did experience some compatibility errors with some firmwares and users typing stuff in lowercase in the terminal tab. All regular (streaming) gcode is sent as-is. Haha she just said "I even would have uppercased all of it if it weren't for M117 [for compatibility]". So I would think most-compatible case it would be work like OctoPrint's terminal tab, but I think it is safe to just rely on the user to uppercase it themselves if needed.

maukcc commented

2019-09-25 13:42:03 +01:00

(Migrated from github.com)

We have the same issue.
But more with @ commands like @pause, and "M118 //action:pause" commands
These will not be interpreted by octoprint when uppercased

So please output exactly as the user writes them.

We have the same issue. But more with @ commands like @pause, and "M118 //action:pause" commands These will not be interpreted by octoprint when uppercased So please output exactly as the user writes them.

maukcc commented

2020-05-12 12:10:47 +01:00

(Migrated from github.com)

We updated to latest version, and this still persists.

CapnBry commented

2020-05-12 15:37:22 +01:00

(Migrated from github.com)

Yeah I had deleted all my plugins while tracking down another OctoPrint issue and when I reinstalled I noticed that this still hasn't been addressed. I've just posted a pull request to maybe make this happen this year. It is the code I've been running since I discovered the issue.

I don't think this works with Python 3 though so the extension might be totally going away once Python 2 does soon.

Yeah I had deleted all my plugins while tracking down another OctoPrint issue and when I reinstalled I noticed that this still hasn't been addressed. I've just posted a pull request to maybe make this happen this year. It is the code I've been running since I discovered the issue. I don't think this works with Python 3 though so the extension might be totally going away once Python 2 does soon.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Gandalf/OctoPrint-Enclosure#248