Pallete 2 and Duet, DWC time estimates are off.

Danal

Summary, regarding Palette 2 Pro:

Hardware seems VERY robust.
Customer support from Mosaic is good to excellent.
Steep learning curve. REALLY pay attention to their instructions; they have a lot of really well done stuff on the web site.
Works fine with Duet in "Accessory" mode, where it generates two files, one for printer and one for Palette. Just send the printer file with DWC. (assuming I get it all calibrated and tuned up, that is)
Works fine with an Octoprint base "Hub". In this case, DWC doesn't tell you much, but Octoprint does...
I'd recommend NOT buying their "Canvas Hub" hardware, but instead "roll your own" hub on a Pi3B+ or similar

.

TBD if it is going to work well on a printer with an 1100mm Bowden.

And, I will keep you posted when I get it all working.

Danal

Update: Running on the Hub, it is seeing pings!!!! Yay!!!

They are running about 112% and should be very close to 100... the mosaic doc has a way to tune this... so MUCH PROGRESS. Yay!!

Phaedrux

Thanks for the write up. That's exactly the kind of details I'm wondering about. I almost jumped on the Palette 2 pre-order but decided to wait for the dust to settle.

I'm curious if anything could be done on either end to better integrate with the Duet.

nikker

wow what a neat piece of hardware. I am with @Phaedrux and am going to keep an eye out although i dont need 4 filaments, just 2... my main and another for support material. Either way very cool. Please keep us posted on how things work, especially integration with the Duet.

Danal

Update: The first almost successful print failed about halfway through because cura put in an M104 T1 S0 to allow Extruder 1 to cool off when the print got above the last layer that needed that extruder. Duet/RepRap sent an error because there is no Tool 1. Canvas Hub (Octoprint) saw the error and stopped the print.

There may be several ways around this. Convince Cura to not put these in the file. Have Chroma remove them. Configure the printer so that it won't error on Tool 1 being set to zero. Configure octoprint to ignore this error.

For debugging, I simply hand edited the G-Code file and removed the M104. Result: SUCCESS!!! YAY!!

.

Summary: Palette 2 Pro + Canvas Hub (built on Pi 3B+) works great with Duet controller. Be aware that you don't really use DWC when configured like this, you do your web control via Canvas Hub (which is really Octoprint with canvas and palette plug ins). I don't consider this a plus or a minus... just "the way it works".

Danal

@danal said in Pallete 2 and Duet, DWC time estimates are off.:

Update: Running on the Hub, it is seeing pings!!!! Yay!!!

They are running about 112% and should be very close to 100... the mosaic doc has a way to tune this... so MUCH PROGRESS. Yay!!

Edit: Palette 1 required you to tune pings. Palette 2 "learns". Nifty!!

Danal

@phaedrux said in Pallete 2 and Duet, DWC time estimates are off.:

I'm curious if anything could be done on either end to better integrate with the Duet.

To my very limited experience at the moment:

Fix estimation when Palette is running in Accessory mode.
Figure out how to deal with configuration for one extruder, but G-Code files that contain elements referring to more than one. In fact, the "estimation" above is really just a special case of this...

That's really it. Everything else seems to "just work".

Phaedrux

@danal said in Pallete 2 and Duet, DWC time estimates are off.:

There may be several ways around this. Convince Cura to not put these in the file. Have Chroma remove them. Configure the printer so that it won't error on Tool 1 being set to zero. Configure octoprint to ignore this error.

How did you eventually solve this one?

My wife did a ninja job on me this christmas and got me a Palette 2. So far my experience has been far from smooth. Finally managed to work out some kinks and get a successful print using Canvas (That's their cloud based slicer) which was ok, but doesn't give much fine control over print settings. So I figured I'd try setting up Slic3r PE and then use Chroma (their gcode post processor) and I ran into the same M104 T1 S0 error on color change that octoprint choked on.

Danal

My first fix was to use a text editor (sublime) to take M104 for any tool not zero out of the file.

My second fix was to find a setting in Octoprint that filters out any string match before a given line is sent to the printer. Set it to allow M104 T0 but suppress M104 Tn where n is one through nine. I'm not near enough to find the exact regex... I can post it if it is important.

Phaedrux

I managed to get past that problem.

I found that the Cura config file edit mosaic posted to remove heater changes worked. But in order for chroma to even import the gcode file I had to manually delete the very first T0 that Cura inserts before the start gcode block. I haven't tested yet but I think that first T0 is only inserted when Cura is set to reprapfirmware flavor gcode.

As long as the temps for all extruders are set the same and the gcode start block had an M109 to set the temp and prevent Cura from inserting its own there were no other m104 entries in the file and chroma seemed to process everything properly.

The only issue after that was the one I just posted about where it looks like chroma inserts a feed rate 0 move at layer change which caused very slow travel moves between purge block and print. Did you notice anything like that?