After a few months playing with the Duet3 and SBC combination, I've decided to revert the duet3 back to standalone. The decision was made last night when my Raspberry Pi4 locked up. (It might have been a kernel panic. I don't know. The Pi was completely unresponsive until I disconnected power and reconnected to let it reboot.) This happened mid-print.

In the course of the last few months, I found that using the duet3 in SBC mode isn't limiting as I expected. While RRF 3.2.2 is slightly ahead of DSF in development, everything I needed worked properly or could be made to work with slight changes. Specifically, the PanelDue works fine when the Duet is in SBC mode, and any conditional g-code parsing issues I had with DSF were easily worked around. In other words, I found running with DSF to be stable and working.

However, there's no getting around the fact that the SBC is a multi-faceted additional point of failure. Not only can the Pi hardware can fail, but there's also the SPI ribbon cable, the additional power supply for the Pi, the OS running on the Pi, and the DSF software suite (This is in addition to all the things that can fail on a standalone Duet3 installation.)

At the current time, and for my particular installation, the only added value that the SBC offered to me was faster gcode upload speeds and an ethernet bridge. It also offered the ability to tinker that I never got around to taking advantage of. Even if I used a small touch screen with DWC on the SBC, I still think things would be more stable with the duet3 in standalone and the Pi running independently.

Perhaps one day RRF/DSFwill offer some advantage over standalone that will cause me to re-evaluate.

PLEASE get rid of this horrible "feature" in DWC2 that "helpfully" pops up a list of previously typed console commands every time I try to type a command. At least on a macbook running chrome, it takes over the focus of the keyboard and when I think I'm hitting ENTER on my newly entered command, I instead find that instead I sent "M1" or something else destructive.

I'm using the console. I'm using a duet board. I'm not an idiot. I don't need nor want some "helpful" crud messing me up while I'm trying to watch the printer and type commands.

If nothing else, please provide a switch to disable that mess.

@chrishamm

Many of us are (still) using Duet 2 boards and RRF2. We've been warned away from having too much interest in RRF3 "until it becomes stable."

Now that it's stable, and this being the official announcement thread, can you please provide a quick statement describing "What's New in RRF3 for Duet2 users"?

Perhaps a subtitle of "Reasons why upgrading might be worthwhile."

Thank you
Gary

In all fairness to @gnydick, things with RRF2 have kind of been dropped for a significant amount of time (relative to timelines in years past) in order to progress with RRF3 and Duet3.

For example, there's a known delta calibration bug in the last "released" version of RRF2 (2.03.) That bug was fixed within a month in an RC (2.04RC1) 3 months ago. Since then, there's been no visible activity for RRF2. The RC bug fix hasn't been released as 2.04, and there's been no other RC or beta.

Another example is DWC2. Until just a couple days ago, I thought development on it had completely stopped while it was in RC status. It seems it's finally been released outside of RC, but it feels like the changes between the last RC and now only are for RRF3. There are still outstanding bugs with it that are unfixed. (I'd really like to download a gcode file without having to wait 2-3 minutes before the download starts.)

All that being said, however, please keep in mind that RRF (and DWC) isn't a paid product. It's free and open source. The only thing being paid for is the hardware. Anyone is free to grab the source and fix bugs on their own. David doesn't get paid by us for firmware updates, and the fact that he keeps providing them for free is, to be honest, amazing. If he wants to use his time to work on RRF3 or just to play tiddlywinks - its his time - not mine (or yours.)

Would I like to see more progress for the things I personally want? Sure. I'd also like it if the next time David is in the US, he comes over to my house, gives me a free Duet3 board, installs it in my delta, AND ports my RRF2 config over to RRF3 with the new board. (Okay, that's being greedy; I'll install the board myself if David crimps the connectors for me. )

As for being an "acceptable software development practice", you're living in the past. Modern s/w dev practice is to throw as many new features as possible at users, see what sticks, and only fix the bugs that are causing a loss of revenue. (I'm not saying it's GOOD practice, only that it's become the normal practice in recent decades.) I'm extremely grateful that David doesn't follow that pattern.

@garyd9 said in Cura, firmware retraction and M207:

The only problem here is that the duet's M207 expects the F and T parameters to be specified in mm/min while the cura values are in mm/sec. So, the above gcode actually sends something like "M207 S1.5 R0 F60 T20" instead of "M207 S1.5 R0 F3600 T1200" Obviously, retracting at 60mm/minute is a bit too slow.

