Servo motor causing Lost communication with MCU 'mcu'

Basic Information:

Printer Model: Custom
MCU / Printerboard: Fysect Spider V1.1
Host / SBC: MKS Pi
klippy.log: klippy.log (185.9 KB)

Hi,
I’m using an MG90S servo motor to deploy a klicky probe. The issue I’m running into is if the servo is repeatedly used then I’ll lose communication with the mcu.
Initially I had the servo plugged into the BL touch connection, thinking that might be overloading it I moved it to a 3 wire LED connect rated at 5A.
The movement of the servo is fine providing communication is there.
I also thought electrical noise might have been upsetting the USB connection between the host and the mcu, so I changed that over to uart and everything motion wise is working fine until I use the servo too much.

If I repeatedly exercise the servo it’ll be 10 commands or less for the effect to happen.

I’m at a loss on this, the only thing I have is electrical noise from the servo could be upsetting the mcu? Searching the web I find a few similar issues, but I’ve yet to see a real answer for whats causing this.

To add to this, I think the issue might be electrical noise.
I’ve been through and made sure that the printer frame is earthed properly to the power supply. I had some hopes that’d fix it but no such luck.

Please post a drawing (with pictures) of how you have wired your printer.

Here’s most of the wiring…

I’ve attached it as the PDF below, that’s probably easier to read.

Schematic.pdf (3.2 MB)

Let me know if details are missing that might help, I’ve left off the parts connected to the tool-head board as they’re probably not relevant for this.

Here’s the setup on the side of the thing, this is all prototype so still messy.

The mcu:

The MKSPi:

An overall view of the thing:

The offending servo:

Tool head:

Something else I looked into was pwm_cycle_time you can’t set this in the servo section, but it appears to be defaulted to 0.100s whereas my servos datasheet has it at 0.050s, thinking it might be this I redefined the servo to use pwn_tool instead but this failed also.

This section from pwm_tool makes me wonder if this is what’s causing the MCU to shutdown?
If it is I don’t know what to do about it.

#maximum_mcu_duration:
#   The maximum duration a non-shutdown value may be driven by the MCU
#   without an acknowledge from the host.
#   If host can not keep up with an update, the MCU will shutdown
#   and set all pins to their respective shutdown values.
#   Default: 0 (disabled)
#   Usual values are around 5 seconds.

Thank you - that’s a great amount of information and just what’s needed to help diagnose the issues.

A few things that aren’t clear:

  1. what is the communications connection between the MKS Pi V1.1 and the Spider board? I can see a serial connection from the MKS Pi V1.1 and the board at the bottom of the wiring diagram, but I don’t see one between the MKS Pi V1.1 and the Spider board.
  2. You talked about grounding the frame but you don’t show any indications of that in the schematic or the photographs.
  3. What is going on with the board at the bottom of the wiring diagram? It looks like it’s just being used for endstops but when I look at your klippy.log, I don’t see a [mcu ...] statement for it and the endstops all seem to be defined on the Spider.
  4. When I look at your klippy.log, you have endstop pins defined for each of your Z Axis stepper motor definition - you only need one for the z stepper, nothing is required for the z1 and z2 steppers.

Interesting looking printer - you’ve obviously put a lot of work into it.

@mykepredko Thanks for looking into this, the smaller diagram on the bottom right of the picture is a zoomed in section of the spider board, if you follow the green line up it’ll get to a dotted square that it represents.

On the grounding in the first photo you can see the yellow/green wires going from the PSU to the base of the controller box and the frame.

on the Z max end stops with the 3 Z motors, on homing the bed will drive down to trip all 3 which gets the bed basically level, then it comes up and I do a Z tilt adjust. I’m more comfortable doing that, that trying to launch straight into the Z tilt and I think the bed can tilt enough that the klicky switch would struggle to work at the extreme, and then things would get really messy.

My suspicion is that either there’s too much electrical noise still or the board just does not like driving servo motors. If I were using a normal Pi I’d have moved it to one of the gpio pins on that, as it is I can’t do that.
So, this morning I went and bought a pico (worth the A$9 bet). I’ve set the servo to run from that and so far, there’s been no issues. So hopefully the issue is done. But I’ll give it some more time before I claim victory.

Okay, that wasn’t clear to me that the box was part of the Spider.

Knowing that, I have to point out that you have a ground loop between the MKS Pi V1.1 and the Spider (Ground connected on the two boards from your bulk power supply and another ground connection on the two board’s serial ports). I’m pointing that out because you’re not using shielded wires and you have some pretty long wire runs. Honestly, I would have thought that a commercially available (even from a dollar store) USB cable would be superior.


The only reason I would think that the servo could be a problem electrically is if it is stalled and even then, it will only draw 700mA:

