Marlin: [BUG] Possible LED Pin clean-up

[ruggb]

@thinkyhead
Here is an actionable item for you
I have spent 3 days chasing this issue. It is the cause of the errors presented to you in #17974 which had "nothing actionable".

To make it short as you requested take 2.0.5.3 commit e4d8336 (or you can also do that in any commit since then including bugfix 64876f7) and search for
(STAT_LED_RED). I think you may immediately see the error.
If not I can continue "talking" more, if @ellensp doesn't object again.

For quick reference your sanity check says the following, but it does not catch your error.
Line 258: #error "STAT_LED_RED/STAT_LED_BLUE are now STAT_LED_RED_PIN/STAT_LED_BLUE_PIN. Please update your pins definitions."

Someone is not following your own directions
After fixing all the instances, it compiles without the library errors.
Your welcome.

[sjasonsmith]

Can you post your configuration files to reproduce this?

[ruggb]

@sjasonsmith
the problem is not in my config files
THIS is the problem (many instances)
#if PIN_EXISTS(STAT_LED_BLUE)
REPORT_NAME_DIGITAL(__LINE__, STAT_LED_BLUE_PIN)
#endif
YOU are asking if a pin exists which is not defined per your sanity check.
Someone only did 1/2 the job to change it.
All I did was to enable the TEMP_STAT_LEDS == this all works fine without error in older builds.
It has also propagated to the latest bugfix.
Apparently Arduino is smart enough to figure it out because it compiles but throws the error without any more info. So much for compiling with platformIO. It is not only smart, but it must figure you are too dumb to figure out the error anyway so it says nothing.
I am also running into similar issue with the EEPROM_SETTINGS but I haven't figured out why yet.

[ruggb]

Maybe you can since you fixed the stepping issue.
enabling the EEPROM_SETTING produces 2 errors (that is the ONLY change made from the config that runs without error now that I fixed the above temp ones.) Nothing else is changed relative to EEPROM.
Error while detecting libraries included by C:\Users\Bill\AppData\Local\Temp\arduino_build_976191\sketch\src\gcodehost\M115.cpp

Error while detecting libraries included by C:\Users\Bill\AppData\Local\Temp\arduino_build_976191\sketch\src\module\configuration_store.cpp

If I comment out // cap_line(PSTR("EEPROM"), ENABLED(EEPROM_SETTINGS));
in M115 the M115 error goes away
Obviously, that isn't an answer as in the LEDs. The question is why commenting that out gets rid of the error?
I'm still trying to find something that negates the other file error.

[sjasonsmith]

I'm not trying to blame you for the problem. By providing configuration files you make it easier for someone else to reproduce the issue and help. I won't waste my time trying to help somebody who won't spend the time to help me help them.

[ruggb]

Jason, I have spent 3 days chasing this issue. What I get from"contributors" is, There is nothing actionable from the boss and a whole lot of disrespect from him and others. The first issue in MANY library errors was apparently I had 2 versions of U8glib. When I deleted one most of the errors went away. Then I tracked down the above temp error because I was told there was "nothing actionable". It is pretty obvious that you can't test for something that does not exist. Just look at it! That is not part of my config.
When I figure the other one out and get a clean compile, I might upload my configs if they are needed to verify the problem I find, but it doesn't take that to see the LED error.
I am a retired EE. I spent all my life troubleshooting. The fact that I have found the LED problem should convince you of that.

[sjasonsmith]

@ruggb, I did not disrespect you in any way. I have no financial incentive to contribute to Marlin in any way. I help fix issues because it is enjoyable for me, or to fix problems with my own printers.

I simply asked for you to make it a little easier for me to reproduce your issues so that I could _volunteer my time_ to reproduce your problem and help you out.

Your lack of cooperation is probably why you have received the reactions you have to past issues. You are working with a group of mostly volunteers who are contributing for fun. People like me have no interest in helping people who are rude or disrespectful.

If you aren't willing to cooperate with people who are trying to help, please just close your issues and go away.

[ruggb]

I understand that. Based on you communications with me in the past I have much respect for you. I will bother to upload if you do ONE additional thing. After fixing the LED issue, (which is in the stated build and everything since then including bugfix) figure out what the EEPROM issue is. Being told that all these errors I get is a result of Arduino and not Marlin's problem is BS. If Arduino flags it, there is an issue and the LED one is very obvious. How Arduino figured it out I don't know, but you can't test something that doesn't exist. I am sending the config that causes both issues, but EEPROM_SETTINGS is commented out so you won't get sidetracked with that error. Reenable it to chase the EEPROM thing. What triggers the other errors is TEMP_STAT_LEDS enabled, which it is.

It must be run with Arduino in verbose mode. I am using 1.8.13 but I was using 1.8.12 when I originally found it. I am also sending the files that I changed to fix the LED issue. I am using e4d8336. Search for //## to find the fixes.
OR use this:

