3.2 Servo making a grinding noise on reboot/M999
-
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 F500
After 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 F500
After 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.
-
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. -
@dc42 I have soldered a 6.6k resistor in the wiring for the pwm signal - same thing still....
-
@dc42 Also I don't know if this is by chance, but if I use Q50 in the declaration, then the grinding noise is still there, but of a shorter duration.
-
Anybody any other ideas perhaps?
-
How about connecting the servo GND pin to a FAN control signal?
That way, (hopefully, @dc42 could verify) power would be removed from the servo during reboot and you'd need to "turn on the fan" with GCODE to power the servo again.
I would think a FAN output could handle the power requirements of a servo.
-
@alankilian Thank you for the reply. Seems the issue is with the PWM signal that gets generated. I have gone and started playing around with the PWM's Hz parameter on the declaration and that does change the amount of grinding - although I am beginning to think that it is just luck...
-
@Reefwarrior Yes, But I don't think changing the PWM frequency is the way to go.
Hobby servos like this should have a 50Hz update rate to function properly.
When the board resets and the signal value goes HIGH, the servo is going to mistakenly read that as a very long position pulse and will try to go all the way to one end of the travel.
Disconnecting toe power to the servo will prevent it from moving.
You could also build some external circuitry that blocks the constant-high signal during reboot. (I can describe that in another message if you're interested in going that way.)
But I think trying to disconnect the power would get you the results you like.
-
@alankilian Hi! Thank you Will tinker with this tomorrow - now I need to see which fan to substitute, as I am basically using all the fan's with PWM control....
-
avoid Fan1 since it powers on briefly at power up because it's intended for the heatsink fan in case the hotend was hot when power was cycled.
-
@Phaedrux Any specific recommendation? Or alternatively I can use an external mosfet connected to the expansion port for that too?