I’m looking at the V1.1 and 5V is provided by the SY8368 Buck converter chip which is capable of 8A in normal operation and 16A for surges (I’ve used the chip in my designs) so I’m reluctant to say that in the stall condition enough current is drawn to either cause a problem with the 5V supply on the board (which also supplies the MCU) or could radiate enough energy to cause a noise problem in the system.


That’s great that the Pico is not having any issues. I hope that continues, although I would be curious as to understand what’s happening to cause the problems.

Now, if you continue to get issues, there are a few things in your klippy.log that jump out at me.

What is your printer front end? From your klippy.log, it looks like you’re running Obico and I’m wondering if there are any correlation with your problems and bringing up your front end/web page?

You have a lot of macros devoted to the servo and levelling - almost 1,500 lines worth. Who wrote them and how have you validated them on your system? I’m always suspicious of a lot of macros - there isn’t a decent debug capability available for them and they can easily run amok and do unexpected things.

Now, when I look through your macros I see that you’re setting your servo movement ranges as:

variable_servo_deploy = 172
variable_servo_retract = 50

but, as I go through your error listing, I see:

Dumping 20 requests for client 281472881345704
Received 90.515305: b'{"id": 281472803709168, "method": "objects/query", "params": {"objects": {"webhooks": null, "print_stats": null, "virtual_sdcard": null, "display_status": null, "heaters": null, "toolhead": null, "extruder": null, "gcode_move": null, "gcode_macro _OBICO_LAYER_CHANGE": null, "fan": null, "heater_bed": null}}}'
Received 91.515989: b'{"id": 281472803710848, "method": "objects/query", "params": {"objects": {"webhooks": null, "print_stats": null, "virtual_sdcard": null, "display_status": null, "heaters": null, "toolhead": null, "extruder": null, "gcode_move": null, "gcode_macro _OBICO_LAYER_CHANGE": null, "fan": null, "heater_bed": null}}}'
Received 92.249038: b'{"id": 281472803709672, "method": "gcode/script", "params": {"script": "SET_SERVO SERVO=klickyservo ANGLE=180"}}'
Received 92.517304: b'{"id": 281472803710232, "method": "objects/query", "params": {"objects": {"webhooks": null, "print_stats": null, "virtual_sdcard": null, "display_status": null, "heaters": null, "toolhead": null, "extruder": null, "gcode_move": null, "gcode_macro _OBICO_LAYER_CHANGE": null, "fan": null, "heater_bed": null}}}'
Received 93.522658: b'{"id": 281472803712752, "method": "objects/query", "params": {"objects": {"webhooks": null, "print_stats": null, "virtual_sdcard": null, "display_status": null, "heaters": null, "toolhead": null, "extruder": null, "gcode_move": null, "gcode_macro _OBICO_LAYER_CHANGE": null, "fan": null, "heater_bed": null}}}'
Received 94.520090: b'{"id": 281472803711240, "method": "objects/query", "params": {"objects": {"webhooks": null, "print_stats": null, "virtual_sdcard": null, "display_status": null, "heaters": null, "toolhead": null, "extruder": null, "gcode_move": null, "gcode_macro _OBICO_LAYER_CHANGE": null, "fan": null, "heater_bed": null}}}'
Received 95.521500: b'{"id": 281472803712808, "method": "objects/query", "params": {"objects": {"webhooks": null, "print_stats": null, "virtual_sdcard": null, "display_status": null, "heaters": null, "toolhead": null, "extruder": null, "gcode_move": null, "gcode_macro _OBICO_LAYER_CHANGE": null, "fan": null, "heater_bed": null}}}'
Received 96.324835: b'{"id": 281472803709448, "method": "gcode/script", "params": {"script": "SET_SERVO SERVO=klickyservo ANGLE=30"}}'
Received 96.522674: b'{"id": 281472803333064, "method": "objects/query", "params": {"objects": {"webhooks": null, "print_stats": null, "virtual_sdcard": null, "display_status": null, "heaters": null, "toolhead": null, "extruder": null, "gcode_move": null, "gcode_macro _OBICO_LAYER_CHANGE": null, "fan": null, "heater_bed": null}}}'
Received 97.523901: b'{"id": 281472803334296, "method": "objects/query", "params": {"objects": {"webhooks": null, "print_stats": null, "virtual_sdcard": null, "display_status": null, "heaters": null, "toolhead": null, "extruder": null, "gcode_move": null, "gcode_macro _OBICO_LAYER_CHANGE": null, "fan": null, "heater_bed": null}}}'
Received 98.529217: b'{"id": 281472803335304, "method": "objects/query", "params": {"objects": {"webhooks": null, "print_stats": null, "virtual_sdcard": null, "display_status": null, "heaters": null, "toolhead": null, "extruder": null, "gcode_move": null, "gcode_macro _OBICO_LAYER_CHANGE": null, "fan": null, "heater_bed": null}}}'
Received 99.526887: b'{"id": 281472803333624, "method": "objects/query", "params": {"objects": {"webhooks": null, "print_stats": null, "virtual_sdcard": null, "display_status": null, "heaters": null, "toolhead": null, "extruder": null, "gcode_move": null, "gcode_macro _OBICO_LAYER_CHANGE": null, "fan": null, "heater_bed": null}}}'
Received 99.710919: b'{"id": 281472803710120, "method": "gcode/script", "params": {"script": "SET_SERVO SERVO=klickyservo ANGLE=180"}}'
Received 100.527983: b'{"id": 281472803332504, "method": "objects/query", "params": {"objects": {"webhooks": null, "print_stats": null, "virtual_sdcard": null, "display_status": null, "heaters": null, "toolhead": null, "extruder": null, "gcode_move": null, "gcode_macro _OBICO_LAYER_CHANGE": null, "fan": null, "heater_bed": null}}}'
Received 101.531083: b'{"id": 281472803333624, "method": "objects/query", "params": {"objects": {"webhooks": null, "print_stats": null, "virtual_sdcard": null, "display_status": null, "heaters": null, "toolhead": null, "extruder": null, "gcode_move": null, "gcode_macro _OBICO_LAYER_CHANGE": null, "fan": null, "heater_bed": null}}}'
Received 102.530306: b'{"id": 281472803334744, "method": "objects/query", "params": {"objects": {"webhooks": null, "print_stats": null, "virtual_sdcard": null, "display_status": null, "heaters": null, "toolhead": null, "extruder": null, "gcode_move": null, "gcode_macro _OBICO_LAYER_CHANGE": null, "fan": null, "heater_bed": null}}}'
Received 103.531573: b'{"id": 281472803334408, "method": "objects/query", "params": {"objects": {"webhooks": null, "print_stats": null, "virtual_sdcard": null, "display_status": null, "heaters": null, "toolhead": null, "extruder": null, "gcode_move": null, "gcode_macro _OBICO_LAYER_CHANGE": null, "fan": null, "heater_bed": null}}}'
Received 104.535033: b'{"id": 281472803332840, "method": "objects/query", "params": {"objects": {"webhooks": null, "print_stats": null, "virtual_sdcard": null, "display_status": null, "heaters": null, "toolhead": null, "extruder": null, "gcode_move": null, "gcode_macro _OBICO_LAYER_CHANGE": null, "fan": null, "heater_bed": null}}}'
Received 105.347303: b'{"id": 281472803334240, "method": "gcode/script", "params": {"script": "SET_SERVO SERVO=klickyservo ANGLE=30"}}'
Received 105.538405: b'{"id": 281472803332504, "method": "objects/query", "params": {"objects": {"webhooks": null, "print_stats": null, "virtual_sdcard": null, "display_status": null, "heaters": null, "toolhead": null, "extruder": null, "gcode_move": null, "gcode_macro _OBICO_LAYER_CHANGE": null, "fan": null, "heater_bed": null}}}'