Can anyone offer any suggestion on how I can get around this? I remember reading once about the ability to create custom gcode's using macros, but I can't seem to find that reference anymore to see if those macros will accept parameters, allow math to be performed on them, and then have the resulting values passed to normal gcodes.

The macro's won't accept parameters. Along with conditional g-code variables, that's on the RRF todo list.

I guess the inconsistency of M207 parameters being in mm/min, but being retained/reported in mm/sec is intentional.

In the meantime, here's what I've come up with to work around the problem. This should be put in the "start gcode" in cura's machine settings:

;Store the cura values in pseudo-variables (workspace coordinates for a workspace that is never used by me):
G10 L2 P2 X{retraction_amount} Y{retraction_speed} Z{retraction_prime_speed}
M98 P"/macros/SetM207" 

Then create a macro called "SetM207" that contains the following:

;use conditional gcode to do the math needed to translate the values into M207 acceptable parameters
M207 S{move.axes[0].workplaceOffsets[1]} R0 F{move.axes[1].workplaceOffsets[1] * 60} T{move.axes[2].workplaceOffsets[1] * 60} Z0

I originally tried to put the M207 line above into the start gcode (instead of using a macro) but doing so resulted in Cura not translating the {retraction_amount} stuff. I'm not sure why.

If needed, the "extra prime amount" could also be stored in a workspace axis offset ( G10 L2 P3 X{retraction_extra_prime_amount}) and then set by replacing "R0" in the macro above with "R{move.axes[0].workplaceOffsets[2]}

Note that I have the Z parameter to M207 set to 0 always. One thing that can't be helped with the current version of cura is z-hop. Cura doesn't seem to consider z-hop to be something firmware retraction is responsible for, so it still emits z-hop commands to the gcode even when firmware retraction is enabled. (I suppose this might be a good thing because Cura gives more control over when z-hop is used instead of just always hopping with any retraction.) Anyway, it works fine if you left cura do the hopping and the Duet to do the retracting.

@Phaedrux his teeth are on edge...

@jrsphoto First guess is that you're too far away from the build plate. If you're using a BLTouch to level, you probably need to reconfigure the trigger distance.

If using RRF3, can't you do it yourself in your bed.g using M291 and object model variables? (I don't know if the manual adjustment / screw turns info is available in the object model.)

@sirus20x6

As @Phaedrux mentioned, that pattern appears to be backlash...

To explain a bit more: If you watch the printer while it's doing the mesh thing, you'll see it moves all along the X axis (left/right) in one direction, then moves back in Y (front/back) and then all along the X axis (left/right) again (but in the opposite direction.) Compare that motion to the image you posted, and you'll notice that all the left to right motions are at one height on the image and all the right to left motions are at a different height. That suggests that the nozzle is at different height depending on the left or right motion... The cause for that in a delta is usually that something isn't moving quite correctly on one of the towers. It might be a belt, a carriage, etc.

Search this forum for "delta backlash" and you might find some useful suggestions. Here's one thread (that I have bookmarked for some reason) to get started: https://forum.duet3d.com/topic/5175/duet-level-bed-and-g29-32

@dc42 said in Why use a Raspberry Pi with a Duet 3?:

If this is important, I think the real answer is to implement a call from RRF to the Pi to get the list of files in a folder, so that RRF can implement M20. I don't think it should be hard. If M36 was implemented in the same way then it would also be possible to start print jobs from PanelDue.

I just would like to add my positive vote for this. It would give much more flexibility in setting up duet 3 boards.

While it's possible to run both HDMI and USB cables to a small screen, the simple fact is that the wiring for the PanelDue is much smaller. There's also the fact that the PanelDue UI is a mature, well designed, simple small screen touch interface that's proven.

@rjenkinsgb said in SE and "Revo" hotend?:

I believe the fan wiring is the same in the V3 as in the V2.

I'm using a v1.2, but I doubt it makes any difference.

The simplest work-around is use the regulator board & mount it at the effector.

Perhaps. The wiring for that would probably be fairly messy, but if it works, I guess that's all that matters. (I'm imagining the two fan wires coming out the underside of the SE, looping back up to a regulator board mounted on the topside of the SE, and two more wires hanging back down to the fan.)

Or, it might be easier to just design something that allows mounting a 30mm fan, even if it's at a slight angle (angled to blow slightly up.)

