Marlin: [BUG] Reports E1 temp sensor error with no E1 temp sensor used

[ghost]

I've not yet scanned through the code to try to find why this is so, but Marlin always reports E1 temperature sensor error when I'm only using E0 temp sensor and E0 stepper (single E0 extruder/hotend in use).

This is if I unplug E0 thermistor from the board (SKR 1,3) to test Marlin's error detection and try to do stuff (heat hotend or such like).

This isn't a real problem, just thought I'd let you know that Marlin is reporting an incorrect E# number when the error occurs.

[ManuelMcLure]

I believe this is by design. Internally the first extruder is E0 because we're programmers and we like to count from 0, but the name we present to the user is E1 because most people count from 1.

[ghost]

hmmm, but we name the temperature sensors from '0' in the Configuration.h file and the controller boards name them from '0' too, including the extruder stepper drivers.

This means the only thing that starts from '1' is this error reporting routine ? .. a bit confusing to everyone, programmers, users and a like me thinks.

[ManuelMcLure]

Yeah - now I'm not so sure. I remember seeing a commit recently that put that thought in my head but I may have misinterpreted it. I can't seem to find it right now.

[ManuelMcLure]

Ah - found it - look at discussion on #13788.

[ghost]

Well, the user is required to use 'zero' based for configuration and on-board silk screening I.D etc, yet 'one' based when it comes to error messages .. this is a bad user interaction design choice.

Good user interfacing is one of the things I've concentrated on during my decades in design.

oh well, anyway, I've highlighted a potentially confusing setup you're getting the user to go by.

[ManuelMcLure]

I agree - consistency is always a good thing.

[marcio-ao]

Personally, I think all the configs and code should use E1. Its okay to have an integer of value 0 represent E1, but it should be hidden behind a constant, such as:

enum {
   E1 = 0,
   E2 = 1,
}

That way, when you write code like this:

uint8_t temp[EXTRUDERS];
temp[E1] = 200;

You get exactly what is expected. But, that's just my opinion...

[marcio-ao]

Much longer discussion on this here:

https://github.com/MarlinFirmware/Marlin/pull/12227

[marcio-ao]

I think the biggest reason this hasn't been done is that 1) it'll require a lot of code to be modified, with the potential for bugs to creep in, 2) it would break everyone's pre-existing configs.

So, there is a strong argument against changing it. But also, the transition from 1.0.x to 2.0.x seems like the best possible time to actually do it.

[InsanityAutomation]

I remember that discussion! We were conspiring to turn you into a 🍅 farmer!

[ghost]

Be interesting to know what peoples idea of the word 'consistency' actually is ;)

Anyway, as is is a mess if you ask me, the user is required to use '0' based throughout the config files and somehow know that E1 LCD messages are in fact E0 messages due to you having magically swapped to '1' base on the LCD.

"Humans make illogical decisions"

[marcio-ao]

Be interesting to know what peoples idea of the word 'consistency' actually is ;)

My idea of consistency is that the config files would say E1, the LCD would say E1, and the source code would say E1. There would be no E0 anywhere :)

[marcio-ao]

If @thinkyhead is on board, I am willing to spend the time to make a PR that changes E0 to E1 in all configs and source code. However, ~this is potentially risky and could introduce bugs~, plus it will most certainly cause everyone to have to redo their configs. So, it's kind of a big change. That's probably why it has never been attempted. But it's worth doing, IMHO.

EDIT: On second thought, changing the name of enums and constants should not change the binary that is generated, so it is possible to check for correctness simply by diffing the binaries for changes. Hence introducing bugs can be eliminated as a risk.

[marcio-ao]

For what it is worth, the biggest difficulty with making the change is that there are tons of macros in Marlin, so it's not simply a matter of doing a search and replace of E0 with E1 and so on down the line. However, I think that once the E0 enums are removed, the compiler will help identify all the places that E0 is used, and thus help identify any macros that need updating.

[ghost]

I'm fine with using zero base myself, so all I now do with Marlin is change a couple of lines in the code in a couple of places to display E0 on the LCD when it means E0 instead of displaying E1.

[marcio-ao]

I'm fine with using zero base myself, so all I now do with Marlin is change a couple of lines in the code in a couple of places to display E0 on the LCD when it means E0 instead of displaying E1.

@doggyfan: You're a programmer, but you have to consider that Marlin is used for printers that are sold to muggles. For us, having E0 on the LCD is totally unacceptable.

[marcio-ao]

Any even you are a programmer, I bet you never say "extruder zero" aloud. You can read it as E0 and maybe it won't bother you, but I bet you can't say it without it sounding wrong :)

[ghost]

lol. I say eee-nort. It do sound OK to me.

But yes, I guess muggles need to be catered for, tut, lol.

But then, you've conditioned them to use '0' zero base from the year dot in the config files, it might take some doing to swap em over to '1' based configs, and also '1' based gcode responses (they are '0' based from what I've seen).

[marcio-ao]

But then, you've conditioned them to use '0' zero base from the year dot in the config files

I would argue that the best time to retrain users would be now. This is Marlin 2.0.x, after all :)

Also, you mention config files as pertaining to end users. This may be true for DIY folks, but I would bet the majority of Marlin users have never touched a config file in their life and are using whatever FW shipped with their printers. So the "retraining" would only happen for the DIY folks -- and I'm pretty sure that folks that can build their own printers, can easily swap indices around in their configs.

Overall, it's a small pain up front vs the long standing pain of having the LCD say one thing and the source say another, as you have experienced.

[ghost]

I don't mind at all it being '1' based just so long as it's consistent, needs to be the same in the configs and in gcode commands and response too, otherwise my brain keeps pausing for thought and says 'am I altering E1 or E0, it say E1 but I have no E1', aarrgghh

But yes, I do understand that changing all the code and config reading code etc etc will no doubt introduce bugs here and there. mmm difficult really.

[marcio-ao]

@doggyfan: Unfortunately, GCODE is one area that can't change, because it is part of the GCODE specs and there are hundreds on slicers out there that use zero based indexing.

However, E0 isn't used in GCODE, T0 and T1 are. So I think we could at least make it so the use of 'E' was consistent and one-based. GCODE itself would still use T0, which would be recognized as zero-based.

[ghost]

Yes I realize the GCODE stuff has to remain zero-based, I'd actually prefer everything to be zero-based, but then as you say, I'm a programmer (not only), but I'm easy either way, it's the mixing of the bases that does my head in. Even though I now know that you're using zero-base for most things and one-based for the LCD, I still have to stop and think whether the LCD really means E0 or E1 in the menu's.

[boelle]

Lack of Activity
This issue is being closed due to lack of activity. If you have solved the
issue, please let us know how you solved it. If you haven't, please tell us
what else you've tried in the meantime, and possibly this issue will be
reopened.