Pallete 2 and Duet, DWC time estimates are off.
-
PROBABLY... this is related to having the physical printer configured in Duet/RepRap as single extruder, and having the Slicer (Cura) set to four extruders.
In particular, the Cura file has this statement (which appears to be unchanged by the Chroma post-processor):
;Filament used: 1.46698m, 0.79558m, 0.452586m, 0m
And the "parser" in reprap is probably only looking at the first number.
-
As an aside, I'm curious what your overall impression of using the Palette 2 with the Duet has been since it's geared towards being used with Octoprint.
-
So far, the learning curve has been very steep (for me).
This is the new "Palette 2" and I chose to purchase a "Pro" which has more metal parts internally. I'm very impressed with the hardware device. Well thought out, heavy duty (darn, it is heavy to pick up off the table), transparent covers on everything, thumbscrews to remove covers to clear jams, etc. Looks really good.
I started out with the Canvas Hub (Mosaic's own hardware with Octoprint+Plugins) and the Palette and a more-or-less stock CR10S. Mosaic chose a Pi Zero W (with an aux board to give it 4 USB ports). These are too slow. I found it VERY frustrating to have the slow "hub" while trying to figure out other things. After about 8 attempts to even get a print to start, and having the device hang, or this or that, I remove the "hub" and put the Palette 2 in "accessory" mode. I also set the CR10S aside and put the palette on my BFD (Big Fast Delta).
In accessory mode, the post-processor generates two files, one for the SD on the Palette, and one for the printer. Of course, with a Duet, the printer file is just an upload. Fairly simple.
I still had issues getting things to start. I eventually discovered that the output tube of the Palette must NOT be connected to the printer until after the palette tells you to do so (after it makes the first bits of spliced filament). Back pressure on the filament causes a hang. By the way, Mosaics instructions on this are VERY clear... nonetheless, I was "doing it backwards" and causing problems.
Now that I understand how to start a print, I've made about six attempts to print and all have failed in various ways. Jams, Tangles, Breaks, etc... Notable, NOT inside the Palette, it has been flawless at a hardware level. I just need to get the reels that feed it, and several other things, completely worked out. I have had one or two prints proceed fairly far, but the colors are nowhere near where they are supposed to be.
Palette goes through a calibration process for a new printer to figure out how far it is from the output of the palette to the nozzle on the printer. Keep in mind that my BFD has an 1100mm (yes, over one meter) Bowden. So the calibration is fairly painstaking... Then, on later prints, it "knows" this distance, but you still have to "load" the filament, and this is a little painful as well with this very long tube.
Probably should put the Palette on a direct drive printer...
Anyway, as I work out all the kinks, it is apparent the color is not "in sync". I'm trying to print this:
And all I'm getting is banding and random colors.
The Palette uses "pings" to keep in sync with the printer. These are longish retracts, with a pause. When the Palette 'sees' the retract/pause, it 'knows' EXACTLY where the G-Code is... and can therefore avoid 'cumulative error' drift between the two devices. Well, in accessory mode, with my best calibrations, it does not ever see the pings. (if they are more than +/- 10% of where they 'should' be, it won't see them).
THEREFORE, I've gone back to the 'hub', as it stays in sync a different way (since the hub is sending G-Code to the printer AND commands to the Palette, pings are not required). This time, I installed Octoprint + The mosaic plugins on a Pi 3B+ I already had. This is a great setup. High praise to Mosiac for making the plugins available so that we can build our own 'hub'.
We'll see how that print comes out.
Also, somewhere in all of the above, I've posted a few things on the Mosaic forums. They've always responded within 24 hours, and even pushed a firmware patch based on some of my feedback. Excellent support.
-
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.
-
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!!
Delta / Kossel printer fanatic
-
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.
-
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.
-
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".
Delta / Kossel printer fanatic
-
@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!!
-
@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".
-
-
@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.
-
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.
-
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?
