Stuttering on high resolution curves over USB

[Josh Carter]

My delta has been experiencing issues lately with stuttering on high res curves, leaving behind terrible blobbing due to the hot end's repeated, short pausing. 

This seems to happen primarily with gcode produced by Simplify3D, however models I sliced with Craftware do the same thing.

Both of these, if I print directly from the USB print, high res curves pose no problem and tend to come out nicely. 

However, from Octoprint (my normal print host, running on a Raspberry Pi) and my laptop running pronterface stutter quite badly.

These same objects, when sliced with slic3r print fine over USB. 

My initial guess is that this is due to the same issues that caused the freezing issues with S3D.

Printing slower (<= 30mm/s) helps the issue, but doesn't solve it. 

This is pretty confusing to me because the issue started pretty recently. 

My smoothieboard used to handle the output from S3D very well, aside from the occasional freezing that has now been largely resolved by the firmware posted recently.

Are there any settings I can change in my config that might help? Maybe something in S3D or on my print hosts?

This has been driving me nuts lately, any help you guys can provide is muchly appreciated!

[Arthur Wolf]

This is a well known problem with S3D, and any other slicer that will not simplify the models to reasonable resolutions.

S3D will generate movements at insane densities, which will cause problem with *any* system.

You need to simplify your file before feeding it to Simplify3D ( ironically ).

Slic3r is much more mature and simplifies things.

I'd also contact S3D to ask them to fix the problem. It's been known for a long time, many users have reported it, and they do nothing. More pressure could help.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

[Josh Carter]

Fair enough. I will contact their support and ask them to work on this as well. 

I've been working on getting slic3r set up since S3D is becoming such a pain to use. 

Great work with the fix for the lockups caused by that gcode btw. It's nice not having to worry about that much at least lol.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Leon Grossman]

On a related note, I'm 90% done with a basic UI application written in swift for OSX to simplify files. I hope to have it posted on this forum by the weekend.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Arthur Wolf]

On Tue, Oct 20, 2015 at 8:33 PM, Leon Grossman <leongr...@gmail.com> wrote:

On a related note, I'm 90% done with a basic UI application written in swift for OSX to simplify files.

So, it simplifies 3D files ? I wonder how you should call it ^^
 

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--

You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Josh Carter]

Nice! I don’t currently have a Mac at home but if you plan on releasing the source I can probably port it over to .Net for us Windows users :)

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Courage et bonne humeur.

--
You received this message because you are subscribed to a topic in the Google Groups "Smoothieware Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/smoothieware-support/366acCUm5bA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to smoothieware-sup...@googlegroups.com.

[Leon Grossman]

I'm happy to release the source but it's largely based on the C++ code posted in the possible fix thread. Other than needing to wrap a gui around it and make the resolution filter parameters variables, it works the way it should.

Josh Carter

Tuesday, October 20, 2015 1:48 PM

Nice! I don’t currently have a Mac at home but if you plan on releasing the source I can probably port it over to .Net for us Windows users :)

--

You received this message because you are subscribed to a topic in the Google Groups "Smoothieware Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/smoothieware-support/366acCUm5bA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to smoothieware-sup...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Leon Grossman

Tuesday, October 20, 2015 1:33 PM

[Josh Carter]

Ahh! If that's the case I can grab that lol

[Mikk Kiilaspää]

Better code it in JS and serve it as a simple web app so that you load the file into the browser and get a fixed file back. Much more universal and easy to use for people.

[Mikk Kiilaspää]

Actually, might do it myself.

[Leon Grossman]

I thought about the web page option but I wanted to learn a bit of Swift and JS was more than I wanted to tackle.  I'm happy to see it happen if you do it, though!

[Mikk Kiilaspää]

Could You share a full file riddled with those tiny moves from S3D though? Don't have that program myself.

[Josh Carter]

I will once I get off work if somebody else hasn't already. :)

--

[David Crocker]

