Posts made by sebkritikel

@fcwilt https://www.filastruder.com/
Great vendor!

Getting closer with the adapter board:

One Item I've just started to look into, but haven't yet worked out is enabling the PDB without the SBC attached. @AJ-Quick unsure if you ran into any issues disconnecting the SBC power cable (4-pin Molex 8981 connector) - initially on power up all power LED status lights are on, and the 5V/12V power supply is outputting voltage. After a few seconds, the 5V/12V power supply cycles between on and off. I wonder if the 5V/12V power supply has some sort of minimum load?

I believe I've got the correct set of pins on the PDB getting power, simply having only the power connector connected to the SBC (no hard drive I/O or power, no display) allows it to power on correctly.

Video of issue: https://www.youtube.com/watch?v=GKUwO8F4w1w

Edit: SBC draws 2A on the 5V side. Thats a start.

@AJ-Quick Once again, my sincerest thanks for your previous work!

Once the interface board is in a useable state, I would be happy to send you one!

To your point on the motors, that is the only part of the Duet that’s likely used to its potential, as for the most part we’re just using RRF and the board to control I/O, as the PDB does all the heavy lifting for things like heaters and whatnot. The 6x stepper drivers on the Duet are overkill (we only use three of them, and off the top of my head the motors are rated at 2A, 2.8A, and 2.8A for X, Y, and Z), and we’re running the board off half its rated voltage. The Geckodrive is also overrated for the application, it could be used for much larger motors, but instead we’re using it simply for control signals.

A custom board (or possibly even an appropriate evaluation kit) could possibly be enough to support all the needed I/O channels. Of course then you’d have to solve the motor control issue, though perhaps that results in using a Duet 3HC via CAN-FD.

Not a problem I’m prepared to solve, happy enough to use the 6HC!

First of all, major thanks to @AJ-Quick, @drphil3d, @Archeantus and @Pete_A for their previous posts regarding converting the Stratasys Dimension, Fortus (250), and uPrint models over to the Duet ecosystem, as I doubt I would have been able to get as far as I have without their previous research, experimentation, and engineering. A great thread here, resulting in this awesome Hackaday post detailing @Archeantus 's fully reversible conversion.

My twist on this was to instead of using the Duet 2 product line, attempt the conversion with a Duet 3 6HC and Sammy-C21.

The fully reversible approach is quite great because it's likely the easiest way to convert one of these machines, as the existing motion, sensing, and extruding hardware is solid. Other approaches, in my opinion, are implemented by swapping in substandard hardware, and at greater time & expense.

Ultimate goal is to have an adapter board that would simplify the conversion process (notional setup below); now that the motors and the bulk of the inputs/outputs can be managed, I think I can move on to refining the board.

For now though, the electronics enclosure is very much a living, breathing organism

What is the current status?
Able to move the motors, home the axes, power on the heaters, and print!

What are the next major next steps?
Tool change, probe, nozzle cleaning macros need to be fully fleshed out. Would like to integrate the 9x limit/position switches into the configuration as best I can (X, Y, Z home, X, Y, Z end of travel, Z probe, Model toggle, Support Toggle)

What won't I be tackling in this project:

• Will not attempt to integrate the existing front user interface/screen. Instead, I'll likely pull that module out, and install a PI and touchscreen (do not intend to run the Duet with the SBC attached however)

What I haven't yet tested:

• Anything with the material bay. The user who posted the Hackaday project did some initial integration efforts, once I'm confident with the bulk of the printing portion of the printer, I'll look into the material bay control (less to use the material spools, but more to help loading in filament).
• Have not tested thermostat outputs as inputs on the Duet, but that should be low effort.

Something that surprised you?
I had previously experimented with driving the Geckodrive G320X with a Duet 2/ Duex, but I was genuinely surprised I was immediately able to get it moving as required with the Sammy-C21 STEP/DIR pins- was expecting to have to do a lot more fiddling!

Motor Control:

