2015-06-22 15:57:14,584 - SERIAL - DEBUG - Recv: Free RAM:3816
I recompiled the firmware on a windows 8 notebook with the latest arduino IDE today. Used the firmware configurator, changed just what is neccessary, dimensions, steps/mm, thermistor types, endstops and the display type. Hotend deadtime, heatbed bangbang.
Yes, 0.92.3 from here: repetier.com/firmware/v92/.
Compiling the firmware with Windows 8 and Adruino 1.6.5 made no difference, last night dry mode was enabled again while printing from sd card after about 100 layers. I am trying the older V91 now, the printer is supposed to be shown at our open day on friday and I do not want it to run in dry mode when 150 people are around.
I guess something overwrites the byte stored for debug mode. So I only need to find when I introduced the problem.
Can you post your configuration so I'm sure I have the part causing the troubles included as well. I will then test if I can reproduce the error to find it.
Well my printer is still stopped, but i can check the free ram, wich is roperted to be 764 as soon as i connect. (Sidenote: should i do something about that? except for the dry run problem, i have no stability problems)
javitopia 764 byte is not very much and likely to cause problems. Also I do not know the exact bytes needed I would reduce buffered moves to 15, that should give you enough free ram without disabling any feature.
Comparing the two configurations there is not much in common with one being a delta and the other a gantry system. Most important common part is the display controller 11 = GLCD Display. This does many things in ram, so it is a potential candidate especially knowing it was modified several times in may and the first complains were from 7. June in this thread.
As a counter test you could try replacing u8glib_ex.h with a version from april. All changes were done to support new displays so the updates are not important for your combination.
I'm now trying to get an error with latest version on a Ordbot, but with different display.
@iceman1306 I can not really believe it happened with 0.91. We have so many users and none had that problem before (reported) and I haven't changed it since Oct 18, 2014 except a small pull request which executes only on auto leveling.
It seems that a lot of people don't have the problem with the newer v92 either. Perhaps there is some error on my arduino board, or it's some kind of interferrence with the power supply or or or...
Next week, i can change electronics with my other printer. Or perhaps I will try a different display first, there should be a 20x4 text display somewhere in my hobby room.
It did happen only once with v91, and when it happened, the pla fans were cooling the hotend by 4-5 degrees below set point. It has not happened again since then, had several successfull prints yesterday and today.
into some other file just to give it a totally different memory position. It it is hardware related it will then change something else. If it is out of array access it will trouble something else. If some part does it on purpose it will remain.
Based on ram yes one less. Delta printers are real ram consumer with all the subdivisions of moves for better quality. That is why I prefer the RADDS boards for my delta. With 96KB ram much better then the 8KB on the mega.
I checked the printer today, and the firmware is still v92.3, not v91. Something must have gone wrong while uploading v91. The problem is still present, changed the display to a 20x4 today (type 2 now instead of 11). Will try tomorrow if that helps. Radds 1.5 arrived today, but I will continue to test with ramps to help you find the error.
In a parallel thread a othe ruser has the same problem - also graphic display. I will analyse the added display code. As a counter test you could also try u8glib_ex.h from april which means before I added new drivers.
I tried u8glib_ex.h from april for several prints. None of those had a problem with dry mode. I switched to RADDS and arduino due with sparklab lcd then, also no problem here.
I have checked where debugLevel gets officially set. There are only 3 wanted methods:
1. M111
2. Extruder detects a problem - then you see a error message.
3. In the LCD debug menu.
I guess no one of you did one of them after a so long discussion. So the reason left is that the byte position storing debug variable get overwritten or changes on it's own (unlikely). Assuming it gets overwritten it must be a access to a variable nearby, so it would be great if everybody having the problem could create a memory map and show the area around debugLevel. Here is how it goes:
1. Close IDE
2. Open IDE_DIR/hardware/arduino/avr/platform.txt
3. Search line with compiler.c.elf.flags= and change that line into
I can provide .gcode, Firmware (2015/Nov/07) + Configuration.h from online-configuration-tool, decent Java-Programming-Skills and some basic knowledge about C++.
If it helps, @repetier, we can continue a conversation in german.
Great having someone with same issue and programming skills. Makes some things easier since I still have no printer with that problem. Since it happens without u8glib I agree that we can rule that out for now. I'm also printing now for days with 8 bit and u8glib without issue.
Then you should try to find out when this happens. As a first test add at the end of void Commands::executeGCode(GCode *com) in commands.cpp the following code:
This should write a message into your log along with the message as it received the printer and disable dry run, so print still succeeds. Then print and log everything and check for the message and post the 100 lines before that happens as well. Maybe it gives a hint if we have some failures so we see a pattern when it happen. Or we see that it understood M111, who knows. But it must not be the command execution. The problem could also be inside a interrupt handle or other stuff executed between commands. At least is helps us finding when it happens.
We could also add more inspection positions to narrow the bad code. Like
with xy different names so we know where. I'd add them to end of temperature interrupt and temperature manager. Once one triggers you add more of this at beginning of function to make sure it did not happen before etc. Hope you see what I mean. I guess that should be the fastest way to nail it down to a function going out of bounds.
Added the block in Commands.cpp and the define in Configuration.
Also tried adding in extruder.cpp after void Extruder::manageTemperatures() Guess this is what you mentioned as "TemperatureManager", right? Problem: "com" is unknown. Tried adding include for "Communications.h", but also got errors. Added this instead: #ifdef DEBUG_DRYRUN_ERROR if(Printer::debugDryrun()) { Com::printFLN("Dryrun was enabled - Temperature Manager"); } #endif Should be good, i guess?
Where does the temperature interrupt get processed?
And the most important thing: Any hint on working on this with Eclipse/Netbeans or any IDE that does not make me want to throw my computer out of the window? Do you develop with stock arduino IDE?
bye, Jan
p.S.: Is there any chance to log into some file with repetier-host?
Yes, manageTemperatures is one complex function running 10 times per second to set temperatures.
The interrupts are all in HAL.cpp near the bottom. But leave them until you have more informations. Writing in time critical interrupts is not the best to do, but works if it is not too much.
No, Arduino IDE is a pain. Just simple to install and compile. I used Codeblocks for arduino in a older version so far. That config file is also included, but with latest ide does not work I think. Need to test that and make it work some day.
I've also heard that Atmel Studio 7 now supports Arduino sketches directly. Needs also testing and would be great if it works. It is based on Visual Studio.
For file logging go to "Einstellungen->Grundeinstellungen" and activate "Logge Session" assuming you use german language. After next start it will log into workdirectory (Datei->Zeige Arbeitsverzeichnis).
Comments
http://pastebin.com/rc7pcJ9D
Also my cache move size is the default value wich I think it's 15, so should I decrease it any further?
Bye,
jan
Added the block in Commands.cpp and the define in Configuration.
Also tried adding in extruder.cpp after
void Extruder::manageTemperatures()
Guess this is what you mentioned as "TemperatureManager", right?
Problem: "com" is unknown.
Tried adding include for "Communications.h", but also got errors.
Added this instead:
#ifdef DEBUG_DRYRUN_ERROR
if(Printer::debugDryrun()) {
Com::printFLN("Dryrun was enabled - Temperature Manager");
}
#endif
Should be good, i guess?
Where does the temperature interrupt get processed?
And the most important thing:
Any hint on working on this with Eclipse/Netbeans or any IDE that does not make me want to throw my computer out of the window?
Do you develop with stock arduino IDE?
bye,
Jan
p.S.: Is there any chance to log into some file with repetier-host?