Smoothieboard loosing moves ?

Controllers Smoothie
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

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:
http:@@s16.postimg.org@3pw991wap@IMG_2621.jpg

nice….second trial:
http:@@s16.postimg.org@bjwuug43l@IMG_2622.jpg
the shifting on x-axis is clear.

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

3

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

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:
http:@@postimg.org@image@7eke66fdl@

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

Thanks.

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 ?)

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.

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”)

http:@@postimg.org@image@yzq6axmwn@

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

http:@@postimg.org@image@jo0c3wqel@

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.
Tks

9

wolf.arthur@gmail.com

10

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

http:@@postimg.org@image@uyf0hs1vz@

I just emailed you this file too (zipped)

Thanks

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 )

Cheers.

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.

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.