I have raised the problem on Ratrig Discord, and "H2 removal" has been raised as a pull request on git-hub for main config files. So it should be addressed in revisions, anyone else following can be pointed to updating their system homing files.
Thanks all
I have raised the problem on Ratrig Discord, and "H2 removal" has been raised as a pull request on git-hub for main config files. So it should be addressed in revisions, anyone else following can be pointed to updating their system homing files.
Thanks all
Ah, it just dawned on me what you and dc42 said.
Please excuse my ignorance, I am somewhat new to G codes and their nuances, specifically to coreXY movement.
Please note that I did not write the base setup code, these are typical RatRig predefined files that I have been slowly massaging into shape for my setup as I learn the structure. It appears I have observed an error in these setup files. Although I didn't notice the unintended movement prior to the 3.4.1 update.
Sorry, but I think you have misunderstood the issue I observed.
The problem is, whilst the motion moves in the X-axis only, Y-axis was also drifting in the plus direction.
This did not happen with the first move to the end stop with H1, only when there is the H2 move away and return to the end stop.
Originally the touch and bump were at 1mm, but I adjusted the value to 5mm to observe the problem.
I removed the H2 and the Y-axis drift stopped. I had left the 5mm moves in place to keep an eye on the homing sequences.
Hi, I have observed a possible bug after updating from 3.3 to 3.4.1
I just updated software on Duet 3 MB6HC + SBC combinations from 3.3 to 3.4.1 on two 3D printers, both (RatRig CoreXY 3) based systems.
These printers are in a private (University) network with no internet exposure, so the updates were performed by re-imaging the SD card with the latest download revision listed as 3.4.1.
I used this file, imaged with the Raspberry Pi software, https://pkg.duet3d.com/DuetPi-lite.zip
I also observed the systems after the immediate boot-up had mixed environments of 3.3 and 3.4.1, this was solved by running M997 to force the SBC update as suggested on these forums.
The possible bug
The odd behavior was observed on both machines.
During Homing X and Y, individually and as XYZ home all, the second bump sequence was moving oddly.
In detail, observing Home X, the movement to the end stop works as expected.
G1 H1 X-625 F3600 ; Move quickly to X endstop and stop there (first pass)
However, the minor move for the bump moves unexpectedly.
G1 H2 X5 F600 ; Go back a few mm
G1 H1 X-625 F360 ; Move slowly to X endstop once more (second pass)
What was observed was the main carriage slowly moved in the +Y direction during the move-out and return to the second end stop activation.
Home Y also has the same drift in +Y, but the observation is no movement in -Y actually is performed as there is unwanted drift in +Y at the same time.
I solved the immediate problem as the example below by removing the H2 from all homing instructions, however, I suspect this isn't the intended behavior or long-term solution.
echo "Home X"
M201 X500.00 Y500.00 ; Reduce acceleration for homing moves
G91 ; Relative positioning
G1 H2 Z5 F6000 ; Lift Z relative to current position
G1 H1 X-625 F3600 ; Move quickly to X endstop and stop there (first pass)
G1 X5 F600 ; Go back a few mm
G1 H1 X-625 F360 ; Move slowly to X endstop once more (second pass)
M201 X3000 Y3000 ; Return to full acceleration
G1 H2 Z-5 F6000 ; Lower Z relative to current position
G90 ; Absolute positioning
G4 S3
echo "Home X Complete"
Supporting files, M122 console and system files.
Notes:
H2 has been removed from the homing files.
T0 was added to the config file to allow movement of the tool head extruder(is this a bug as well?)
console.txt
bed.g
config.g
deployprobe.g
dwc-settings.json
homeall.g
homex.g
homey.g
homez.g
pause.g
PrimeNozzle.g
resume.g
start.g
stop.g
trigger6.g
(updated) I didn't like passing 230vac power to the front of the printer to switches, so I found another mains relay with a 6vdc coil (trips on 4.5vdc), Now I'm controlling the switching with low voltage, I think this option is safer and still functions.
Still asking Duet team for comments, specifically the SBC being powered connected via the default cable to an unpowered MB that is then powered up. Is this a problem?
Hi,
RatRig Core-3 builds(two printers)
Duet3MB6HC main boards 1.01a
Pi4B 4GB
Looking for advice, confirmation, of my electrical plan.
Will there be any ill effects from powering and depowering the Duet MB whilst the Pi is live(5vdc) (connected via supplied SPI cable, board 1.01a with only Int 5v option)
Basically I am adding a Start & Emergency Stop buttons to my builds, but I don't want to damage the SD card/Pi firmware from sudden power offs. Therefore with my plan the buttons really start and stop the 24vdc supply and 230vac bed supply, the 5vdc supply the Raspberry Pi, power is controlled via main IEC14 plug switch.
I am also planning to add a secondary stacked switch to the start button to create a "pause/resume" switch. (later stage)
