Best posts made by poofjunior

Hey folks,

At long last, Jubilee kits are now live and available through Filastruder!

If you've ever wanted to explore toolchanging with a hacker-friendly platform that's ripe with customization potential, I hope that kits make Jubilee a fair choice in the bold new frontier of toolchangers. Jubilee is especially ripe to provide you with an ecosystem for designing your own tools, complete with a parametric solution for parking tools and the specs needed to make them fit.

The kit takes everything you need to build the motion system, QCs it, and puts it into a box. That includes all the wiring (pre-crimped and labeled!), and even the assembly tools too (minus the soldering iron for inserts).

In the next couple months we'll try to do the same with tools, but for now, this dramatically streamlines the build.

Jubilee was 3.5 years of my work in grad school, and I'm thrilled that I get to share it with folks this way. Along the way, folks on Discord who built the project from source have battle-tested and improved it over the years. The Jubilee that's kitized today represents the latest-and-greatest as far as what we've learned as a community from playing with it.

Finally, Jubilee simply wouldn't exist without the ecosystem of people who keep it afloat. That's a combination of the machinists making Jubilee's more complicated parts, the printer veterans producing the printed parts, and the vendors who have adopted Jubilee parts along the way to make the project a little easier to source. This kit was a collaboration with many of them; it wouldn't make sense to do it any other way!

In part, through the serendipity of meeting Tony Lock at MRRFs and ERRFs back in 2019, Jubilees have been Duet-powered since pretty-much the start of this adventure. And with all the other things that can go wrong with toolchangers, it's nice to not have to worry about overheating motor drivers or underspec'ed connectors. Duet also made adding the toolchanging feature a breeze. (Far simpler, I admit, than when I was modifying custom firmware on other boards to make it happen.) Thanks a bunch to the crew moving the electrons in the right places at the right times!

Cheers--and happy hacking!

Project Page: jubilee3d.com
and Machine Pics for the curious!

I'm building out an automated sonication work cell for a lab at school, and I wanted to share some of the more fun bits!

For starters, I started with a Jubilee 2.1.x. The bed plate has been retrofitted for holding well plates with a laser cut fixture and some (no joke) battery clips from Digikey.

Then I added two tools: a downwards facing camera and the sonicator.

Next came the software. I couldn't drive the sonicator and camera with GCode directly, so I wrapped the HTTP interface in Python to get easier access to the custom tool commands. Since the tools don't need to be active while the machine is moving, this ends up working out.

The camera is for dialing in the location of the well plate using the centroids of the 3 corner wells. (Doing this manually for now keeps the machine flexible enough to accommodate oddly shaped custom plates.) The sonicator is for zapping samples with ultrasonic vibrations. (Apparently this breaks down cell walls and DNA and makes it easier for scientists to measure some of the more rudimentary components. Honestly, I wish I could say more here, but I just the machine designer!)

Here's the machine in all it's glory:

and... here's the dry run where the sonicator gets picked up and cycles between well plates and cleaning viles.
https://www.youtube.com/watch?v=aem-JLtchbI

I thought this'd be a fun share to showcase just how much you can do with a Duet with an extra layer of abstraction or two. In a nutshell, the Duet folks have done a fantastic job exposing interfaces to build robots of all kinds on top of their work, not just printers and cnc machines. I'll slowwly get the bed CADs on the Jubilee wiki if anyone wants to try some other sample handling mischief.

This is heartbreaking news, but thanks for sharing.

Danal and I only interacted online over the last 6 months, but he certainly left his footprints behind on my work in ways that really kept me going.

Danal was the first person I know of to build a Jubilee and join the Jubilee Discord. When I kicked the files online back in September, Danal was the first person to find bugs and improvements for the documentation. In the months that followed, Danal took Jubilee and the rest of the community with him to a whole different level of capability by writing TAMV, a machine vision add-on enabling automatic tool offset alignment using an upwards facing webcam.

But let's forget about project contributions for a second. Danal was the first one to jump onto Jubilee Discord, and his discussion points was always sincere. And he became one of the chattiest community members, answering a multitude of first-timer questions and setting the tone for a warm discussion where new folks can learn from experts in a laid back session of IRC. In the tough world of online discussion forums, some earnest, light-hearted chat is hard to come by, but Danal was the one who set the tone for that. It was incredibly refreshing to engage with Danal online. Through his sincerity and responsiveness, it was like he believed that people would put their best feet forward if you did the same first.

