Homing sensors not working correctly with RRF3.3.0 stable
-
@Phaedrux, No, it does not report any errors, there are only the warnings of the overheating of the extruders
-
M350 X16 Y16 Z16 W16 U16 V16 E32:32 I1 ; configure microstepping with interpolation M906 X{2800 * 0.5} Y{2800 * 0.5} Z{2800 * 0.5} W{2800 * 0.5} ; set motor currents (mA) and motor idle factor in per cent M906 U1800 V1500 ; set motor currents (mA) and motor idle factor in per cent M906 E{700 * 0.8}:{700 * 0.8} I60 ; set motor currents (mA) and motor idle factor in per cent M84 S30 ; Set idle timeout M92 X{200 / (20 * 2) * 16} Y{200 / (20 * 2) * 16} ; set steps per mmCan you send M92, M350, M906 by themselves in the console and see if they report the expected evaluated values?
-
Can you also send M584 and see what it reports?
M584 X0.0 Y0.1 Z0.2:0.3 U1.0 V1.1 W0.3 E0.4:0.5 P3
I notice you're trying to use driver 0.3 twice for Z and W. -
@phaedrux ,everything is correct
m584 Driver assignments: X0.0 Y0.1 Z0.2:0.3 U1.0 V1.1 W0.3 E0.4:0.5, 3 axes visible m92 Steps/mm: X: 80.000, Y: 80.000, Z: 802.005, U: 37.670, V: 5245.900, W: 802.005, E: 813.000:813.000 m350 Microstepping - X:16(on), Y:16(on), Z:16(on), U:16(on), V:16(on), W:16(on), E:32(on):32(on) m906 Motor current (mA) - X:1400, Y:1400, Z:1400, U:1800, V:1500, W:1400, E:560:560, idle factor 60% -
@phaedrux , Z axis has 2 motors, it has been like this for about a year and has never given any problems. I know of no alternatives to configuration
-
@marco-bona add G4 S5 in your config.g before any reference to the expansion board is made (so before M569)
-
@jay_s_uk, with delay before M569 I do not get anything different, same problem
-
@marco-bona said in Homing sensors not working correctly with RRF3.3.0 stable:
it goes in the opposite direction for 5mm and stops, instead it should move slowly until the limit switch is activated.
@marco-bona said in Homing sensors not working correctly with RRF3.3.0 stable:
G1 H1 U-150 F2000 ; move U until the endstop is triggered G4 P100 ; delay 0.1 sec G1 U5 F1000 ; move U back 5mm G1 H1 U-15 F500 ; move U slowly towards the switch until it triggers
that makes it sound like the endstop is triggered when it is not. What is the status of the endstop in M119 both when the switch is depressed and not depressed?
-
@phaedrux, The states of limit switches are correct, strange thing is that code runs correctly up to G1 H1 U-15 F500, then continues with the code as if the limit switch is active. I have another limit switch on the expansion card that has same problem. On DWC initial screen, axis states are reset after performing the reset. This behavior only affects sensors on expansion board
-
Just to verify, can you go back to the last 3.3 RC you tried to see if the behaviour is resolved?
-
@phaedrux, I can try, but I need a procedure having SBC connected, otherwise it is enough to replace files in system folder? Until before update it worked fine
-
This tool may be the easiest way to switch back to a specific version.
https://github.com/DanalEstes/DuetVersions
DuetRegress.
Though it likely hasn't been tested with 3.3 etc as Danal is unfortunately no longer with us.
-
@phaedrux, sorry but procedure is not very clear, I may have some commands to insert in the SBC otherwise I cannot give you feedback.
-
@phaedrux it still works. I use it to generate the scripts used by the LPC/STM port
-
@marco-bona said in Homing sensors not working correctly with RRF3.3.0 stable:
@phaedrux, sorry but procedure is not very clear, I may have some commands to insert in the SBC otherwise I cannot give you feedback.
To install it, you run this on your Pi console
git clone https://github.com/DanalEstes/DuetVersionsThen follow these instructions to install a older version
https://github.com/DanalEstes/DuetVersions#run-duetregressshEx:
./DuetRegress.sh 3.2.2 -
@phaedrux, i tried but i was unsuccessful. Yesterday I forgot to tell you that with the latest update I also reinstalled latest version of DuetPi but I don't think it is related to problem.
If I remember correctly I had a similar problem with RRF3.3 RC3 + 7, but then I had not deepened as stable version was released. With RRF3.3RC3 + 6 I'm sure everything was correct -
@dc42, @chrishamm , I try to raise this question to you since I have no longer received an answer.
I think it came from an update between version 3.3rc3 + 6 and 3.3rc3 + 7, if I remember correctly there has been an update on the expansions as well. The stable version has the same problem. -
If you were unable to downgrade the SBC version, can you try setting up in standalone mode to see if it's a firmware issue or SBC issue?
https://duet3d.dozuki.com/Wiki/Getting_Started_With_Duet_3#Section_Running_in_standalone_mode
Once in standalone issue it would also be much easier to change firmware versions by simply uploading the zip file of the firmware version you want.
https://github.com/Duet3D/RepRapFirmware/releases/download/3.3/Duet2and3Firmware-3.3.zip
https://github.com/Duet3D/RepRapFirmware/releases/download/3.2.2/Duet2and3Firmware-3.2.2.zip
-
@Phaedrux , @dc42, @chrishamm, I tried in standalone mode, I have the same problem I have with SBC starting from version 3.3RC3 + 7(https://www.dropbox.com/sh/xfsvscbaab0dtzl/AACCcSeiTNINZL-xbs6IhC4Ja?dl=0). Latest release where limit switches work correctly is 3.3 RC3 + 6, if I am not mistaken, afterwards an update was also made on the expansion boards. I cannot provide you with a report in standalone mode because I do not have possibility to connect a network cable to modem, but I am still available for further tests.
Thank you -
@Phaedrux ,I wanted to know if there was any update or some solution to fix the problem. I would like to inform you that heater set on the expansion board also has problems with this release.
Furthermore, when starting a print, this error also appearedError: Failed to get macro response within 3000ms from SBC (channel File)I am now working in SBC mode, can anyone give me an answer?
Thank you
Marco