It's not just that S3D generates shorter segments than other slicers, it's also that Octoprint and Pronterface can't deliver data over the serial link at anything like the theoretical speed. The reason for this is that these host programs by default wait for the OK response after sending each command, and because this flow control is done at application level and not at device driver level, it is very inefficient.

However, this is completely unnecessary when using electronics with a native USB port and flow control implemented in the driver, which I presume includes Smoothie. I know you can turn off waiting for the OK response in Repetier host, in S3D and in Pronterface, but I don't know whether Octoprint supports this. If it does, I suggest you try it.

[Arthur Wolf]

On Tue, Oct 20, 2015 at 11:23 PM, David Crocker <davidcr...@gmail.com> wrote:

It's not just that S3D generates shorter segments than other slicers, it's also that Octoprint and Pronterface can't deliver data over the serial link at anything like the theoretical speed. The reason for this is that these host programs by default wait for the OK response after sending each command, and because this flow control is done at application level and not at device driver level, it is very inefficient.

However, this is completely unnecessary when using electronics with a native USB port and flow control implemented in the driver, which I presume includes Smoothie.

Sure.
 

I know you can turn off waiting for the OK response in Repetier host, in S3D and in Pronterface, but I don't know whether Octoprint supports this. If it does, I suggest you try it.

Actually, while this is helpful in a lot of case where the gcode is still sort of sane, S3D just generates Gcode of completely non-sensical densities ( we've seen as high as 100 lines to move 0.05mm ... )

Meaning even when printing from the SD card there is no way any firmware could handle it.

--

You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.

To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Mikk Kiilaspää]

Ok, initial version is up: http://mikk36.eu/SimplifyS3D/
Nothing fancy, all the code is in js/app.js.

On Tuesday, October 20, 2015 at 10:28:44 PM UTC+3, Leon Grossman wrote:

[Leon Grossman]

That was quick!

Mikk Kiilaspää wrote:

Ok, initial version is up: http://mikk36.eu/SimplifyS3D/
Nothing fancy, all the code is in js/app.js.

On Tuesday, October 20, 2015 at 10:28:44 PM UTC+3, Leon Grossman wrote:

    I thought about the web page option but I wanted to learn a bit of
    Swift and JS was more than I wanted to tackle.  I'm happy to see
    it happen if you do it, though!

    On Tuesday, October 20, 2015 at 2:05:55 PM UTC-5, Mikk Kiilaspää
    wrote:

        Better code it in JS and serve it as a simple web app so that
        you load the file into the browser and get a fixed file back.

     &nbs p;  Much more universal and easy to use for people.

        On Tuesday, October 20, 2015 at 6:54:37 PM UTC+3, Josh Carter
        wrote:

            My delta has been experiencing issues lately with
            stuttering on high res curves, leaving behind terrible
            blobbing due to the hot end's repeated, short pausing.

            This seems to happen primarily with gcode produced by
            Simplify3D, however models I sliced with Craftware do the
            same thing.

      &nbsp ;     Both of these, if I print directly from the USB print,

            high res curves pose no problem and tend to come out nicely.
            However, from Octoprint (my normal print host, running on
            a Raspberry Pi) and my laptop running pronterface stutter
            quite badly.

            These same objects, when sliced with slic3r print fine
            over USB.

            My initial guess is that this is due to the same issues

            that caused the free zing issues with S3D.

            Printing slower (<= 30mm/s) helps the issue, but doesn't
            solve it.

            This is pretty confusing to me because the issue started
            pretty recently.
            My smoothieboard used to handle the output from S3D very
            well, aside from the occasional freezing that has now been
            largely resolved by the firmware posted recently.

            Are there any settings I can change in my config that

  &nbsp ;         might help? Maybe something in S3D or on my print hosts?

            This has been driving me nuts lately, any help you guys
            can provide is muchly appreciated!

--
You received this message because you are subscribed to a topic in the

Google Groups "Smoothieware Support" group.

To unsubscribe from this topic, visit
https://groups.google.com/d/topic/smoothieware-support/366acCUm5bA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
smoothieware-sup...@googlegroups.com

