@droftarts I have solved the issue,

Your suggestion to switch to the lite version helped as the Raspberry Pi was then able to display the terminal on the monitor however it did not fix the networking issues. The solution was to connection to the Raspberry Pi via IP address instead of "name.local". Not sure why that's more reliable but it hasn't dropped out once since I switched over.

@o_lampe
Yes, on all sides it is the same.

Yes, it is a dual drive extruder. What can I try in this case? Change it? Change it to which one? (I will have to redesign the whole stand).

I don't see that the spring load tension of the dual drive makes any difference. I tried varying it during printing.

@Phaedrux yes

@Phaedrux

Yes, of course. Here are the files. For context, I generated this G-code based on the example provided in the accompanying image. In this setup, there are two identical parts, each printed using four different tools. One part involves support material and the actual part printed with two tools, and the second part is similarly printed but using two different tools.

I configured Simplify3D with the intention of enabling the cooling fan only for the tool responsible for printing the support material. However, upon reviewing the generated G-code, it appears that the fan behavior does not fully correspond to the intended configuration.Preview process.png config.g 3024-10-010LR_4Tools_test.gcode

Changing the shielding ground pin made zero difference. In fact, not grounding the shielding has zero affect from what I can tell. I checked all of my connections I made and everything seems good there.

Then this morning I decided to move the temp daughterboard to the duex instead of off of the duet. It appears that my open circuit is gone now but I will have to do additional testing when I get the time to do so. This is a machine I run at my 9-5 so I don't always get time to put into it depending on my workload.

Will update this thread with any additional information I get.

@ToWi1989 which way are you trying to baby step? Up or down? Also try RC2

@perfetto

Good evening, I loaded the firmware 2.05.1 if I want to hook the yellow wire of the bl touch ei =a e2 of the rf configurator I have to use the pwm v_ in pin or the +3.3 V pin.

The yellow wire is the control wire for the BLTouch. It should connect to a PWM pin, usually heater 3.

E2 in the configuration tool is heater 3. This is referred to as M307 H3 in the firmware and config.g and M280 P3 in deployprobe.g and retractprobe.g.

Your wiring should be:

Duet Z Probe connector pin Duet expansion connector pin BLTouch pin Colour IN Out White GND GND Black 5V (pin 1) +5V Red Heater3 (pin 8 ) Control Orange or Yellow GND (pin 2) GND Brown or Blue

Your configuration should be
in config.g

; Z-Probe M307 H3 A-1 C-1 D-1 ; disable heater on PWM channel for BLTouch M558 P9 H5 F120 T6000 ; set Z probe type to bltouch and the dive height + speeds G31 P500 X0 Y0 Z2.5 ; set Z probe trigger value, offset and trigger height

in deployprobe.g

M280 P3 S10 I1

In retractprobe.g file

M280 P3 S90 I1

If you are still having problems, post a picture of your wiring at the BLTouch end, and at the Duet end.

Ian

@dc42 Ok thanks - Yes my printer has separate Z adjustments for each print head - have raised enhancement request.

Referenced Multiple Motion System Mesh Adjustment and Z hopping in the same request - but could separate them out if that would be better.
https://github.com/Duet3D/RepRapFirmware/issues/1106

ukdavewood created this issue in Duet3D/RepRapFirmware open [FeatureRequest]: Multiple Motion System - Micro Z Adjustment and Z Hopping #1106

@droftarts amp coin v18 - PLA.gcode

@phoenix

That's why we are here!

If we cannot help, we can mess things up in style. 🤠

Frederick

@dc42 Again, thanks! I can confirm that this fixes my probing issue.

@CaiJonas the stuttering movements appear to be a feature of the moves generated. They are not arc moves, they are a sequence of line segments. Here's an example from line 2270 of your example file:

G1 X60.133 Y46.575 E.6074 ; perimeter G1 E-.5 F3000 ; retract G1 X60.509 Y46.911 F18000 G1 X75.371 Y60.871 ; move to first infill point G1 X75.561 Y61.029 ; move to first infill point G1 X75.728 Y61.145 ; move to first infill point G1 X79.425 Y63.53 ; move to first infill point G1 X79.396 Y63.585 ; move to first infill point G1 X78.911 Y63.328 ; move to first infill point G1 E.5 F3000 ; ; unretract ;TYPE:Internal solid infill ;WIDTH:0.420424 G1 F12000 M106 S81 ; enable fan G1 X77.989 Y64.25 E.0389 ; infill

The commanded speed is F18000 but RRF can't maintain that speed at the boundaries between moves because the direction changes between the moves would cause the jerk limit to be exceeded. So RRF reduces the speed at the boundary to a value that doesn't cause the jerk limit to be exceeded.

It's possible that you are getting movement queue underruns, which would contribute to the jerky movement. The M122 report you published doesn't show any, but perhaps you didn't run M122 after a print.

If you are getting layer shifts then it's likely that you have the maximum speed or acceleration or jerk set higher than the motor can handle at the current you are using. You can try increasing XY motor currents, if the motor rated current allows. This won't help if the speed is high enough for the torque to start reducing. You can use the calculator at https://www.reprapfirmware.org/emf.html to estimate that speed.

@scooby The PanelDue only shows temperatures related to heaters, ie nozzles, beds and chambers. If your bed temperature sensor isn't used by a heater (ie usually the bed heater), it will show on the 'Extras' tab in DWC only. You can define a 'dummy' heater, that uses an unused output, and map the temperature sensor to that, and define it as a bed or chamber. See https://docs.duet3d.com/User_manual/Connecting_hardware/Heaters_bed#configuring-a-bed-heater

Ian