As for E3D possibly releasing a V6 length threaded sink: It's possible that it happens, but I'm not going to hold my breath waiting.

@dc42 said in SE and "Revo" hotend?:

@garyd9 the Revo isn't as long as the V6, so you will need to use a different print cooling fan duct and perhaps a smaller print cooling fan. Other than that, it should fit.

Digging into things, it appears there might be an incompatibility with "revo" heatsink fan and the smart effector. The revo fan is a 20mm x 10mm 5VDC fan, and the smart effector expects either 12v or 24v on that line (as it uses it to power the LEDs.)

What would happen if 5VDC was supplied to the smart effector HF+ line? I'd guess that it might cause a problem with the LED's, but would anything else bad happen?

As an alternative, E3D supplies some kind of 5V "regulator board" that I might be able to stick to the smart effector (depending on how big it is.) Or perhaps I could track down a 20mmx10mm 24VDC fan -- or print some kind of adapter to use the old 30mm 24VDC fan.

@jay_s_uk said in SE and "Revo" hotend?:

@garyd9 should do fine.
Uses an M12 thread so I don't see a reason it wouldn't

I agree, but I'm also paranoid. I can think of dozens of things that might go wrong.

That's why I was hoping that someone has direct knowledge, and now that the "revo" is out of beta testing, they'd be able to share that information.

I'm having a hard time getting clear (explicit) information, but I suspect that at least a couple people here have direct knowledge: Will the E3D "revo" micro heat sink fit properly in the Duet Smart Effector without modification?

Thanks
Gary

@phaedrux said in Duet 3 6HC Wifi?:

Something like this would make a good wifi to ethernet bridge

https://www.amazon.ca/TP-Link-TL-WR802N-Wireless-Repeater-300Mbps/dp/B00TQEX8BO/ref=sr_1_5?keywords=Wireless+Travel+Router&qid=1639430960&sr=8-5

I'd try something else. I bought that product and used it with my Duet3. However, quite frequently, the duet would act as if it had no network connectivity at all and I'd have to reboot the duet to get it to "see" the bridge again.

When I bridge with a RaspPi instead, I have no problem whatsoever.

Perhaps I just got a flaky bridge, or perhaps there's some odd interaction between that bridge and the duet board. No idea, but the problem was annoying enough that if I buy another bridge, it won't be that device.

@ibash

Is that gcode file using variable height layers?

@gurusmi said in Smart Effector V3 an plastic nut:

the adapter i talked about ist that Thing. There i printed only the adapter named Dragon_Adapter_v3.stl, It is made for the full dragon hontend and also for the BMO. You will have to take off the BMO's groove adapter. One don't need the Groove Adapter any longer with this design.

I realize that this is an older post I'm replying to. However, this is the first I'm seeing it. As the author of that thing, I'm kind of amused that you are asking any questions about nuts. When I designed the adapter, I realized that there are two different threads being used for smart effectors, and to avoid any issues, I included a .STL file of a nut that works fine. I even mention it in the instructions:

After attaching the adapter to the hotend, simply put the M12 threads of the adapter through the 12mm hole in the smart effector, and attach the printed nut.

I'd suggest scaling the nut to 100.1% if printing at the original size doesn't work. The nut should be a tight fit (to prevent it loosening) but not impossible to thread on the adapter.

I actually prefer using the plastic printed nut to using a metal one for weight savings. I also feel that I can tweak the scaling of the nut in order to make a very tight fit on the threads (which avoids any issue of the nut loosening over time.)

I am happy to see remixes of the thing that add "arms" to prevent rotation of the hotend.

@dc42 said in PanelDue Firmware 3.3.0-rc2 released:

@mfs12 it might make more sense for me to change RRF to return the remaining time calculated from simulation, then PanelDue can use that directly.

If you're going to change RRF, wouldn't it be better to add a "simulatedTimeRemaining" instead of changing the definition of something already existing?

...just wondering if there are plans on updating PanelDue for RRF 3.3. (In particular, replacing the layer-based estimates with something else.)

@tecno I'm using the actual 24V E3D heatsink fan. The genuine E3D V6 shroud will work, but it might be loose and rattle.

I modeled something that (in my opinion) holds the 30mm fan to the dragon heat sink better. It's on this thingiverse thing:
https://www.thingiverse.com/thing:4818787