<mailto:smoothieware-sup...@googlegroups.com>.

[Leon Grossman]

One more thing. I did have a freeze with these settings so I suspect that the default settings are a touch too low. Unfortunately, I haven't got an answer for the right settings.

Mikk Kiilaspää wrote:

Ok, initial version is up: http://mikk36.eu/SimplifyS3D/
Nothing fancy, all the code is in js/app.js.

On Tuesday, October 20, 2015 at 10:28:44 PM UTC+3, Leon Grossman wrote:

    I thought about the web page option but I wanted to learn a bit of
    Swift and JS was more than I wanted to tackle.  I'm happy to see
    it happen if you do it, though!

    On Tuesday, October 20, 2015 at 2:05:55 PM UTC-5, Mikk Kiilaspää
    wrote:

        Better code it in JS and serve it as a simple web app so that
        you load the file into the browser and get a fixed file back.
        Much more universal and easy to use for people.

        On Tuesday, October 20, 2015 at 6:54:37 PM UTC+3, Josh Carter
        wrote:

            My delta has been experiencing issues lately with
            stuttering on high res curves, leaving behind terrible
            blobbing due to the hot end's repeated, short pausing.

            This seems to happen primarily with gcode produced by

            Simplify3D, however mod els I sliced with Craftware do the

            same thing.
            Both of these, if I print directly from the USB print,
            high res curves pose no problem and tend to come out nicely.
            However, from Octoprint (my normal print host, running on
            a Raspberry Pi) and my laptop running pronterface stutter
            quite badly.

            These same objects, when sliced with slic3r print fine
            over USB.

        &nb sp;   My initial guess is that this is due to the same issues

            that caused the freezing issues with S3D.

            Printing slower (<= 30mm/s) helps the issue, but doesn't
            solve it.

            This is pretty confusing to me because the issue started
            pretty recently.
            My smoothieboard used to handle the output from S3D very
            well, aside from the occasional freezing that has now been

            largely resolved by the firmware poste d recently.

            Are there any settings I can change in my config that
            might help? Maybe something in S3D or on my print hosts?

            This has been driving me nuts lately, any help you guys
            can provide is muchly appreciated!

[Mikk Kiilaspää]

Also https://github.com/Mikk36/SimplifyS3D

[David Crocker]

Are you sure? 0.05mm is only 5 microsteps on a typical Cartesian printer, so 95 of those 100 moves should be getting thrown away immediately after conversion to machine coordinates, because they correspond to no movement. If there was "no way any firmware could handle it", I would expect people running Duet or RAMPS to be reporting this problem too with S3D files, even when printing from SD card.

On Tuesday, October 20, 2015 at 10:26:56 PM UTC+1, Arthur Wolf wrote:

...

[Leon Grossman]

I tested your web page. If I try to do multiple files in a row, the previous parsed files are incorporated in each subsequent file.

[Leon Grossman]

That should have been a reply to Mikk.

[Triffid Hunter]

On 21 October 2015 at 07:16, David Crocker <davidcr...@gmail.com> wrote:

Are you sure? 0.05mm is only 5 microsteps on a typical Cartesian printer, so 95 of those 100 moves should be getting thrown away immediately after conversion to machine coordinates, because they correspond to no movement. If there was "no way any firmware could handle it", I would expect people running Duet or RAMPS to be reporting this problem too with S3D files, even when printing from SD card.

Even if the null moves don't get queued, it still takes time to transfer them, parse them and convert them to integer steps before we can discover that it's a null move. That time adds up, and can cause the motion queue to starve.

Furthermore, the motion queue is only so long, and Smoothie always calculates speeds for each move so that it can safely decelerate if the queue starves. If there is a long sequence of extremely short moves, Smoothie's motion queue inevitably goes slowly to maintain this constraint as it can only "see" a couple of mm ahead in this situation.

When sequences of very short moves are interspersed amongst longer moves, this will definitely look like stuttering.

Before you ask, the length of the motion queue is primarily constrained by available ram and cannot be safely extended.