in MarlinCore.cpp
Line 1048: #if PIN_EXISTS(STAT_LED_RED_PIN) //##
OUT_WRITE(STAT_LED_RED_PIN, LOW); // OFF
#endif

Line 1052: #if PIN_EXISTS(STAT_LED_BLUE_PIN) //##
OUT_WRITE(STAT_LED_BLUE_PIN, LOW); // OFF
#endif

in tempstat.cpp
Line 48: #if PIN_EXISTS(STAT_LED_RED_PIN) //##
WRITE(STAT_LED_RED_PIN, new_red);
#endif

Line 51: #if PIN_EXISTS(STAT_LED_BLUE_PIN) //##
WRITE(STAT_LED_BLUE_PIN, !new_red);
#endif

in pinsDebug_list.h
Line 908: #if PIN_EXISTS(STAT_LED_BLUE_PIN) //##
REPORT_NAME_DIGITAL(__LINE__, STAT_LED_BLUE_PIN)
#endif

Line 914: #if PIN_EXISTS(STAT_LED_RED_PIN) //##
REPORT_NAME_DIGITAL(__LINE__, STAT_LED_RED_PIN)
#endif

Marlin.zip
Mod files.zip

Good luck

[sjasonsmith]

@ruggb, your fixes are to replace PIN_EXISTS(STAT_LED_RED) with PIN_EXISTS(STAT_LED_RED_PIN)?

The PIN_EXISTS macro already appends the _PIN suffix, so this ends up checking for STAT_LED_RED_PIN_PIN. That actually breaks the functionality of the related code.

The configuration and source files you provided seem much older than either of the branches you referenced in the issue description. I have a feeling you are using a mixture of old and new files together.

[sjasonsmith]

I had to modify your configuration files to get them to build against the current state of bugfix-2.0.x. Once I got past those errors, I did not encounter any issues with either your LED pins or your EEPROM_CONFIGURATION.

Right now I don't see any issues which need fixed.
I suggest starting with a clean copy of the bugfix-2.0.x source, and update your configuration files accordingly. If you still have issues, upload your new configuration files which demonstrate the problem.

[ruggb]

the configs are different between the builds, I would expect errors.
So you are saying that Arduino is finding a ghost?
When I changed it, it compiled w/o error. And I repeated it to verify.
I would sure like to know what is going on. I compile BF b7f8163 one second b4 or after this on the same computer and no errors with either version of Arduino.

[ruggb]

I just repeated the issue with clean 2.0.x.64876f7 right out of the box.????????????? Default everything

[ruggb]

I have downloaded it 2x. Always the same.
If I run 2.0.x.b7f8163 default or with my config everything is fine.
This is driving me batty.

[GhostlyCrowd]

I just repeated the issue with clean 2.0.x.64876f7 right out of the box.????????????? Default everything

I just did a fresh pull built everything default and did not get your errors, As suggested before, platform IO is the better way to compile as the Arduino IDE struggles with how many files are in 2.0.x and also suffers more from longer paths. as suggested before. as @sjasonsmith said above he seemed to build with out issue with your configs on the latest pull of bugfix with your configs (after modifying them for this build) I'll assume he is also using platform IO.

As you have stated a fresh 100% un touched build still errors for you and not us, would suggest its an issue with the IDE and its quirks since platform IO is not having these issues at all. When the only differences is the compiler/environment and the same code has two different outcomes it suggests looking into your Build ENV is the nest step i suppose.

"It's recommended to use PlatformIO if Arduino IDE is giving trouble. To most efficiently build with Arduino you need to delete all the HALs from the project that you're not using. If building on Windows, don't put the project into a location with a long path name."

[Roxy-3D]

It's recommended to use PlatformIO if Arduino IDE is giving trouble.

Agreed! But if Arduino is the root cause of this problem, I would like to see it fixed!

[ruggb]

Here is the dilemma. I use the same computer, the same directory structure, the same compiler and with the older BF I get no errors with or without my configs.
I then compile a newer version with default configs and get errors. I add my configs and when I enable TEMP_STAT_LEDs I get errors that go away when I add _PIN to the test lines.
The fact that it does compile then is also strange. If you are not doing this with Arduino in verbose mode, why do I think you will duplicate what I am seeing?
Please help me understand this!!
Maybe it is Arduino, but why does it fix when I add PINS if it is false error. Just not false enough to not compile. Please note, I do not have any more hair to pull out.

[GhostlyCrowd]

It's recommended to use PlatformIO if Arduino IDE is giving trouble.

Agreed! But if Arduino is the root cause of this problem, I would like to see it fixed!

Agreed, with the above information its an IDE issue to be looked into.

Maybe it is Arduino, but why does it fix when I add PINS if it is false error. Just not false enough to not compile. Please note, I do not have any more hair to pull out.

I think @sjasonsmith explained above that when you're making this change your breaking the function and that seems to make it stop throwing the non critical error for you. As to why? this is up for investigation, but its definitely not a "fix" for you issue.