I will miss a ton of things about this guy. I'll miss his transparency, his willingness to solve a problem and then share a well-formed solution online in code. I'll miss his kindness, how he always tried to meet folks where they were at in answering their questions. And I'll certainly miss his excitement for this stuff. Seriously, Danal was one hell of a great human beings to have hanging around these parts of the internet with us. It's going to be tough without him, but I think it's on us to keep echoing some of his character in the stuff we do here.

Hey folks,

I would love to see input shaping implemented on the Duet. So I read-up on the math and took notes on how to do it fast on standard resource-constrained hardware. In a nutshell, I wanted to really "see" what was happening to the position signal when we apply input shaping to it.

My "crash-course" notes on the math are here:
https://github.com/Poofjunior/input_shaping_notes/blob/main/input_shaping_and_modifying_kinematics.ipynb

In short:

• Input Shaping requires running all position curves through a convolution with a special impulse sequence signal.
• The impulse sequence signal requires measuring the natural frequency for each axis. Printer owners will need to run some sort of "self-test" routine with an accelerometer to collect the machine's impulse response.
• Convolution is a pretty resource-intense operation, but since our second signal is an impulse sequence, the math simplifies dramatically and is actually pretty fast.
• Technically, we're convolving our impulse sequence with our acceleration signal, but it turns out that it's equivalent to convolve the impulse sequence with either velocity or with position, so convolve with whatever's convenient.
• because our position signal is convolved with an impulse sequence, it's impractical to solve for the inverse function (i.e: time as a function of position) analytically. But an iterative solver really shines here.

I'll bet you'll get a lot of requests for this feature in the future, so I hope this helps the folks doing firmware digest what's actually involved in coding it up!
(And if someone wants to point me to where in RRF that step times are being calculcated, I might just give this a go in a few months.)

Finally if you have any questions on the math, feel free to reach out!
Cheers!

@auser Looks like I'm getting to this one a bit late, but a kit for the frame has been in the works via Filastruder, and we're almost done aggregating everything. Our target is end of this month (Jan), which feels a bit surreal, since we've been at this for a good ten months now.

