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

Comments

• Repetier

  May 2015

  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.

  
  

  
  
• Enlightx

  May 2015

  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?
  
• Repetier

  May 2015

  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.
• Enlightx

  May 2015

  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!)
  
  
  
• Enlightx

  May 2015

  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
  
• Repetier

  May 2015

  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.

  
  

  
  
• Enlightx

  June 2015

  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
  
• Repetier

  June 2015

  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
• Enlightx

  June 2015

  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??
  
• Repetier

  June 2015

  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. 
• Enlightx

  June 2015

  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)
  
• Repetier

  June 2015

  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.