What have the RaspberryPis ever done for us?

DocTrucker

Evening all. My Duet3 & Raspberry Pi build is finally coming along and I've a chance of getting things moving before the next kit of parts arrive for the next paying job that'll halt progress again!

For me this is a build it and they will come! I've not added the companion computer because I needed it, but because I wanted it there to play with! I'm keen to hear about the various use cases for companion computers aside from website is quicker, downloads are quicker, and there are more options on the touchscreen.

What have been your favorite use cases withing relatively convensional hardware topology?

The printer is solid and a reasonable size (300mm side cube volume), enclosed, and has a small USB camera looking down from one of the top corners. The standard steppers won't set the world alight but I'm keen to get the machine running reusing much of the original machine before I start trying to fix things that I've not even deemed broke yet. So far the list of swapped out kit is extensive with the following parts having been stripped (or due to be) out: screen, controller, stepper controllers, and hot ends.

DocTrucker

No Aqueduct or Sanitation?

o_lampe

My impression about SBCs and Duets always was: They have to implement it, because Klipper does.
I see an ongoing technology/feature race between the two.

Maybe one day RRF can outsource the various kinematics and path planning to the SBC and Duet-boards only act as a buffered receiver. (Like some laser controllers)
Except probes, endstops and thermistors, everything else can be done via SBC, I guess.

dc42

@o_lampe not so. We implemented SBC mode to allow users and OEMs to implement features such as custom user interfaces and data collection, cameras etc. and so that we could implement add-ons that can't be implemented solely in the browser. We deliberately didn't put any of the real time or semi-real-time code on the SBC because we wanted to keep most of the SBC processing power available for those jobs, so that users and OEMs don't have to worry about the SBC running out of processing power for running the printer.

So far we haven't found the processing power of the Duet to be a bottleneck, although it's becoming marginal on boards that don't have FPU hardware (e.g. the Duet Maestro). When there are lots of axes to be moved, our CAN-FD bus expansion board architecture means that you automatically add processing power to the system to handle these additional axes.

DocTrucker

@o_lampe the laser controller reference is interesting. What you descrube does sound like the cambridge technologies driver, and indeed a PCI controller that worked with SCAPs but I've forgotton the name of.

Which bit of the documentation gives a good intro to what is possible with the SBC and some coding?

DocTrucker

@dc42 your post hadn't updated on my screen when I posted for some reason apollogies.

Would anything custom run in place of the Duet software om the pi, or along side it? What's the best reads in the documentation to learn about the intended achitecture for custom software?

droftarts

@DocTrucker See https://docs.duet3d.com/User_manual/Machine_configuration/DSF and https://docs.duet3d.com/User_manual/Reference/APIs

Ian

o_lampe

@dc42 Sorry for my polemic thesis about Klipper.
At least it started a discussion about the real benefits of SBC use. So far it's not convincing me, but I'm a Linux-hater

Frankly speaking, there is another good reason for Duet3d, not to follow the outsourcing route I proposed and that's in the sales department.
Because of the open-source approach, Duet3D has to constantly invent new hardware to stay ahead of the cloners (or go the proprietary way)

As a long time Duet2 fan, I don't like to see the growing technology gap and I don't like to buy new hardware. The outsourcing route would definitely help to reduce the gap.

achrn

I'm not sure it's 'favourite' use case, but what I've done with the Pi on my delta is that it controls a weighing filament holder - https://forum.duet3d.com/topic/25419/another-weighing-filament-holder and it controls a string of RGB leds for status updates - https://forum.duet3d.com/topic/25575/a-delta-with-colourful-lights.

Neither are functionally essential, both are a quite handy - a progress bar I can see from across the room doesn't actually enhance my 3D printing, but I do look at it.

I also observe that both things can be done without a Pi specifically, but using other external processors. My sand table (early prototype at https://forum.duet3d.com/topic/30304/sbc-mode-on-non-pi-s/8) has 120 RGBW LEDs. Despite that post saying I'm going to add a Pi, I never have. In this case there's no Pi, but there is a Teensy 4.0 (arduino on steroids) communicating with the duet via. serial to read the object model and react accordingly. The Teensy can periodically do M409 K"move.axes[].machinePosition" and change what it is doing according to where the printhead is (for example).

RRF can do basic NeoPixels etc. control directly, but that Teensy is probably up for about 800 LEDs (100 LEDs in each of 8 parallel strings) at 200 fps frame rate if it's minding its own business and not dealing with serial comms to the Duet. (In my testing if it's just regurgitating a precalculated pattern it can run the 120 LEDs I have at about 370fps, if it calculates new values for a third of the LEDs each frame for a fade effect for example it drops to about 300fps.)

DocTrucker

@achrn it's a fair point. Any sort of user extras that get a bit too complex for conditional gcode maybe well served by plugins built to run on the Pi. I would have thought it was also less risky as you stand less chance of knackering safety critical stuff - unless of course you send the gcode to do so in error.

Has the duet firmware got to the stage where safety critical gcode instructions are locked mid process? Eg changing temp limits, PID settings etc?