#1 – bdring 于 2025-04-07

Start with the switch issue.

I would turn off hard limits while you are debugging the machine. Add a reset button if you are worried about crashes.

What type of switches are you using? Send some pictures of your machine and wiring.

Turn on $message/level=debug.

Test the switches manually. Do you get any false or missing activations?

#2 – breiler 于 2025-04-07

I have noticed that on some controllers it will always start with the switches reporting as activated. For me it is because they are configured as normally open and left floating. If I go through and trigger them one by one they will behave correctly.

#3 – MitchBradley 于 2025-04-07

To expand on what Bart said – $limits does not disable the hard limit alarm, so it is best to turn off hard limits when using $limits for testing. When $message/level=debug, you get messages about limit switch activations and deactivations, rendering $limits unnecessary.

!Image

Regarding the jitter – try inverting the step pulses to see if that makes a difference.

#4 – bdring 于 2025-04-07

Does the jitter add up to any net motion? Does it just jitter or slowly drift?

Most servos jitter as they feel changes in load.

#5 – token47 于 2025-04-07

I do use hard limits turned off all the time, it works well. I use TMC drivers and stallguard for homing and they also fire randomly during normal usage when the load is high enough, therefore the hard limits cannot be trusted. I have never seen any downsides on this, except that some times the logs get spammed with limit switches being activated messages (which are ignored, just annoying).

#6 – MitchBradley 于 2025-04-07

> For me it is because they are configured as normally open and left floating.

Yet another reason to prefer external pullups! The other reason is that internal pullups tend to be weak with poorly-controlled values, often ranging from 50K to 100K. That results in inconsistent timing. The reason for poor internal pullups is that the silicon processes that make good, fast, small transistors do not result in good resistors with reasonable die areas.

#7 – daxliniere 于 2025-04-07

Thanks gents.
While looking for schematics for the input sections on the wiki, I discovered that 2 of the limit switches (2 & 26) require “:pu“. Now that this is enabled, all 5 limit switches are working (though the 2 limit switches it affected were not ones directly involved in the homing error).

> Test the switches manually. Do you get any false or missing activations?

Yep, always testing manually with $limits and no, all good (as long as it’s being held during a redraw cycle).

> I would turn off hard limits while you are debugging the machine.
>$limits does not disable the hard limit alarm

Ahh, I never would have guessed that in a million years, which is why I reported it as a bug. Seems like hard limit alarms should be ignored when $limits is active since you can’t (and shouldn’t) issue motion commands during limit switch testing anyway. Don’t you think?

>Add a reset button if you are worried about crashes.

I have door switch on an ‘e-stop’ style (mushroom) button and the main power switch is only 12″ from that.

> What type of switches are you using? Send some pictures of your machine and wiring.

High quality Matsushita and Burgess microswitches like both of these (without lever arms). They’ve never given me problems on this machine.
!Image

> Turn on $message/level=debug

Can do – what am I looking for with this? If it’s just limit switch testing, I’m satisfied everything is good there now.

> Start with the switch issue.

Done.
Should I post another issue for the jitter issue or is there any value in renaming this thread to the name of my CNC machine?

#8 – daxliniere 于 2025-04-07

> Does the jitter add up to any net motion? Does it just jitter or slowly drift?
>
> Most servos jitter as they feel changes in load.

Axes that are not (supposed to be) moving are jittering by random amounts. I had assumed crosstalk, so I replaced the 12-core cable I had with 3x 4-core shielded cables and I’m getting the same thing.

My next step will be to invert the pulses as per Mitch’s suggestion (once I work out how to do that.) (aaaand I have a recording session starting in 10 minutes. Thankfully I’m free tomorrow to continue debugging.)

#9 – MitchBradley 于 2025-04-07

Crosstalk between stepper motor cables is usually not a problem. The impedance is too low, on the order of a few ohms. You can get crosstalk from stepper cables to high impedance (10K or more) switch cables.

To invert the pulses, just add :low to the pin definition.

#10 – MitchBradley 于 2025-04-07

$message/level=debug is a better way to test switches than $limits. It shows all the events, not just current state sampled infrequently. I am disinclined to add more complexity to $limits, since there is a better way of testing. Maybe if I had infinite time I would do it, or maybe I would eliminate $limits entirely.

#11 – daxliniere 于 2025-04-11

> Crosstalk between stepper motor cables is usually not a problem. The impedance is too low, on the order of a few ohms. You can get crosstalk from stepper cables to high impedance (10K or more) switch cables.

Okay, that’s good to know, thanks.l

> To invert the pulses, just add :low to the pin definition.

Is that just for the step pin or dir and disable?