[ruggb]

OK, I put Marlin on the desktop and with default everything I get errors. That eliminates the path length issue, right?

[ruggb]

If breaking the function by adding _PIN makes it test ...._PIN_PIN which also does not exist, it should also fail.

[sjasonsmith]

I had built it in both VS Code and Arduino in verbose mode.

What exactly are the errors you are seeing, I don’t think you have told us.

[sjasonsmith]

And if you have re-tested with the latest bugfix please provide the updated config files you are using.

[ruggb]

maybe we should do a zoom and share my screen.
I am using it OUT-OF-THE-BOX. Exactly what was downloaded. not with my configs

I am compiling now and will upload the errors

[sjasonsmith]

I just did it again with clean bugfix-2.0.x source. I only added the following 3 lines:

#define TEMP_STAT_LEDS
#define STAT_LED_RED_PIN 5
#define STAT_LED_BLUE_PIN 6

It builds fine for me in both PlatformIO and Arduino 1.8.12, on Windows.

The only indication of any issue are multiple messages like the following, but this doesn't interfere with the build, and I don't think is what @ruggb is talking about.

Error while detecting libraries included by C:\Users\jason\AppData\Local\Temp\arduino_build_622220\sketch\src\MarlinCore.cpp

[thisiskeithb]

What exactly are the errors you are seeing, I don’t think you have told us.

@ruggb: Please upload your full log output to pastebin.com and paste the link back here for review.

[ruggb]

I just did it again with clean bugfix-2.0.x source. I only added the following 3 lines:

#define TEMP_STAT_LEDS
#define STAT_LED_RED_PIN 5
#define STAT_LED_BLUE_PIN 6

It builds fine for me in both PlatformIO and Arduino 1.8.12, on Windows.

The only indication of any issue are multiple messages like the following, but this doesn't interfere with the build, and I don't think is what @ruggb is talking about.

Error while detecting libraries included by C:\Users\jason\AppData\Local\Temp\arduino_build_622220\sketch\src\MarlinCore.cpp

Thank you - that is EXACTLY what I am talking about. That its the first error I get when I do that.
There are probably about 5 more.
The last time I did that and then added the _PINS, those errors went away.

[thisiskeithb]

There are probably about 5 more.

We've already asked you several times to upload your logs.

Please upload your logs.

[sjasonsmith]

Really? That's the error? That's just Arduino being dumb.

If adding _PINS fixes it, then it is even more dumb, because you are quite literally breaking the code to make a fake error go away.

I have huge respect for Arduino, what they've done for the hobby electronics community is amazing, and I often support them buy buying their genuine hardware and donating to them. That said, their IDE was never meant for a project like Marlin. They are doing some trickery to detect dependencies which clearly doesn't jive well with Marlin's own macro trickery. Many tools that analyze code don't handle macros well.

Just ignore it. This isn't a real issue.

[ruggb]

I'm not as fast as you and I would like to get it right.
I just did it and got lots of errors, the went back and thought I did it again and got none.
I want to make sure it is repeatable which I thought it was, then I get no errors. bear with me so I can get it right. However, Jason has repeated what I got so I don't know what that tells you.

[ruggb]

OK Jason. At least I know you saw what I saw. If you know it is not an issue I will be happy with that.
You have to admit it is awful strange.

[thisiskeithb]

We need your full log output. Paste your full log output.

I'm not sure how many ways we can ask for this information.

Please upload your logs.

[GhostlyCrowd]

OK Jason. At least I know you saw what I saw. If you know it is not an issue I will be happy with that.
You have to admit it is awful strange.

We probably could have solved this with your full logs, which have been asked for several times, much sooner and with much less passive aggressiveness. Just to point this out...

[ruggb]

hey Keith. Jason saw what I see and says it is not an issue. I can live with that.

BTW I posted the errors is saw (not full log) in the previously mentioned issue at the beginning.
The .... is just all the files being errored

Thanks guys. I will try to convert to platformIO soon.

[thisiskeithb]

hey Keith. Jason saw what I see and says it is not an issue. I can live with that.

BTW I posted the errors is saw (not full log) in the previously mentioned issue at the beginning.
The .... is just all the files being errored

No, we are still asking for your full logs.

[ruggb]

@thisiskeithb
here you go. I deleted all the entries that were not associated with errors - sorry.

compile OOTB.txt

[GhostlyCrowd]

@thisiskeithb
here you go. I deleted all the entries that were not associated with errors - sorry.

compile OOTB.txt

thats not what was asked, the full log is the only way to provide any proper insight, if your not willing to give it then this issue I guess is closed?

If we cant see exactly what you see start from finish then your asking any one willing to help to guess and fly blind., and thats not fair especially when you have been so aggressive with the people trying to help.

Would it be reasonable for me to ask you for help and refuse to explain the situation and provide the information asked?

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.