Simplify3D & Smoothie stalled print

[moo10032]

It could be "ground loop". I had a really weird similar problem with my smoothie randomly stopping. You need to have the printer on the same outlet/power strip as your computer controlling the board.

[LeonMF]

It could be "ground loop". I had a really weird similar problem with my smoothie randomly stopping. You need to have the printer on the same outlet/power strip as your computer controlling the board.

This is a very specific problem with S3D and Smoothie. No ground loops here as I'm printing from SD card.

[CompoundCarl]

The smoothie firmware is choking on the S3D gcode files. It happens even when you run those files from the SD card, so it doesn't have anything to do with the simplify3d usb communication. It's just a bug in smoothie's gcode processor.

[tpete61]

Hmmmm, seems like the forum moderators removed my unkind post yesterday about simplify 3D not working with Smoothieboard.

[LeonMF]

FYI, there is a test build here: https://groups.google.com/forum/#!topic ... z2VbP7muoY

So far in (all of) one 13 hour print of a complex part, I didn't get the problem. In the past, this was a high likelihood of failure.

There are no guarantees but, if you have issues, it's worth trying this bin file.

[LeonMF]

All,

The smoothie team has posted a potential fix over in the smoothie forum here: https://groups.google.com/forum/#!topic ... r0JLV3G5i8

The text of the post is here. It appears that Smoothie generates too many moves with some models and it's a significant problem but the team was able to fix it.

Here's the relevant text snippet from Arthur Wolf, the developer.
-------------------------------



Debugging the problem was rendered extremely difficult by the fact that the bug is very complex to reproduce reliably ( some bugs are like that ). But with the help of the community, we were relatively quickly able to find out why the bug only occurred with S3D : simplify3D does not simplify high resolution models, resulting in uselessly high levels of detail in the G-code files ( long strings of moves up to 0.0002mm long are commonly found, which is 100 times smaller than some 3D printer resolutions ).
Other more mature slicers on the other hand do simplify the models, and so they are not concerned by this ( Slic3r lets you set the simplification resolution yourself but has a sane default, one user who changed the default reported this problem also ).
While rarely used to our knowledge, Kisslicer also does not simplify models and therefore is probably also subject to this problem.

With a lot of help from Leon Grossman, who had been able to reliably reproduce the problem, and was able to open a debugging session while the bug was occurring, we figured out why the bug only occurs with Smoothieware ( several edge cases related to floating point math and single-step movements, which do not happen unless insanely small movements are sent ).

Jim Morris devised some fixes for this bug in a separate branch ( https://github.com/wolfmanjm/Smoothie/t ... d-fix-hack ). Leon has been testing it for many print-hours successfully, so we think it is time to ask the wider Smoothieware community to test these fixes, and tell us if for them also, they resolve the freezing problems.

I would like to emphasize that we have already proposed a possible fix for the community to test before, and while it did improve ( reduced the frequency of the problem ), it did not fix it completely. This was interpreted by some as claiming the bug was fixed but failing to actually fixing it, which is not what happened, we simply asked for the community's help in finding out if the fix was good or not, we did not claim it was a definitive fix.

This time again, we are not claiming this is 100% certain to fix the problem for everybody, but both our new understanding of the problem, and the testing that has been done so far, gives us very good confidence this could be definitively resolved. And so we ask for your help testing it.

If you want to help us test this fix, and in particular if you have ever experienced the freezing problem, here is the procedure :

1. Download the "firmware.bin" file attached to this message, or here : https://www.dropbox.com/s/yufuad7qj4e6i ... e.bin?dl=0
2. Drop it onto your SD card
3. Reset the Smoothieboard. The file should be renamed to "FIRMWARE.CUR" automatically.
4. Use everything as normal
5. If the printer freezes, report here

Thanks a lot to all of you for all the help and support so far, thanks to all those who will test this.

We sincerely hope this is the end of the problems some of you have been experiencing. Hopefully S3D also fixes the problem on their end at some point, which would make things doubly nice.

[LeonMF]

The Smoothie devs are working on a fix for the problem caused by too small moves generated by Simplify3D. In the mean time, there are a couple of options to post-process your code before printing if you experience the problem described in this thread.

Option 1 Use Mikk's parsing program: http://mikk36.eu/SimplifyS3D/
GitHub: https://github.com/Mikk36/SimplifyS3D

Option 2 Use my OSX program (unsigned) , attached here.
GitHub: ttps://github.com/leonmf/S3DFix

For either application, set minimum XY move distance and minimum extrusion distance. This will filter out lines of code which are too small for the printer to even attempt. The web version processes faster than my version in written for the Mac but my version can live write in your launch bar for easier access.

Enjoy!