#12 – daxliniere 于 2025-04-11

Also, any idea why all 3 enable (disable?) LEDs change simultaneously even though I have defined individual pins and have sharedstepperdisablepin: NOPIN?

Tested by jogging with UGS.

#13 – daxliniere 于 2025-04-11

@MitchBradley To simplify my wiring setup, would there be any problem if I used the shield of the 4-core cable as the ground for the motor? The motor positive supply is already a separate wire running parallel to the 4-core signal cable. (I currently have the motor negative supply wire dangling in a temporary setup.)

Would this introduce jitter/crosstalk?

#14 – bdring 于 2025-04-11

Stepper Enables

Most machines should use idle_ms: 255 to keep the motors on. They could drift after homing if they disable. Change your config.

All enables work at the same time regardless of whether you use a shared or separate pins. The only advantage of separate enables is that you can manually disable one motor with $MD=X

#15 – bdring 于 2025-04-11

Are you seeing any step pin LED activity associated with the jittering motors?

#16 – daxliniere 于 2025-04-11

> Most machines should use idle_ms: 255 to keep the motors on. They could drift after homing if they disable. Change your config.

Will do, thanks.

> All enables work at the same time regardless of whether you use a shared or separate pins.

Why? Surely if you are moving in a single axis you would get a cleaner result if non-moving axes had their motors held in position?

#17 – daxliniere 于 2025-04-11

Maybe it would be a good time to get you to review my config.yaml for this 6X.

#18 – bdring 于 2025-04-11

You want enables on all the time.

Any moving axis will enable all motors in all idle_ms values.

#19 – daxliniere 于 2025-04-11

Enables or Disables? Motors are always marked as ‘En’ as is the 6x controller, but config.yaml says disables.

#20 – daxliniere 于 2025-04-11

Are all 18 motor LEDs supposed to be illuminated briefly at startup?

!2025-04-11_14-39-33.png

#21 – bdring 于 2025-04-11

I2S pins do not have a defined startup. We set them as soon as we can

#22 – bdring 于 2025-04-11

Do you know the signal pulse timing? I did not see it in the manual.

Some have really long delays especially enable.

#23 – MitchBradley 于 2025-04-11

I just now noticed that you are using MKS Servo 57D. What I said about crosstalk or lack thereof applies to conventional stepper motors, not necessarily to MKS Servo57. My Servo57 has opto-isolated signal inputs but with a common + wire. It is probably not too susceptible to crosstalk, but there could be wiring configurations that cause problems. The impedance is about 1K, so not terribly sensitive to noise, but certainly more sensitive than conventional stepper wiring where the coil wiring is differential (no common signal) at a few ohms.

Using a shield as the negative supply often works, but is not best practice. It could possibly induce noise, but it is hard to say for sure.

#24 – MitchBradley 于 2025-04-11

Very few people use MKS Servo 57, so we do not have much experience with what problems can occur. Mine is sitting in a box, having been tested briefly. I have no long-term production experience with it.

#25 – daxliniere 于 2025-04-12

> I2S pins do not have a defined startup. We set them as soon as we can

Okay, phew! I was worried that something was wrong since they seemed to be somewhat random each power-on.

#26 – daxliniere 于 2025-04-12

> Very few people use MKS Servo 57, so we do not have much experience with what problems can occur. Mine is sitting in a box, having been tested briefly. I have no long-term production experience with it.

Then I am more than happy to help getting them to a known configuration.

> My Servo57 has opto-isolated signal inputs but with a common + wire.

So how does that fit with the 6X controller?

#27 – daxliniere 于 2025-04-15

Hey @bdring and @MitchBradley, I looked at the 6X schematic and it seems that the I2SO ICs are set up for common cathode, not common anode. How will this work with the Servo57’s opto inputs being common anode? Any idea why it was working at all?

#28 – bdring 于 2025-04-15

The I2SO chips can drive and sink current. They are not “common” anything. Each can can be connected to either side of an LED.

If you need a common (+) on the servo side, then source it from another location on the controller. You can invert the pulse pin if the active state does not match what the servo expects.

!Image

#29 – daxliniere 于 2025-04-15

Thanks Bart. So I would disconnect the servos’ common pins from 6X’s motor COM terminals and connect altogether to 6X’s H1 +5v pin, yes?

Separately, is there any sense in considering driving the 3 axes via RS-485? Does FNC support that?

#30 – bdring 于 2025-04-15

I don’t think I ever called them a COM terminal. It is labeled Gnd.

My reading of the diagram would put + on the common terminal. I assume 5v is OK.

We don’t support RS485 for motion control. It is too slow for stepping and too hard to coordinate and time for planner segments.