Terrible print quality using Octoprint over USB connection

[wesc]

I wouldn't normally use Octoprint, but it's necessary for the Mosaic Palette to work with Duet.

When printing over USB, I get terrible underextrusion and no bed adhesion. The same exact file printed natively using DWC prints fine. This is with a normal .gcode - the Palette machine is turned off, though it happens when trying to print with the Palette.

In the pic below, the currently printing bit is from Duet. The mess on the right is what comes out with Octoprint.

This configuration worked fine the last time I printed with Palette a month ago. Nothing of significance has changed about my machine since then.

Image of problem here:

The Octoprint terminal log shows the lines being sent with Recv: ok replied. The lines sent match the original GCODE except with line numbers and *checksums

I have tried powering the raspberry Pi with a USB battery pack, thinking it's some ground loop thing. No luck.

I have tried various baud rates for the connection.

Not sure what else to try...

Firmware Electronics: Duet WiFi 1.02 or later
Firmware Version: 2.03RC5 (2019-06-05b5)
WiFi Server Version: 1.23
Web Interface Version: 1.22.5

Octoprint 1.3.10
No plugins except the two for the Palette.

[dc42]

This type of problem is usually caused by a combination of Octoprint assuming that it's talking to an 8-bit board so that it has to wait for "ok" before it's safe to send another command, and the operating system that Octoprint is running under not being a real-time OS, so that it doesn't give priority to Octoprint when the "ok" is received.

With the Duet, it's not necessary to wait for the "ok" response, because the USB connection has driver-level flow control. So it's much faster to stream the GCode over USB and let the drivers do the flow control. The baud rate is not used, the transfer will proceed as fast as possible.

A year or two ago, someone did a patch to Octoprint to not wait for the "ok". I don't know whether that ever made it into the Octoprint source as a user-settable option.

Gina (the creator of Octoprint) has a Duet, so she may be able to help. Alternatively, can you run the Mosaic from the Duet? I think other users have done that.

[Phaedrux]

@dc42 said in Terrible print quality using Octoprint over USB connection:

I don't know whether that ever made it into the Octoprint source as a user-settable option.

Yes, it is configurable now.

@dc42 said in Terrible print quality using Octoprint over USB connection:

can you run the Mosaic from the Duet? I think other users have done that.

