Terrible print quality using Octoprint over USB connection

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

droftarts

Not sure where the settings are in Octoprint GUI, but there are a number of options about 'ok' in the config.yaml. See https://docs.octoprint.org/en/master/configuration/config_yaml.html#serial and find everything with 'ok'. Not sure exactly which setting does it. I don't have an Octoprint instance to check either; haven't used it for quite a few years!

Historic perspective: The original RepRapFirmware had a bug on USB comms, so printing over USB from Pronterface was really poor. It's one of the first things dc42 fixed; see this post from 2014! https://reprap.org/forum/read.php?340,293031

Ian

nophead

@wesc Yes I think that would do it because if you had an extrusion say from A to B to C and it missed out B it would do an A C line with and E value appropriate to B C. If kiss is breaking straight lines into short segments then missing some of those out would lead to under extrusion.

So I don't think we blame this on OctoPrint being slow because of OK replies.