3.2 Servo making a grinding noise on reboot/M999
-
@Phaedrux No it's not a BL touch. It's basically a servo that moves my optical sensor's probe into position/out of position, to commence a probe for the Z axis.
It happens only during M999 or when it is rebooted (or emergency stop) from the webgui (eg. after editing the config.g file)
Switching the machine off/on with the physical switch does not give this problem.
Also:
Board: Duet 2 WiFi (2WiFi)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.2 (2021-01-05)
Duet WiFi Server Version: 1.25 -
And did this behaviour only start after updating to 3.2?
-
As far as I can recall, yes. Printer has been out of action for quite some time doing upgrades on the Z-axis - so I did go and flash the newest firmware before commencing the configuration of it - though before I worked on the printer, I did not have this issue... Think it was firmware 3.0 or something. Not too sure.
Just downgraded to 3.1.1; and still the same....
-
Would you be able to test the behaviour in 3.1.1?
It should be pretty easy to switch between versions by uploading the respective release zip files to the system tab in DWC.
https://github.com/Duet3D/RepRapFirmware/releases/download/3.1.1/Duet2and3Firmware-3.1.1.zip
https://github.com/Duet3D/RepRapFirmware/releases/download/3.2/Duet2and3Firmware-3.2.zip
-
nevermind, looks like you beat me to it.
-
@Phaedrux haha nothing more than luck on my side
But yes, still the same is being observed.... Even if I go and issue M280 P0 S180 before the M999; it still does the same.... -
Thanks. Will add this to the list to investigate.
-
@Phaedrux Thank you
-
Would you be able to make a short video showing what it's doing?
-
sure. Where must I upload it?
-
Also a bit off topic, but with 3.2 the end-stop status on the 'Machine-Specific' tab is also missing....
-
Also found something else now. If I don't send any commands to the servo, and then issue M999; then there is no grinding or any activity. But as soon as I have issued a command to the servo; and then reboot, then this phenomenon occurs....
-
@Reefwarrior said in Servo making a grinding noise on reboot/M999:
Where must I upload it?
you can upload a small mp4 here to the forum or use dropbox or the like.
@Reefwarrior said in Servo making a grinding noise on reboot/M999:
end-stop status on the 'Machine-Specific' tab is also missing....
yes. hoping that will make a come back soon.
@Reefwarrior said in Servo making a grinding noise on reboot/M999:
If I don't send any commands to the servo, and then issue M999; then there is no grinding or any activity. But as soon as I have issued a command to the servo; and then reboot, then this phenomenon occurs
And that is true regardless of whether you have the M401/M402 commands present?
-
@Phaedrux Yes, Issued M280 instead of M401/2 and it does the same. So seems it is not linked to the M280/401/402 code; but perhaps something in the M999 code? Like basically sending a PWM pulse to the servo upon 'flushing' the memory before reboot or something.
-
@Phaedrux Attached the clip. Hope it is of some help - I have taken the 'arm' off the turning mechanism on the servo so it doesn't damage the gears inside...VID_20210114_193516 (1).mp4
-
Just to be super clear, you have no M401/M402/M280 commands at all in config.g, right?
-
@Phaedrux None, whatsoever.
-
Seems like I may be having a similar issue - I am using the exp.e3stop and exp.e4stop pins on the Duet WiFi as external signals for Arduino control, I just updated to RRF release 3.2. In my config.g I have:
M950 P0 C"exp.e3stop" Q500 M950 P1 C"exp.e4stop" Q500 M42 P0 S0 F500 M42 P1 S0 F500After reboot, for about 1 second the pins are set high, and also they try to go high after reboot has been triggered just before the shut off. You can see in this video (apologies for birds nest of wiring). I do not believe this behaviour was present on RRF 2, but since I upgraded I am not keen on reverting and for time being will try to just use some fan pins and see if they have the same issue.
-
@vasparshin said in 3.2 Servo making a grinding noise on reboot/M999:
Seems like I may be having a similar issue - I am using the exp.e3stop and exp.e4stop pins on the Duet WiFi as external signals for Arduino control, I just updated to RRF release 3.2. In my config.g I have:
M950 P0 C"exp.e3stop" Q500 M950 P1 C"exp.e4stop" Q500 M42 P0 S0 F500 M42 P1 S0 F500After reboot, for about 1 second the pins are set high, and also they try to go high after reboot has been triggered just before the shut off. You can see in this video (apologies for birds nest of wiring). I do not believe this behaviour was present on RRF 2, but since I upgraded I am not keen on reverting and for time being will try to just use some fan pins and see if they have the same issue.
The pins of the microprocessor default to inputs with pullup resistors enabled when the processor is reset. That is why you are seeing them go high. If you need to avoid this, either use an inverter or inverting gate between the output and the device (which is how the on-board heaters are driven), or add a pulldown resistor between 3.3K and 10K between the pin and ground.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
Thank you for explaining, I will try your suggestions. Just to be clear, do you mean putting a resistor between ground and the pin I wish to use as external IO signal (not sure what you mean by pni)? Is there a benefit to using an inverter/gate VS the resistor?
Did this behaviour change from RRF 2? I do not believe this was the case before but perhaps I haven't noticed it.
Also, I just tried to use the Fan0 pins for IO control but realised why I didn't originally - I am unable to get a signal below 0.4V and it maxes out at 12V, which is too high for Arduino (with max PWM set to 40% I could make it work). I am not sure why the voltage minimum is 0.4V - is this PWM related (shouldn't be a massive issue as Arduino threshold is over 2V)?
In any case, the voltage spikes to ~3.3 for about 1 second upon reboot - same issue as with the extra IO pins.
