Mini Kossel Pausing on and off while printing with new firmware update

edited May 2015 in Repetier-Firmware
Upgraded my firmware to latest website version 2 days ago had horrible prints since. blobs all over the place. after checking everything and find that retraction wasnt the issue. i started to watch a whole print then notice the printer would stop dead in its tracks (ozze would happen leaving a blob) then kicks back into like. this happens for around half a second 2 - 3 times a layer!!

Iv taken a video of it happening and slowed down the moment when it stops then carrys on. not this is even while doing the skirt!!



iv reset eeprom, restarted a new firmware from scratch, lowered segments to as low as 80, tried a new SD Card, tried printing via repetier software with gcode on hdd. all with the exact same results!

code is being made using cura and the 3dbency model.  which i have been printing for the past 2 weeks with no issues at all.

any ideas as im competly lost here guys and printer is unusable

Comments

  • Hard to say without more informations. Stops normally mean buffer was down to 0 - if you have a lcd you can see this.

    For more details you would need to check the printlog at least when printing from host. There I could argue you are having some com errors causing the wait. From your comment is looks like you are printing from sd card, so I would not expect that. Anyhow it may help to find what is going on if you check the log while printing from host.

    If you have a graphic lcd that can also cause blobs. It takes 0.1s to update the screen in the optimized version and in that time the print queue does not get refilled. We have added some new drivers but haven't changed anything in the old drivers. But maybe u8g internal selector now uses a even slower version for communication. As a test you could disable the lcd and see if blobs are gone.


  • Hi

    iv just found month of arduino sketch from 09/04/15 flashed and working so far no issues.

    im printing from SD card
    LCD im using is reprap discount normal size setup with sd card (the common one)

    im also using auto level and z correction but always have been.

    i only upgraded to i could easily reverse encoder knob via website config.

    interested to know if other people are having same issue or just me?

    is there a way of seeing version number on dowloaded versions from website?
  • No, website version is not updated very frequently as it is development version. Only on github you can see from comments for commits what changed.

    With standard display did you mean 40x4 character display? That code has not changed and is also much faster as it only needs 160 byte per update.

    z distortion correction is quite new and increases computation time, mainly for lower z where the effect is not 0, at least if you have enabled reduction to zero over z.

    As my only delta has 32 bit electronics it would be great to hear if it still works for others with 8 bit and if not if someone can say since which commit it started to get problems.
  • Hi

    Back working on this again.

    I found an old arduino sketch for my older firmware dated 09/04/15 from the website. flashed this back on and no problem at all.

    just tried latest website code today and getting stops again.

    has anything changed between those dates?

    my next test is to try without z correction and see if that helps.

    to note i am getting warning while flashign that in near limits of arudino board and may cause instablilty (not exact error!)


  • just lowered z correction points from 7 to 5 (i was changing this on new firmware) think this may be whats killing the memory.

    time to look into a 32 bit due i think :|
  • I guess around 30 commits since that date. But I'm not really working on delta movement code. That works and I do not plan touching working code.

    Since you get memory warnings and new features also take memory it might be a memory problem. Can you try reducing move buffer count by 1 to free some ram again. If it then vanishes, it is simply too much ram usage also that normally would mean some errors.


  • Seems to have reappered in a reflash (i changed probe to inductive so had to reflash)

    were can i find the move buffer count so i can lower it?

    Thanks
    luke
  • Configuration.h

    /** \brief Number of moves we can cache in advance.
    This number of moves can be cached in advance. If you wan't to cache more, increase this. Especially on
    many very short moves the cache may go empty. The minimum value is 5.
    */
    #define PRINTLINE_CACHE_SIZE 14
  • Hi

    Found #define PRINTLINE_CACHE_SIZE 16

    Changed that to 14. still got a pause.

    Then lowered it to 10 and still got a pause.

    Pause is always in the same spot. and also i have now tried with 2 boards, ramps 1.4/mega2560 and now a rumba both with same results.

    any other ideas??
  • So if it is always the same spot it should be possible to extract that gcode for analysis. A pause normally means print buffer is empty e.g. because many short lines could not get send fast enough. With a lcd display you might even see a drop but with 1s refresh rate it might also miss it. That is why extracting the gcode would be usefull. We could see what causes it and can better analyse possible reasons. For debugging problems you first need to identify the real problem not the symptom (pause)

    If you say pause how many seconds do you mean? Or are iot mor emilliseconds?

    You could also try disabling distortion control if you have compiled it
    #define DISTORTION_CORRECTION         0

    That function requires extra computation time. 
  • Okay interesting update!! and do with some help analysing the gcodes!

    I use cura for my gcode generation.

    thought i would try slic3r see if i get same result. i didnt notice the issue. (i only ran for a while though)

    here is Gcodes for both and also the STL.


    Can someone have a quick look see if they can see an issue?

    Cura gcode can be see pausing in the video at the top of the page. (to note video slows down to show issue)
  • Obviously the cura files are nearly twice as long so the average move length is only half the size as slic3r has. So firmware has more to compute and host more to transfer. I also see much slowdowns in slic3r code so I think it prints critical parts also slower giving more computation time.

    My guess is if you reduce cura speed to 50% the pauses will also go away. If true you might need to find the limit which the printer still can handle. 50% is just a save value and truth will be somewhere in between.
Sign In or Register to comment.