Smoothieboard loosing moves ?

(pbisiac_SW) #1

Hi all,
My printer (custom hw with smoothie board) looses moves. When I print non-banal objects at some time (never at the same point) my printer “looses a move”, and from that moment on shifts every path by 0,5……5mm on X or Y axis.
I am not talking about loosing steps, I suppose this would lead to imperfections in my prints, my diagnosis is that either Robot or Planner miss to interpret some gcodes.
When I send my extruder to (0,0,0) it actually returns to (ofsX, ofsY, 0), so I am quite sure it looses entire moves.
I tried many things to understand where problem could arise. On hardware side, I added a separate power supply for heated bed, just in case. I set the pulse length to 2uS. i tried to put a fan directly on motor drivers……no relief.
It seems like the problem is more frequent which rounded objects, so I supposed that firmware would eventually run out of blocks…I set planner_queue_size to 64 and now things seem to go better (1 object successfully printed so far).
But this could just be a fluke.
Should I add some printf’s in Planner/Robot.cpp etc in order to discover allocation/queue errors ?
Thank you, regards

Imported from wikidot

(pbisiac_SW) #2

Update: even with planner_queue_size set to 64 problem doesn’t disappear, sometimes gets even worse. I printed a threading twice. Firs result:
(please substitute @ with / and @@ with //, for some reason I cannot post links, low Karma :wink:

nice….second trial:
the shifting on x-axis is clear.

Both prints from the same file……pleas help, i am running out of ideas……

(Arthur Wolf) #3

Do you have G3 G-codes in your G-code file ?

(pbisiac_SW) #4

Hi, actually not, the only occurrence is a comment:
; arcReplaceG2G3,0

My files are generated by Simplify3D. If you want I can send you a file (2MB) that show this inconvenience almost at every print….

Here another trial:

(Arthur Wolf) #5

We have had several recent reports of problems with S3D.

Can you try :

  1. Generating the G-code with S3D, but sending it with Pronterface
  2. Generating the G-code with Slic3r and sending it with Pronterface


(pbisiac_SW) #6

I am generating the G-code with S3D, copying to SD via filesystem and then launch printing from Pronterface (gcodes are red directly from SD). In the past I had bad experiences sending files directly from Pronterface (delays, bad arcs etc.)
I will try to slice my file with slic3r……but……why files sliced with S3D should perform differently at every print ? I suppose they should fail always at same point…….
Shall I reset planner_queue_size to 32 (or try with different values ?)

(Arthur Wolf) #7

Yes, please try setting the size back to 32, and generating the G-code with Slic3r, and tell us if it makes a difference.

(pbisiac_SW) #8

Hi, I have some interesting news

I re-sliced my object with slic3r (took a while to find out right parameters) and launched a print on my smoothie board-powered printer; so far, no more shift error (albeit slicing is much less efficient and printing is less “smooth”)

Yesterday evening, I sent S3D file to a friend’s printer (Ultimaker 2) and work came out quite perfect (gray item on the right)

So….sound like there is some misunderstanding between S3D and smoothieware…

If you give me an email address I can send you both files for further investigation.

(Arthur Wolf) #9

(pbisiac_SW) #10

Hi, I jus started printing a new object sliced with slic3r, and had same problem

I just emailed you this file too (zipped)


(Arthur Wolf) #11

A few things to investigate in case of skipped steps : 

  • Reduce acceleration
  • Reduce junction deviation ( divide by 10 each try )
  • Make sure it’s not a mechanical problem ( most of the time it is )
  • Make sure the current is set to the exact value specified for the steppers
  • Make sure there is no over-heating of the drivers ( rare )


(pbisiac_SW) #12

Hi, I followed your suggestions, one by one
After many trials, reducing acceleration from 3000 to 1500 mm/second/second seem to solve problem.Obviously my printer is quite slower now.
I will make more trial prints, to be sure, but a doubt remains: how do I find the highest accel value that does not leads to skipped steps ? by trial and error only ?

Thank you again for helping.

(Arthur Wolf) #13

how do I find the highest accel value that does not leads to skipped steps ? by trial and error only ?

That’s generally how it’s done yes.