The kit should totally eliminate the need for making your own wire harnesses, come with all the assembly tools except a soldering iron for installing the heat-set inserts, and leverage a Duet3 Mini + 3HC Expansion with 2 drivers to spare for tools by default. (There's also a hole mounting pattern for 2 additional 3HC boards.)

Along the way, I totally revamped the default extruder tool to be Orbiter-based with support for the 1.5 and 2.0, and then support groovemount heatsinks, threaded heatsinks, and v6 and v7 heads, not to mention a bunch of clones. It also sports dual 5015 fans. More info on the Baby Bullet here, but the folks who've built one or modified one seem to be really happy with it.

I totally acknowledge that building Jubilee is lots of work, but hopefully this will get folks much further out faster.

Cheers--and have fun on your build--whatever platform you pick!

One of the quirks about multi-tool setups is that we can't readily add/remove standalone config.g snippets without editing the main config.

That has to do with some config-related interdependence of commands. Here's an example.

M584, which sets the drive mapping, requires that you declare all extruder drives at once like this:

M584 E3:4:1.0:1.1

Running M584 later in the config (let's say, to add a new tool), requires you to take what was already there and append to it manually like this:

M584 E3:4:1.0:1.1:1.2

This interdependence prevents you from adding config snippets to add/remove a tool without modifying the main config. The result is that you have to know in advance how many tools you have or will ever have. The other quirk here is that electronics setups may differ on multitool setups--even on machines with well-defined electronics options like Jubilee. Someone might use Duet3 with toolboards while someone else uses the 3HC's. I would love to know if there's a way to dynamically offer standalone snippets of tool-related config.g's without requiring that folks edit the main config.

So here are my questions.

1. for folks tweaking their machines often (like for multitool setups), does any sort of read-modify-write syntax exist? Something like:

curr_m584 = M584
curr_M584:1.2

2. Is there any effort to make dynamic config generation for swapping tools any simpler using resources of the optional Raspi?

Cheers--and thanks!

Duet has an awesome feature to snapshot the state of the machine, alter the machine state, and then restore it from the snapshot (M120 and M121: Push and Pop. It looks like only a subset of the machine state is captured though. Would it be possible to capture other motion-related state variables too, like those that specify acceleration values?

Here's the use case: in a multitool setup, we can use the toolchange macros to alter the tool-less machine state when a particular tool is loaded. If it's a slightly heavier tool, we could reduce the acceleration values with M201. Upon releasing that tool, the prior acceleration values would be restored.

@auser There's no EU distributer for a kit now, but folks building Jubilees in the EU usually go to HighTemp3D for parts. I'd be open to looking for more folks willing to do kits.

I totally acknowledge that shipping costs add up. Test driving a kit in the US is one way to help solve that issue, but not the last. Baby steps!

And I'll gladly post an announcement when kits go live if I'm allowed to do some self-promotion!

Thanks for the support, folks! This is a nearing-completion work-in-progress, but the plan is to make all reusable bits of this project (CAD files for the bed, python library for motion) shareable so that other folks have a starting point for similar non-printing mischief.

@T3P3Tony said:

Would be great to catch up in more detail at some point about generic plugins/libraries to streamline this for wider use cases.

Aye--that'd be great. All that feedback from other threads really helped! For now, I swapped from DSF to HTTP to be able to let the same code command Duet2 and Duet3 setups. Longer-term, I'll probably make the interface selectable in the class constructor so that folks can pick either DSF or HTTP. Currently doing a light code overhaul so that the sonicator and motion control sections of the code can exist as separate projects with the duet motion interface being pip-installable.

Thanks again for all the hard work on the Duet side, and more actions shots may follow!

Hi folks,

I'd like to write a python-based that emulates the web behavior of being able to:

• poll the state of the machine
• send over simple GCode commands or entire files.

First off, are there leads on doing this already? I'm super new to web programming, but I want to adhere to best practices for interacting with the exposed network-based API. From what I've read, I should be connecting to the Duet via websockets, not via http polling.

I started by opening up dev-tools in my browser on DWC's main page, I was able to track down the connection on this URL:

http://192.168.1.2/rr_connect?password=reprap&time=2019-10-30T17%3A29%3A0

(My Duet has a static IP for now.) It looks like a password, date, and time are encoded too.

Pasting that URL into a connection from Python's socketIO library throws a 404 with this code, though:

import socketio                                                                                                            
sio = socketio.Client()                                                                                                    
sio.connect("http://192.168.1.2/rr_connect?password=reprap&time=2019-10-30T17%3A29%3A0")

However, using vanilla HTTP Requests with Python works flawlessly:

import requests                                                                                                         
params = { "password": "reprap",
           "time": "2019-10-30T17:29:0"
         }
r = requests.get("http://192.168.1.2", params=params)  # this works!                                                                              
r = requests.get("http://192.168.1.2/rr_status?type=1")  # this also works!                                        
print(r.json()) 

What do folks recommend? I could simply setup a thread to poll the machine state and send GCode from the main thread using the Python requests library. Is there a better approach?

Thanks for taking a look and offering suggestions!

Finally, it looks like others have visited this topic before, but the conversation ended without any leads:
https://forum.duet3d.com/topic/441/web-ui-native-wrapper

I also referenced the Duet Web UI code, but I'm not a web programmer by trade.

Hmm, I suppose I'm looking for an easier way to quickly re-configure a machine. For the most part, that's a pretty rare thing to do, since most folks configure their machine once or occasionally when they upgrade/tweak hardware.

But for machines whose configurations can change frequently (tool changing machines that add/remove various tools), it would be nice to have an easier way to manipulate the machine configuration in a way that's not so highly interconnected.

I certainly can't ask the Duet project to support this kind of flexibility for hobbyists who want to switch tools on-and-off. But I do think that having a less-interconnected config.g or, higher level, an alternate api for changing machine configuration, would lower the bar for folks interested in playing with toolchanging setups. And I think that Duet supports tool-changing setups best so far.

If folks developing the Duet would be willing to consider something like configuring the machine via Object Model upload (via text file or other), I could jump on that API to build an abstraction that lets you easily add/remove tools. Otherwise, I'd probably look at using jinja templates to abstract the config-writing/editing process a bit more.

I'll keep my eyes peeled on project updates for anything that could make machine reconfiguration easier. In the meantime, thanks a bunch for chiming in!