No, the Octoprint device is still required to synchronize the printer with the palette. You can try to use the Palette directly with the Duet without the octoprint, but synchronization is much harder to do with physical filament "pings". (Not that it's great with the octoprint either, but I digress)

@wesc said in Terrible print quality using Octoprint over USB connection:

Nothing of significance has changed about my machine since then.

Nothing at all? Or nothing that you think is significant?

@wesc said in Terrible print quality using Octoprint over USB connection:

2.03RC5

Perhaps time to update to the full release of 2.03

[wesc]

Phaedrux,
I can't seem to find this setting to not wait for OK in Octoprint - I'm on the latest version.

What I'd really like is Palette integration with Duet, so Octoprint isn't needed. I'm not sure what it involves hardware wise, but i believe the handshaking with the Palette is relatively simple.

[Phaedrux]

@wesc said in Terrible print quality using Octoprint over USB connection:

What I'd really like is Palette integration with Duet, so Octoprint isn't needed.

Make the request on the Mosaic forum and let them know you'd like to see this. I'm not sure how easy it would be to implement though, because the Duet is not a USB host and neither is the Palette. Somehow the two would need to be synchronized.

The octoprint as an intermediary isn't such a bad idea, but it would be better if Octoprint worked better with the Duet. If it could start the print on the Duet and allow it to print via SD card rather than streaming over USB and yet still maintain awareness of progress and have some means of flow control so that the Palette could stay in the loop for accurate filament production monitoring.... Sadly it's a far more complicated problem than it first appears.

@wesc said in Terrible print quality using Octoprint over USB connection:

Phaedrux,
I can't seem to find this setting to not wait for OK in Octoprint - I'm on the latest version.

I don't have an octoprint instance up and running at the moment, but I believe it's either in the octoprint settings or in the printer setup in octoprint.

[dc42]

@phaedrux said in Terrible print quality using Octoprint over USB connection:

The octoprint as an intermediary isn't such a bad idea, but it would be better if Octoprint worked better with the Duet. If it could start the print on the Duet and allow it to print via SD card rather than streaming over USB and yet still maintain awareness of progress and have some means of flow control so that the Palette could stay in the loop for accurate filament production monitoring.... Sadly it's a far more complicated problem than it first appears.

It sounds to me that it's not possible using Duet 2, except by bypassing the Mosaic electronics and having the Duet drive the Mosaic hardware directly, if that's possible. But on Duet 3 it should be possible to implement as a plugin.

[wesc]

@phaedrux, I don't see any setting that remotely looks like Ignore OK/Don't wait for response, etc in the settings or printer settings panels.

If you can take a look when you can get Octoprint up, let me know.

Thanks,

[Phaedrux]

@dc42 the mosaic slicer produces 2 files, one gcode file for the printer and the other for the palette. That palette file either goes on its own sd card or gets set to it by octoprint. I can't see any means of the duet controlling the palette directly at this time.

[wesc]

@phaedrux Doesn't It also has a mode where it makes one file, with the Palette stuff at the top of the .gcode file (Connected, vs accessory, where 2 files are made). The Duet could feed those O commands to the palette if a hardware means was available.

[dc42]

@phaedrux said in Terrible print quality using Octoprint over USB connection:

@dc42 the mosaic slicer produces 2 files, one gcode file for the printer and the other for the palette. That palette file either goes on its own sd card or gets set to it by octoprint. I can't see any means of the duet controlling the palette directly at this time.

So you are forced to use their slicer? That's bad, and IMO a good reason not to use it. Is the slicer open source?

[wesc]

@dc42 There is a plugin for Slic3r made by 3rd party devs (P2PP). Mosaic also has a tool that post processes gcode (Chroma).

The slicer - http://slicer.io is cloud based, and it's OKish. It does have a really nice paint a STL tool that works well.. The engine is based on Kiss codebase.

[Phaedrux]

@dc42 there are options. You can either use their cloud slicer called Canvas, or you can use your own (Cura or slic3r) provided they are configured correctly for multi STL multi color printing according to the mosaic requirements, and then post process the resulting gcode with a seperate program they provide called Chroma. Nothing from mosaic is open source at the moment as far as I know.

Canvas is attractive because soon it will allow for "painting" a standard STL file with multiple colors and then it will produce a multicolor print. I believe that it's built upon kisslicer.

[Phaedrux]

@wesc said in Terrible print quality using Octoprint over USB connection:

@phaedrux Doesn't It also has a mode where it makes one file, with the Palette stuff at the top of the .gcode file (Connected, vs accessory, where 2 files are made). The Duet could feed those O commands to the palette if a hardware means was available.

Accessory mode uses physical filament movement and pauses to sync with the palette. So even if the duet had a means of transmitting that data to the palette, the palette firmware would need to be changed to function with it.

It's too bad the palette doesn't have a can bus option.

The duet3 with SBC may be able to do connected mode in a more useable fashion but mosaic would need to target it with a plugin like it has with octoprint.

[wesc]

@phaedrux Very unlikely Canvas will be OS. The Kiss dev is very protective of his codebase. Really frustrating because with a few features and tweaks and some needed UI love it could be the best slicer out there.

[burtoogle]

@phaedrux said in Terrible print quality using Octoprint over USB connection:

You can either use their cloud slicer called Canvas, or you can use your own (Cura or slic3r) provided they are configured correctly for multi STL multi color printing according to the mosaic requirements, and then post process the resulting gcode with a seperate program they provide called Chroma.

I have recently been making some additions to my Cura fork at the request of someone with a Palette. The changes are related to enforcing min lengths of filament extruded when switching materials. So if the amount of material used in the print is too small, the prime tower gets more. It's WIP and not yet verified as correct.

[nophead]

Interesting conversation but I can't see why Octoprint would produce the mess shown. I print with it over USB on a Melzi with Marlin and an original RPI B day in day out.

Yes has a limit to how many line segments per second it can produce but I never hit that with my own designs from OpenSCAD. The symptoms of the gcode not arriving fast enough are it pauses on curves and the prints get blobby. The amount of filament should be correct though and given first layers are normally done slowly anyway I think something else is going wrong.

[wesc]

@phaedrux

I don’t see how duet could not function in exactly the same way octoprint does, entirely replacing it.

Octoprint feeds gcode to the printer, looking for O codes. It sends O codes to palette for processing there. There’s also the ping pong dance of communication to synchronize filament lengths between the two.

[wesc]

@nophead this is laying down the first layer, 20mm/s slow with lot of straight line infill.

kiss/canvas does produce huge gcode files in its implementation of pressure advance (lots of tiny segments).

The weird part is this did work at some point, printing at 100mm/s with palette with no problem. So something else has gone south.

[nophead]

@wesc Doesn't the Duet do its own pressure advance? In which can't you tell Kiss to not do its own?

Does the motion slow down and stutter or does it move correctly but under extrude?

[wesc]

@nophead it moves correctly, but underextrudes. Missed gcodes would behave that way, I’d think.

I won’t be able to try again until after this weekend. Could try with prusaslcicer which generates much simpler gcode