The correct fix is to never send these sequences of null moves bundled with extremely short moves in the first place. I find that moves smaller than about 0.2mm can be safely discarded with no visible difference in printed output.

Slic3r has options to do this automatically that work great, and that's why users that use slic3r never encounter this issue.

I have no idea why people are not reporting this issue with Marlin/etc, the issue shouldn't be related to any specific firmware implementation as it's caused by move density vs time to transfer and calculate.

[Mikk Kiilaspää]

Indeed, fixed.

[Mikk Kiilaspää]

When Cura had this kind of an issue, lots of people reported it, Ultimaker confirmed it as a bug and fixed it.

[Arthur Wolf]

On Wed, Oct 21, 2015 at 1:16 AM, David Crocker <davidcr...@gmail.com> wrote:

Are you sure? 0.05mm is only 5 microsteps on a typical Cartesian printer, so 95 of those 100 moves should be getting thrown away immediately after conversion to machine coordinates, because they correspond to no movement. If there was "no way any firmware could handle it", I would expect people running Duet or RAMPS to be reporting this problem too with S3D files, even when printing from SD card.

Well not everybody prints parts with insane levels of details. And even those that do do not always notice there is a problem.

People noticed the crappy Gcode S3D produces because it triggered a bug in Smoothie, would probably have gone largely un-noticed otherwise.

When I say "100 moves for 0.05mm", that's not a standard thing, just an example of how extreme it can get. We have seen many many different cases with different densities. It looks like the closer you are to "one line per microstep" the more problems you'll get. And S3D definitely *can* get you to those sorts of densities.

And by the way, i don't know about Duet, but I have definitely seen this density problem reported by S3D/Ramps users.

On Tuesday, October 20, 2015 at 10:26:56 PM UTC+1, Arthur Wolf wrote:

...

Actually, while this is helpful in a lot of case where the gcode is still sort of sane, S3D just generates Gcode of completely non-sensical densities ( we've seen as high as 100 lines to move 0.05mm ... )

Meaning even when printing from the SD card there is no way any firmware could handle it.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Josh Carter]

Is it possible that there may be some form of degradation happening with my Smoothieboard's communication over USB?

Even after simplifying the S3D files to 0.1mm resolutions and slicing with slic3r, I'm still having stuttering issues, and the stuttering seems to get worse from print to print, i.e. even printing the same object back to back might introduce stuttering where it was previously fine.

For example, this file: https://www.thingiverse.com/thing:725675

After simplifying the file with Mikka's javascript app, it was printing without any stuttering, however I was having some adhesion issues so I stopped the print and double checked my Z-height and found that I was just a little too far from the bed. 

Restarted the print after making the corrections and then it started stuttering a little on the screw holes. 

Stopped the print again, cleaned up the bed and sliced the same file with slic3r. There was still stuttering happening around the screw holes, and even a little worse than before.

I'm really beginning to suspect that I have a combination of issues compounding upon one another. 

Would one of you guys be willing to slice that object with S3D and try printing it?

[Triffid Hunter]

On 22 October 2015 at 22:19, Josh Carter <wpc...@gmail.com> wrote:

Is it possible that there may be some form of degradation happening with my Smoothieboard's communication over USB?

The most likely source of speed issues with suitably simplified models is your host sender, eg pronterface, especially if you're using an old/slow computer and haven't turned off the gcode viewer.

Try simply dumping the whole gcode file down the serial port (eg cat file.gcode > /dev/smoothie) and see if you get any stuttering. Note that it may take a long time to cancel your print using this method!

I've done thousands of prints with smoothie and never seen any stuttering except when my computer has choked on something and is swapping hard.

[wolfmanjm]

Another thing to check is that you have unmounted the sdcard from the host before you start to print. If the host tries to scan the sdcard (as macs like to do) then it will cause smoothie to stutter.

Also if there are  lot of 0.1mm segments in the gcode then it will still stutter as it is faster to move 0.1mm than it is to send down a USB block.

Printing from sdcard may be better in this case.