Posts made by sebkritikel

@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.

@Proschi78 Can you post an example print file for both slicers?

I'm thinking you may need to restore the Z position after each tool change. See the notes for "G1" on the "R" parameter https://docs.duet3d.com/User_manual/Reference/Gcodes#g1-controlled-linear-move

Also, though you shouldn't need to call it out, read through "R2" for G60 https://docs.duet3d.com/User_manual/Reference/Gcodes#g60-save-current-position-to-slot These details are also described in the tool change section of the Gcode dictionary https://docs.duet3d.com/User_manual/Reference/Gcodes#t-select-tool

If another tool is already selected, the current coordinates are saved to memory slot 2 automatically (see G60), run macro tfree#.g where # is the number of that tool.

The fix for you would likely to to include G1 R2 Z0 in your t*post files. This will restore the Z position to the location from stored position slot "2" (R2), which is created when your tool change process starts.

@droftarts said in How to set M425 backlash compensation?:

@sebkritikel said in How to set Blacklash ?:

I don't see it listed in the RRF change log

Here, under new features: https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-350beta2

it is there! I must have fat fingered my search!

@JayT said in How to set M425 backlash compensation?:

@sebkritikel : I have gone through the suggestions and will try that print for backlash.

One more question:
-e) Can steps/mm be also updated in addition to setting backlash.
I understand on direction change backlash will act to include few pulses to compensate for loss of move. However, steps/mm will also add up some pulse to stepper, to print the exact dimension.
The reason I ask is, the diameter of circle I print now has variance in diameter, when measured in Y direction as compared to Xdirection. & variance is 300-350um. So diameter in vertical direction is say 60mm then in X direction is say 59.7mm . Is this variance acceptable in fdm printing?

So should I measure steps/mm & set them ?

Tough one. I would firstly recommending printing that cali-‘flower’ I shared via the YouTube link, as it has 8+ measurement points and an associated spreadsheet that reports back various calibration values. I think it’s a really great baselining tool.

Changing the steps/mm could be of use, but I think it’s important to validate if the steps/mm truly needs to be changed, or if you have some other motion system issue. Is it always 300-350um on a print if any size, or is it always a % of the length? Questions that calibration video I linked can help you answer.

@JayT Great questions! Going to tag @dc42 as backlash compensation is a newer feature (and I don't see it listed in the RRF change log!).

I have used a dial gauge and measured the backlash on my Y-axis, and measure about .15mm. With only a small amount of testing, it seems as if the compensation works well.

Intuitively I could see how a smaller value of "S" would improve more print segments, as 10*backlash=a fairly large value (relative to things like small diameter circles).

A) I would not use a 'calibration' cube to calibrate things like backlash or print size/scaling. I would only use a calibration cube as a quick check to ensure the printer is functioning at its lowest level (able to move, extrude, be at roughly the correct size, right height off build plate, etc). For true printer calibration, I highly recommend this video: https://www.youtube.com/watch?v=H7OsnMLDIMw I also highly recommend purchasing the model/spreadsheet, as it is really well done, and offers insight into extrusion, print shrinkage, and axis skew.

As part of that, I wonder if printing the model without backlash compensation, and then with backlash compensation, as merits. Something I could certainly test. As far as other methods of measuring backlash (you're using a dial gauge, which when used properly is probably the best method), here is an example on how an older professional style printer measured Y-axis backlash - a series of zig-zags, where the user inspects the print picking the most evenly spaced lines.

Something like this could work well:
https://www.thingiverse.com/thing:3060573

C) Axes having uncorrected backlash of differing amounts will definitely produce print defects. I can't imagine correcting them will induce more/different defects, however since this is a newer (and somewhat unpublished feature) reporting testing and validation to the forums will be of value to the RRF dev team.

D) I think the recommended value of "S" is going to vary greatly printer to printer. I could see on other printers (say a printer with some sort of rack and pinion) with a much greater backlash value might need an "S" value closer to 10 (As the amount of backlash needed to be compensated for could cause motor issues on shorter segments), but I think on my printer (Y-axis with some belted gearing down) the .15mm could likely be taken up easily with very small values of "S". It would be interesting to test this by running something like a 'ringing tower' or some other test print, changing the "S" parameter with height (decreasing "S" as the height increases), and noting if there are any visible differences.

Not helpful for your case - and while it was RepRapFirmware, it wasn't Duet hardware (was a Troodon 2 for work), I could not for the life of me get the printer to connect to a WiFi network. Would have to check the specific router/switch, but it was a newer dual band Netgear device. I set the printer up in access point mode, and haven't had an issue since.

I tried everything I could think of on the Netgear switch - simple access point name and password, disabled all security, disabled the 5ghz band, yet still no luck. Would be interesting to give it another shot at some point.

@donvukovic Hi Don,

Yes, the Duet 3 6XD is an active/available product. Here are a few North American vendors:
https://www.filastruder.com/collections/electronics/products/duet-3-mainboard-6xd-no-stepper-drivers
https://hartsmartproducts.com/products/duet-3-mainboard-6xd
https://www.matterhackers.com/store/l/duet3d-duet-3-6xd-3d-printer-controller-board/sk/MC5N34W5

@JayT I would recommend keeping the 'S' factor at 10 (default value for now). but doing some testing at different values. Note the comment on possible skipped steps with too low of a value of 'S' (you will need to determine what too low is for your use case). Your M425 command would thus look like M425 X0.18 Y0.18 S10

From the Gcode docs... "The additional steps are inserted over a distance of at least the distance multiplier times the amount of backlash". In your case, .18mm * 10 = backlash of .18mm is taken up over 1.8mm. If your 'S' value was say, 5mm then .18mm * 5 = .18mm of backlash taken up over .9mm.

@selva_tvi ahhhh I'll need to think on this. On closer inspection of the Gcode file, your machine follows this logic

• T0 prints at Z=0.2

• T1 is called, tfree0.g is run
  Per tfree0.g, you move Z: G1 Z3 F500 ; up 3mm
  T1 nozzle moves to the next printing location: G1 X270.6 Y259.2 F4800

What this means is Z is still equal to Z3, and doesn't go to the proper location until the start of 2, when G1 Z0.4 F1000 moves the T1 nozzle back to the correct height.

I use Cura for my IDEX machine, and on the move following a tool change Cura re-writes the current Z position, so I don't see this issue (I have my tfree set up in a similar way as you, where I move the print head in it). What we should be doing (I think) is using the G1 command with a R2 and Z0 in your tpost0.g and tpost1.g
https://docs.duet3d.com/User_manual/Reference/Gcodes#g1-controlled-linear-move
Example: G1 R2 Z0. This will move the tool head back to the printing Z height.