• Bypass the Stratasys PDB for the X, Y, and Z motors, instead wire directly to them from the 6HC
• Use the Sammy-C21 (default firmware build) to interface with a Geckodrive G320x via STEP/DIR. The Geckodrive interfaces with the PDB to control the DC motor for the extruder (the G320x actually doesn't directly connect to the motor armatures, rather it goes through to a L298P full bridge driver. In this application, the G320X is mainly used just to gain closed loop control of the motor).
• Instead of a Sammy-C21, a Duet 1XD could most likely be used.

Temperature Sensing:
There are three temperature sensors to interface with, all three are K-Type thermocouples. While the chamber thermocouple terminates inside the electronics enclosure, the two hotend thermocouples are terminated and processed in the print head. From the PDB the processed analog voltage spans from 0v (low temp) to 5v (high temp). To be read by the Duet temperature inputs, the analog voltages go through voltage dividers to get down to scale from 0v to 3.3v.

I validated the temperature range by soldering a few wires onto the existing Stratasys Control board, and running a print (with the original control board, SBC, etc), logging the values via a Labjack T7 DAQ. At the same time, I fed the analog voltages to the Duet, finding that ~1v was applies to the sensor inputs, biasing the temperature high. Once I made that discovery it was pretty straightforward to correct my M308 B and C values.

Limit Switches (Optical Switches):
I fed the limit switch outputs directly from the PDB to the 6HC inputs (5v signal, 6HC's inputs are 30v tolerant).

Enabling Head Blower Fan, LED Lights, etc:
A few ways of doing this - ultimately you need to send 5v to the PDB. To use the I/O headers, I used SN74AHCT125N level shifters to take 3v to 5v.

To use the low current outputs, this works well:

Plenty more to work on, but for now, proof of life:
https://www.youtube.com/watch?v=rRLwZSXlzxI

@DIY-O-Sphere said in Question about Sammy-C21 board:

As far as i can see, standard io's can do the job.
What am I missing here?

Can at least answer this! As an example, some folks have modified the source to allow the Sammy-C21 to drive 2x external drivers. The 'example' source (or standard release) is set up to only drive a single external driver. For the 2x external driver version, this has been used by some as part of the ERCF multi-filament system, as seen here: https://forum.duet3d.com/topic/27573/canned-ercf-board-v1-0-beta2/24

@DIY-O-Sphere said in Question about Sammy-C21 board:

@fcwilt
It means that the effort is quite high.
It's a poor performance that the latest firmware is no longer provided.
Until now I thought the Sammy-C21 is a cool option, but not any more....

You must be mistaken, the latest compiled firmware for the Sammy-C21 is 100% up to date with 3.6.0 Beta 3 here: https://github.com/Duet3D/RepRapFirmware/releases , and you can see the 3.6-dev branch here: https://github.com/Duet3D/Duet3Expansion/tree/3.6-dev

I've recently worked on a Sammy-C21 project and the firmware is up to date and available.

@fcwilt FYI, depending on your needs, the compiled 'standard' Sammy firmware is located in the RRF releases page - you might not need to compile your own version!

https://github.com/Duet3D/RepRapFirmware/releases

@SanderLPFRG Cura will inject temperature commands in such a way to ensure the next extruder is (nearly) at the printing temperature when called via the Tx command. This behavior can be further tuned via the 'Machine Settings' plugin, which allows you to specify the 'heat up' and 'cool down' rates of your tool. Also has a nice setting to configure the minimum stand by time (at print temperature).

@Solv777 To activate all four extruders and nozzles at once, in your config.g you would define a tool using M563 that uses the applicable extruders, heaters, fans, etc. https://docs.duet3d.com/User_manual/Reference/Gcodes/M563

You could then use pretty much any slicer I believe, so long as it supports tools other than 'T0'. I use Cura, which in my experience has great support for printers with multiple tools (I use it with my IDEX printer). In the Cura printer settings you would tell it how many tools your printer has, and then when you want to slice a given model, you activate the tool(s) you would like to use.

@RockB For the US Digikey and Mouser are great options (there are more!)
https://www.digikey.com/en/products/detail/molex/0436450308/4247419
https://www.mouser.com/ProductDetail/Molex/43645-0308?qs=1uvhzzitxfhjsp6NZN%252BXjw%3D%3D

@SanderLPFRG You could try keeping the G91 + G1 Z1 in your tree, but then in tpost you could set up a restore point move?

https://docs.duet3d.com/User_manual/Reference/Gcodes#g1-controlled-linear-move

Example - G1 R2 Zxxx , with xxx being your Z-hop height, and then follow that with G1 R2 Z0. Likely would want both lines at the end of your tpost. This would restore the print head to the position stored before the tool change, but offset by Zxxx. Then it would restore down to an offset of Z0 from the restore point (thus completing the Z-hop).

@oliof Not sure I follow - the 1HCL is compatible with quadrature encoders like whats used by the OP.

@BenzinLord3 , read through on connecting quadrature encoders to the 1HCL here: https://docs.duet3d.com/Duet3D_hardware/Duet_3_family/Duet_3_Expansion_1HCL

You'll essentially connect the motor/encoders 5V, GND, A+, and B+ to the 1HCL 'Quadrature Input' +5V, GND, A_INPUT, and B_INPUT. The motor leads would then connect to the 'DRIVER 0' connection.

@SanderLPFRG said in On-device start gcode handling:

@jay_s_uk I have, but I do not see any issues. I have not used G, M, N, or T and I do not see a max specified

what do you mean exactly?

The section he quoted below regarding not using ‘P’

@achrn In the example you cite, best practice IMO would be to actually use an inline connector. You don't really want a soldered joint in a flexible connection (joint becomes brittle), and a nice connector at the end of pigtail means easy swapping of components (upgrades? replacing a bad motor?).

For chassis wiring, soldering would work well - the solder sleeves mentioned above are pretty awesome. https://www.newark.com/c/cable-wire-cable-assemblies/cable-management/sleeving-tubing/solder-sleeves

@DuetUser Using one of the Duet closed loop products is without a doubt superior to using an external driver/motor combo.

1. Simple hardware and firmware setup
2. Integrated closed loop tuning & control
3. Better handling of error states

There is a third (and even a fourth option) you don't mention, and that is using the 1HCL expansion board instead of the 23CL steppers. This allows you to pick nearly any stepper you need, combine it with a quadrature encoder, and get running almost as easily as using the 23CL. The fourth option would be to also use a 1HCL, but in conjunction with the Duet Magnetic encoder. Depending on the motor you select, you may need to engineer a mounting interface for the magnetic encoder, but that should be fairly trivial.

If the 23CL motors don't quite get you the motor specs you need, I definitely recommend option three or four. Going the native closed loop direction and tuning directly in RRF/DWC is the way to go. https://docs.duet3d.com/User_manual/Tuning/Duet_3_1HCL_tuning

@Jered No problem! You could likely use the same technique, combined with the bed scanner, to get an even quicker read of just the print area before each print.

@Jered said in Creating height maps only where the part is being built:

Interesting post, but not automated enough to matter for me. I think I will look into the scanning probes as they don't require a lot of time to use. My printer is a 500mm ratrig, so it is large and requires about 25min to probe

@Jered said in Creating height maps only where the part is being built:

. I was kind of hoping that, as a temporary fix, I could automatically have the area where the part is printed to be probed, but it looks like I would have to program this for every part made.

Not sure I follow, as the link @Phaedrux posted shares several (IIRC) entirely automated solutions. Typically you add a line or two to your slicer (PrusaSlicer, Cura, etc) start code, which will automatically pass the X/Y Min/Max values to either M557. Following that the start gcode would then call for that area to be probed and used as the height map. Linked thread goes into some elegant start scripts that use mesh.g, but some simpler methods below.

Not sure what it looks like for PrusaSlicer, but I think something like this in your start code would work:

M557 X{first_layer_print_min[0]}:{first_layer_print_max[0]} Y{first_layer_print_min[1]}:{first_layer_print_max[1]} 
G29 S0

In Cura, I have added a MeshPrintSize post-processing plugin (to handle the replacement of the min/max placeholders), and then have added the following to my start gcode:

M557 X%MINX%:%MAXX% Y%MINY%:%MAXY% P3:3
G29 S0

I'd recommend taking a closer look at the linked thread, you should find a nice automatic implementation that will work for you.

@travasky I'd recommend taking a look through this thread: https://forum.duet3d.com/topic/12647/another-stratasys-uprint-retrofit/41
And the associated Hackaday project (under files there is a wiring diagram): https://hackaday.io/project/186419-dueprint

While this retrofit replaces the Stratasys SBC and control board with a Duet 2 + Duex, it retains the Stratasys PDB. For the most part the Duet and Duex interface with the PDB, so you don't have to worry about the specifics of the existing components when connecting the Duet boards.

I have a BST1200, and a near term goal is to perform a similar retrofit but with the Duet 3 ecosystem (in my case, other projects keep getting in the way!). One issue I believe, and this is just from counting up I/O from the wiring diagram), is the Duet 3 6HC is one I/O short to be a direct swap for the Duet2+Duex. It may be possible to reassign/repurpose a heater channel or 5V PWM output to fill this gap, but I haven't looked into too much detail yet.

If you read through the project linked above, they drive the extruder DC motor via a Geckodrive G320x - but this actually then goes to the PDB's L298P full bridge. To do a similar setup with the Duet3 system, you'd likely need to go 6HC->1XD->G320x, so with the 1XD you could likely make up that previously mentioned I/O gap. I'm looking at alternative ways of driving the DC motor (Which I highly recommend keeping in the system), but I'm also not there yet

Duet2/Duex wiring

@Proschi78 To summarize my line of thinking - I've seen other users have this issue, and often in the print files what happens is the new tool is called, but no Z position is specified in the successive moves, until the next layer or next tool change. With no restore point callout in the tool change files, you end up maintaining that 3mm safety move from your tfree file. The "G1 R2 Z0" solves this by restoring to the Z position stored from the start of the tool change.

I just opened your print files, and am a tad bit confused as (at least in the first layer) it appears as both Ideamaker and S3D are handling it correctly. At least in the files your provided, both Ideamaker and S3D provide a Z height a few lines after the tool change, this should move the tool to the correct printing height.

Ideamaker:

S3D

@Proschi78 Awesome! Let me know if anything else crops up.