@gloomyandy yeah, I should have been more clear, all of the messages above were for trying to get the 2209's to work in uart mode.

@jay_s_uk said in Accidentally bought tmc2130:

That's why we have this note. I should probably update it anyway to lump 2240s in with 5160s and mention it only applies to stepsticks

I was referring to the last part that mentiones the mixing of EZ drivers.

@droftarts, I am waiting for your response.

Please check my config.g file:

M558 K0 P11 C"100.i2c.ldc1612" F36000 T36000 ; configure SZP as probe 1, type 11, on CAN address 120 M308 A"SZP coil" S10 Y"thermistor" P"100.temp0" ; thermistor on SZP coil G31 P500 K0 Z3 Y-17 H10 ; define probe 1 offsets and trigger height M558.2 K0 S23 R164530 M558.1 K0 S2

Let me know if I am doing something wrong.

At some points, I get trigger heights like 3.00, -2.55, or -2.99.

In DWC, my Z-probe value is not steady; it fluctuates between 0, 9097, and 999999.

Additionally, I am using a proximity sensor for homing the Z-axis.

provide me solution for that.

@droftarts I'm a bit confused about the concept behind that offset to be honest. My tools get picked up and dropped off correctly as long as I have no offset configured.
It turns into a nightmare if I have offsets configured for obvious reasons.
So I tend to change the offset now in the tpost file and turn it back to X0 Y0 in the tfree file but that seams to me like a ugly hack. It would be far more convenient if the offset would be removed automatically removed when the tfree gets executed.

Cheers, Chriss

@mikeabuilder macros run automatically by RRF don't have workplace coordinate offsets or coordinate rotation arrived. Macros invoked by M98 do have them applied regardless of where on the SD card they live, unless the M98 call is from a macro that itself doesn't have offsets and rotations applied.

@droftarts Thanks, I'll wait then.

@mitch Lots of places to shift electronics (ebay, craigslist, offerup marketplace), I'm in agreement about saving it from a landfill. But seems really disrespectful to come here to do it. Just my 2c.

@dwuk Made some good progress today on a basic gcode post processor to segment prints into the 4 sections that are going to be required for parallel printing.

The challenges were
a) Extruded Lines going out or coming in to segment
b) Extruded Lines passing both in and out of the segment
c). G2/G3 Arcs

Took sliced gcode file of this
Screenshot 2024-12-20 at 15.07.04.png

And sliced out just one section
Screenshot 2024-12-20 at 15.06.25.png

Another example for a more complex model
Screenshot 2024-12-20 at 15.11.41.png

Screenshot 2024-12-20 at 15.12.33.png

Screenshot 2024-12-20 at 15.13.20.png

Screenshot 2024-12-20 at 15.13.30.png

Remaining challenges before moving on to slicing the whole 4 sections and reording the gcode within each layer to do 2 of each of the sections in parallel on the front and rear gantry extruders.

Performance is fairly slow due to the low tech approach I have taken to arcs - which is to segment them into tiny line sections and treat them the same as lines - as the maths for splitting circles into up to 4 smaller sections where they intersect the border of each section got too difficult.

Another issue is travel moves around the cut off borders - the issue is fairly clear in this screenshot. - This will be a particular issue when printing sections that ajoin a layer on a section that has already been printed.

Screenshot 2024-12-20 at 15.22.44.png

Will be interest to see how these segmented files actually print - should be able to run some real tests on a single extruder printer.

The approach I now think I will take with the final output is as follows:

Go through the Gcode file expanding out G2/G3 to G1s.

Go through the expanded file 4 times - creating versions of each of the 4 segments - and collecting statistics per layer per segment.
NB/ Segment precise bounds can vary a bit per layer for strength and in later versions to better spread the load - they just need to be wide enough to avoid gantry clashes.

Final iteration - with output gcode file is generated - which will consist of GCODE, separated by laters - with each layer being either:

a). The gcode of the whole layer unsegmented - for layers with more than 2 colours per segment or not enough time needed in each segment to warrant parallel printing.

b) Segmented - with the following structure:
M596 P01
--Seg3 gcode
M596 P00
--Seg1 gcode - which can be printed in parallel to seg3
M598 - to wait for Seg3 and Seg1 to complete
M596 P01
--Seg4 gcode
M596 P00
--Seg2 gcode for printing in parallel to seg4
M598 - to wait for Seg4 and Seg2 to complete

@T3P3Tony

I will be able to check that in January, once I'm back from holidays

@droftarts

Same, will test it out in January once I'm back. The wiring I've done per the guide you've shown. I had missed the driver enable polarity jumper, so that's quite likely the issue there.

With re-sending the commands we were able to get the printer up and running, and the printer has completed a successful print, though hopefully we won't need to use the driver_enable.g file I used before with the fixes recommended.

Thanks both for the help, I'll enjoy the Christmas break for now and get back to it in Jan

@droftarts thanks for replying.
This model you mentioned, from aliexpress, theoretically doesn't need any changes to the wiring, right?

@martinv what is the chamber heater controller actually controlling? How many heaters, fans, temperature sensors etc?

@RodrigoRMaraujo said in Duet maestro - Diag led does not turn off:

I've been buying Duets on AliExpress since 2019

Just curious, since you’ve benefited so much from their work without buying genuine hardware, have you offered to contribute to the Duet development team?

@Aurimas Do you have a daemon.g file in /sys?
I think the logging (M111) should show the Gcode sent if you turn it on, which might give a clue where it's coming from. Send M111 P3 S1 and connect a serial monitor (eg YAT) via USB.

Ian

@droftarts

My mistake... I'm sorry for mixing up the firmware numbers. I thought I had the latest firmware on both boards but I don't. I updated the firmware on the 6HC and it's now working.

Thanks so much for your help!

@Arminas said in PT1000 thermistor configuration:

erature is stable all the time, expect at a

you probably have season changes and thus your PID tuning is out the window.
rerun the tune and you will probably find that it works fine now

@LindsayC which firmware version? SBC or standalone mode?

@Carter3DP you will need to reverse the direction of the homing moves for the proximal and distal motors, and switch the proximal and distal homing switches over from low to high end or vice versa.

@Paski to confirm for anyone else reading this following our email exchange:

That backlash is too high for successful calibration where the encoder is being used for motor commutation. There is inevitably backlash in a system where there is a coupler and then a leadscrew between the motor and the encoder. Using an encoder on the motor is effectively required for a well behaved system, adding a second encoder on the axis for position loop closing is supported but that can't be the only encoder.

Also, depending on axis length, and the position of the 1HCL, the SPI cable may be too long to be reliable, although thats not the specific issue in this case