Simplify3D & Smoothie stalled print

[LeonMF]

For several months, a few of us in the Smoothie community have been experiencing a weird symptomology when using Smoothie with Simplify3d. At some point, and it will be the same point for a given gcode file every time, the printer will stop moving and the extruder will sing at a constant frequency without moving. For some models, the failure point is early, sometimes it's two hours or more into a print.

The problem:
* Only happens when Simplify3D is the slicer
* Only happens when running from SD card (as opposed to over USB)
* Always involves an circle/elipse or high detail model.

The current theory of the smoothie devs is that Simplify3D is slicing moves into segments smaller than the useful resolution from the printers.

Does anyone else have any experience with this? Some flags to modify the slicing to avoid these small moves? Apparently, the Smoothie team has reached out and received no response or help.

EDIT: I forgot to describe the symptomology

[tenaja]

I have an unused Smoothie board, so I'm interested in what you come up with.

Have you been able to duplicate it on a single layer, so you can approximate the location?

[LeonMF]

I have an unused Smoothie board, so I'm interested in what you come up with.

Have you been able to duplicate it on a single layer, so you can approximate the location?

Sadly, it's not that simple. It has happened as early as the first layer for some prints and as late as a few hours in. It's not predictable other than that it will cause smoothie to crash at the same spot in a given file every time.

[innkeeper]

the only time I get stalled prints is when I am using S3D to start off the SD prints and monitor.
do you get this when your not using S3D to start the SD print and monitor?

I happen to have a GLCD connected to my smoothie, and always start and monitor the prints from the GLCD, and never have a problem.
I do get stalled prints if I kick off a SD print though S3D though.

id say try kicking of the prints that stall though one of the many ways you can do it without using S3D, like the web interface, or telnet in and do it from the command line...and see if you have the same problem... maybe even try using ponterface to kick off the print.

I would be curious if your experience is the same as mine in that all other methods of actually running the print work fine and it only stalls when initiated and monitored form S3D.

[innkeeper]

oh and, you might want to comment on the feature request board for having S3D support smoothie officially

[tpete61]

I can second have a problem with the smoothieboard and the GLCD. I also can have a print randomly stop.
It's a head scratcher as it is totally random. Sometimes I can re-output the file to an SD card and a print will finish.

[tenaja]

Sadly, it's not that simple. It has happened as early as the first layer for some prints and as late as a few hours in. It's not predictable other than that it will cause smoothie to crash at the same spot in a given file every time.

If it crashes at the same spot every time, then that is very predictable, and a lot easier to debug. You should try to go back to one of those files that crashes on the first layer, then the command can be isolated.

From what innkeeper says regarding the monitor, It may actually be a Smoothie bug that presents itself with S3d code, and not an issue with S3d itself. Isolating the command will confirm this one way or the other. Probably not what you want to spend your time doing, but with the current information, S3d can easily say it's not their bug until you can demonstrate otherwise.

[tpete61]

You may want to load the stable firmware for your board. I was having problems with multiple different STL files running on the current "edge" firmware. They always halted at the same spot. I rolled back to the stable firmware for smoothie tonight. I haven't had a problem so far.

[JoeJ]

This sounds like a pretty obvious bug with the smoothie firmware. Probably something in their motion planner. Maybe a divide by zero or something like that.

You have to keep in mind that S3D gcode is running on dozens of other firmwares out there without any issues. So however S3D is slicing stuff doesn't create any issues with any of those other firmware packages. That seems like a pretty strong argument that this is an issue in the smoothie firmware.

[innkeeper]

if so, then why does it only occur with simplify3d.
also, why, according to the smoothie team, doesn't the simplify3d team seem to want to work with the smoothie team to look into it.
very strange ...