I’m obviously not familiar with your code, but with a cursory look, I can’t find anywhere where the servo should be set to 180° or 30°.

Do you have any ideas on this?

Finally, when I run @Sineos 'klippy.log` analyzer, I was surprised by your bed temperature:

While the extruder maintains an even 30.3C, your bed temperature starts at 0C and then falls to almost -110C and then stabilizes at -79.7C.

I’m not sure what to make of this as I would think this means there is a problem with the thermistor connection and Klipper should catch that before moving forward. I don’t know if that is suppressed by the macros - do you have any idea?

As I said above, I hope you’ve solved your problems and let us know how things are working for you!

Ground loops are not good, I’ll look at what I can do about that, maybe not have the ground on the uart connection.
I’d had a USB cable doing the connection before, but moving it to uart was one of the steps I’d done to try and fix it, which made no difference.

The system configuration is from the MKS Pi Git:

I’ve not noticed issues with it, at this stage it was working well enough so has been left alone.
The font end is Fliudd which comes up fine.

At the time of this testing the heater bed thermocouple was probably not connected, hence the odd temperature readings. I try to make sure I’ve got one bit working right before I move onto the next, and the heater bed being 240v got left until last as I want no mistakes with that.

The macros relate to the klicky probe which came from their git:
GitHub - jlas1/Klicky-Probe: Microswitch probe with magnetic attachment, primarily aimed at CoreXY 3d printers

And the Orbiter 2 smart sensor which were also from their git:
GitHub - RobertLorincz/Orbiter-2-Smart-Sensor: Orbiter 2 Smart Sensor

I’ve just ran with the OOTB macros for the moment, I believe there is more there than I will need so at some point I will try and cull it down.
Sorry the differences in deploy and retract angles will be from where I was screwing around with different things. For example, I’m now pretty sure for the MG90S’s I have the PWM range is between 0.0005 and 0.0025 whereas the data sheets say it should be between 0.001 and 0.002.

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.