Extruder stops extruding

24

Comments

  • Compiler shows it at least in newer version. When you connect you see it also in the log.
  • Ok so I found this in the log from today:
    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.
  • That is more then enough ram.

    Are we talking abount 0.92.3 firmware version?
  • 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.
  • So far no problems with firmware v91...printed several parts today, all were ok, no dry mode today.
  • 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)

    And last, here is my current config for v92: http://pastebin.com/L1e6ZvmA

    PS: I have a delta printer (custom made, but similar to a rosstock, and not much bigger) with a ramps 1.4
  • edited June 2015
    My configuration for firmware v92:


    http://pastebin.com/rc7pcJ9D
  • Just a minute ago I was wondering why the printer sounded different....dry mode was enabled with firmware v91 while printing from sd card.
  • 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.

  • To rule out a array overwrite (which I think is not very likely as it would also overwrite other variables) you could move
    Printer.cpp line:

    uint8_t Printer::debugLevel = 6; ///< Bitfield defining debug output. 1 = echo, 2 = info, 4 = error, 8 = dry run., 16 = Only communication, 32 = No moves

    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.
  • I'll check the next week when I hope to be back in painting.

    Also my cache move size is the default value wich I think it's 15, so should I decrease it any further?
  • 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.
  • Thanks for your endurance. My printing tests all worked so far, so no chance to see it happen there I guess.
  • Little update... I have been printing yesterday for 8 hours without dry mode problems. Only change was the display type.
    I will continue to print today, just to be sure it really works.
  • 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.
  • OK, I will try that tomorrow.
  • OK, I'll also test (finally my printer is printing again!)
  • So far no dry run issues encountered. I'm keeping my fingers crossed since i'm starting a 8h nylon print
  • 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

    compiler.c.elf.flags=-w -Os -Wl,-Map,c:\temp\memlist.map,--gc-sections

    and save. You can adjust the path c:\temp\memlist.map which is the memory map needed.
    4. Compile and open c:\temp\memlist.map
    5. Copy the area around debugLevel. Here an example how it looks for me:

     
  • edited August 2015
                    0x008002e7        0x4 C:\Users\littwin\AppData\Local\Temp\build2486305431805331772.tmp\motion.cpp.o
                    0x008002e7                baudrate
     .data.stepperInactiveTime
                    0x008002eb        0x4 C:\Users\littwin\AppData\Local\Temp\build2486305431805331772.tmp\motion.cpp.o
                    0x008002eb                stepperInactiveTime
     .data._ZN7Printer7memoryFE
                    0x008002ef        0x4 C:\Users\littwin\AppData\Local\Temp\build2486305431805331772.tmp\Printer.cpp.o
                    0x008002ef                _ZN7Printer7memoryFE
     .data._ZN7Printer15extrusionFactorE
                    0x008002f3        0x4 C:\Users\littwin\AppData\Local\Temp\build2486305431805331772.tmp\Printer.cpp.o
                    0x008002f3                _ZN7Printer15extrusionFactorE
     .data._ZN7Printer17stepsPerTimerCallE
                    0x008002f7        0x1 C:\Users\littwin\AppData\Local\Temp\build2486305431805331772.tmp\Printer.cpp.o
                    0x008002f7                _ZN7Printer17stepsPerTimerCallE
     .data._ZN7Printer10debugLevelE
                    0x008002f8        0x1 C:\Users\littwin\AppData\Local\Temp\build2486305431805331772.tmp\Printer.cpp.o
                    0x008002f8                _ZN7Printer10debugLevelE
     .data._ZN7Printer38maxTravelAccelerationMMPerSquareSecondE
                    0x008002f9       0x10 C:\Users\littwin\AppData\Local\Temp\build2486305431805331772.tmp\Printer.cpp.o
                    0x008002f9                _ZN7Printer38maxTravelAccelerationMMPerSquareSecondE
     .data._ZN7Printer32maxAccelerationMMPerSquareSecondE
                    0x00800309       0x10 C:\Users\littwin\AppData\Local\Temp\build2486305431805331772.tmp\Printer.cpp.o
                    0x00800309                _ZN7Printer32maxAccelerationMMPerSquareSecondE
     .data._ZN7Printer14homingFeedrateE
                    0x00800319        0xc C:\Users\littwin\AppData\Local\Temp\build2486305431805331772.tmp\Printer.cpp.o
                    0x00800319                _ZN7Printer14homingFeedrateE
     .data._ZN7Printer11maxFeedrateE
                    0x00800325       0x10 C:\Users\littwin\AppData\Local\Temp\build2486305431805331772.tmp\Printer.cpp.o
                    0x00800325                _ZN7Printer11maxFeedrateE
     .data._ZN7Printer14axisStepsPerMME
                    0x00800335       0x10 C:\Users\littwin\AppData\Local\Temp\build2486305431805331772.tmp\Printer.cpp.o
                    0x00800335                _ZN7Printer14axisStepsPerMME
     *(.rodata)
     *(.rodata*)
     .rodata._ZTV16RFHardwareSerial
                    0x00800345       0x10 C:\Users\littwin\AppData\Local\Temp\build2486305431805331772.tmp\HAL.cpp.o
                    0x00800345                _ZTV16RFHardwareSerial
     *(.gnu.linkonce.d*)
                    0x00800356                . = ALIGN (0x2)
     *fill*         0x00800355        0x1 
                    0x00800356                _edata = .
                    0x00800356                PROVIDE (__data_end, .)

    .bss            0x00800356      0xa70
                    0x00800356                PROVIDE (__bss_start, .)
     *(.bss)
     *(.bss*)
     .bss.fanKickstart
                    0x00800356        0x1 C:\Users\littwin\AppData\Local\Temp\build2486305431805331772.tmp\Commands.cpp.o
                    0x00800356                fanKickstart
     
  • Looks the same as my map:-) So hope it keeps gone also I haven't knowingly changed a thing that relates to it.
  • edited November 2015
    Hi!
    Unfortunately I fight this issue for some days now. (CoreXY, Ramps 1.4, reprap discount full graphics controller)
    I recompiled the firmware with LCD support disabled and got the same behaviour again.
    So I think u8glib is out of focus now?
    Also disabled thermal decoupling check.

    Print stops reproducably mid-print somewhere between layer 10-40 in my test-object (http://www.thingiverse.com/thing:669459 The version for 2 pushfits)

    Anything I can do to help digging into this?
    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.

    Bye,
    jan
  • 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:

    #ifdef DEBUG_DRYRUN_ERROR
        if(Printer::debugDryrun()) {
            Com::printFLN("Dryrun was enabled");
            com->printCommand();
            Printer::debugLevel &= ~8;
        }

    and in your configuration.h add
    #define DEBUG_DRYRUN_ERROR

    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
    #ifdef DEBUG_DRYRUN_ERROR
        if(Printer::debugDryrun()) {
            Com::printFLN("Dryrun was enabled xy");
            Printer::debugLevel &= ~8;
        }
    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.

  • edited November 2015
    Hi!

    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).
Sign In or Register to comment.