Homing sensors not working correctly with RRF3.3.0 stable

Phaedrux

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

Marco Bona

@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

Phaedrux

Just to verify, can you go back to the last 3.3 RC you tried to see if the behaviour is resolved?

Marco Bona

@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

Phaedrux

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.

Marco Bona

@phaedrux, sorry but procedure is not very clear, I may have some commands to insert in the SBC otherwise I cannot give you feedback.

jay_s_uk

@phaedrux it still works. I use it to generate the scripts used by the LPC/STM port

Phaedrux

@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/DuetVersions

Then follow these instructions to install a older version
https://github.com/DanalEstes/DuetVersions#run-duetregresssh

Ex: ./DuetRegress.sh 3.2.2

Marco Bona

@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

Marco Bona

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

Phaedrux

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

Marco Bona

@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

Marco Bona

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

Error: 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

dc42

@marco-bona I have added this to my list to investigate.

User3D

@dc42 I have faced a similar issue , when upgraded from 3.3beta Feb1 release to to RRF 3.3.0.
Axes X-Y are connected on EXP1XDs and I have end-limits on both the low and high ends. After upgrade, Axes started hitting the end-limits on the other(high) ends . I suppose It is the same issue as of @marco-bona & due to incorrect homing, axes hit the endstops.

NOTE: After downgrading to previous release i.e. (3.3beta Feb1) , problem is gone.

Do you concur the issues are similar?

Marco Bona

@dc42 , Thanks.
@User3D , yesterday I did some tests and it seems that adding a G4 between moves gets around the problem. I haven't tried to print but homing works. I enclose an example, let me know if you solve.

G1 H1 U-150 F2000                                                               
G4 P100                                                                         
G1 U5 F1000                                                                     
G4 P100
G1 H1 U-15 F500                                                                
G4 P100

With M400 it doesn't work, if you still have problems increase the delay

User3D

@marco-bona Thanks! Did you try printing? If yes then can you confirm that its not step skipping and homing issue only?

Marco Bona

@user3d, hello, I tried to make some prints but I can not give you a certain answer because on expansion board I have 2 axes that I do not usevery often during printing. From what I see I don't think there are any problems but I'm not entirely sure

dc42

@marco-bona said in Homing sensors not working correctly with RRF3.3.0 stable:

yesterday I did some tests and it seems that adding a G4 between moves gets around the problem.

I believe the cause is that there is a minimum permitted interval between successive reports from an endstop switch connected via CAN. The reason is to prevent contact bounce and interference spikes generating excessive CAN traffic. This interval is currently set to 30ms. Therefore, it should be sufficient to ensure there is at least 30ms elapsed time between the end of the first G1 H1 command and the start of the second G1 H1 command; and that there is at least 60ms between the start of the middle G1 command and the end of the second G1 H1 command. These delays can be achieved by making each of the second and third G1 commands take at least 30ms, or using G4 delay commands, or a combination of both.

In RRF 3.4beta4 I will either implement a fix or reduce the minimum interval.

Marco Bona

@dc42, thanks for reply