But the compile shows the define of MOTHERBOARD value is incorrect in the PINS.h 'if' statement.
I created a new sketch and brought in the code to create an very slim path to the error line in question.
This new sketch compiles. I test it by setting the MOTHERBOARD to 34, which is suposed to work. AND IT DOES. Then I set the MB to 01, which reports Motherboard not defined. This is also correct because I deleted those lines in my test sketch.
So this test proves the syntax and logic in the Marlin code are correct. The compiler fails due to dropping the MOTHERBOARD value in the variable collection process. It might have collected it correctly but drops in the passing or linking phases.
If this is a bug in the new Arduino IDE then the important thing is to make it easy for the developers to see the issue clearly. They are busy with many issues so if something isn't clear or maybe just a bug in Marlin then it will take lower priority which may mean months delay on getting the issue fixed. Here's my suggestion:
Make sure the bug still exists in the hourly build(looks like you are already doing that).
Write the most simple possible code that demonstrates the bug.
Write out a clear description of the steps required to reproduce the bug, what results you expect, and what results you are getting instead of what you expect. I'm happy to verify your results if you post the demonstration code here.
Then you can submit an issue to the tracker. This sounds like a problem with arduino-builder so it should probably go in that repository. If you don't have a GitHub account I'm happy to submit the issue for you.
If done correctly issue reports tend to get fixed very quickly. Of course then they are only available in the hourly build until the next version is released.
@Pert,
I understand what you are saying. I felt it not necessary to redocument everything verbatim but to supply a bullet list of steps.
Get Marlin code,
Run through compiler,
See error.
The compiler console would show them an exact fault.
I did not submit an isuue in the tracker site. Should I or will this thread be investigsted by them?
The bigger problem fo me would be if it compiles in their environment. That would trigger another investigative session by me as the fault would be on my part somewhere.
Three things stand out at this point: Not my IDE code, not my firmware code, my PC.
The PC end of it have the most variables to pursue and I dont know where to start. The supplied bullet list is the quickest way to start the next step of investigation.
Thanks for the previous reply.
(you don't mention in your steps that you need to change the value of MOTHERBOARD to get the error, where do I do this?)
Compile(does it matter which board I have selected?) - I receive the following error:
(use code tags) {error message here}...
So If I follow your steps exactly it compiles for me. It may be caused by me not understanding your instructions. If you submit the issue with the steps you wrote above and the developer tries it and gets no error then your issue either gets closed as invalid or goes to the bottom of the pile.
giantkiller:
The PC end of it have the most variables to pursue and I dont know where to start.
That's why I suggested you remove as many variables as possible by writing simplified code that demonstrates the issue. Marlin is so complex that there are just too many variables. As for the PC, if you and I get the same results then that supports your PC not being the cause. As I said I'm happy to test, I just need more information on how to go about it.
Yep. My bad. You don't change anything in the code. Just download and shove. No pre-analysis needed.
Its that simple.
The failure looks to be values getting dropped or clobbered. Bingo. I will stress 'clobbered'. This would be an almost given when compiling since that is a huge resource hog.
I'm making a real effort to understand your issue but I still can't. The developers have 572 open issues and 93 open pull requests, they're not going to try so hard. You need to help us to help you. The issue seems very clear to you but I can't read your mind and don't even have a 3D printer. Explain it as clearly as possible. Pretend you're someone who understands the basics of the Arduino IDE but nothing else and give a very clear set of steps for how I can reproduce your error. Assume I'm a robot, if you tell me that the way to make a PBJ sandwich is to take the peanut butter and put it on the bread you're going to end up with a jar of peanut butter sitting on top of a loaf of bread. If it requires owning a 3D printer you're might be better off taking this to a different forum or the Marlin repository.
I also believe it has something to do with the 'Application data folder' structure. I need to know what entries are made to those 2 areas of the computer.
What more can I supply to enable the dev team any more insight into this compile error.
I am suspicicious that the majority of the issues we see on this build stem from the same problem.
Could it also be a memory allocation issue?
I am on Win7 pro 64 bit. The install directory always ends up in the programs(x86) folder but the zip can reside any where.
I have even tried 'Run as Administrator'.
The compiler shows 'Unknown MOTHERBOARD value set in configuration.h'. But as PERT noted it worked for him. This points to file areas of operation in the compiler. All the necessary .h files are there. Its like an '#include' doesnt work.
What board do you have selected in Tools > Board? Is is a 3rd party board? I ran into pretty much the same issue yesterday where the preprocessor directives were acting unexpectedly because of a 3rd party core that needed a platform.txt update.
Well in this case it was only that set of 3rd party boards that didn't work right and the Arduino/Genuino Mega or Mega 2560 entry worked fine. This test should check if you're having that issue:
Select Tools > Board > Arduino/Genuino Mega or Mega 2560
Select Tools > Processor > ATmega2560(Mega 2560)
Enter this sketch:
#if defined(__AVR_ATmega2560__)
#error __AVR_ATmega2560__ defined
#else
#error __AVR_ATmega2560__ not defined
#endif
void setup() {}
void loop() {}
Compile
If the preprocessor directives are working correctly then it should fail with the error:
#error __AVR_ATmega2560__ defined
If they are not working correctly then compiling will fail with the error: