Problem: Inconsistent behaviour with servo motors #859

Try changing idle_ms to 255

Try changing idle_ms to 255

Already tried. didn’t helped.

Here is video: https://youtu.be/33M7h_5wbLg

Was the video taken with idle_ms: 255 ?

Video was taken with idle_ms: 150. But I already tested and testing now with 255.

Not really understand what happining… Sometimes I try to move A or B axis, and X, Y or Z starts to move. Why?

Video WebUI example: https://youtu.be/SiKnWTKoyTk

Can you send a photo of your controller?

Sorry for bad quality photo.

All axis including servo is directly connector to therminals. No filter is used.

Servo and stepper motors pinout

S1 – Servo1
S2 – Servo2

The stepper drivers went creazy couse the low voltage of the logic, dm556 need 4/5V mininum for the logic.
U need to amplify the dir ena and pulse signals from 0÷3.3V to 0÷5V

Thanks for letting me know that. My test is easier if use a 6 pack and an RC Servo module. That uses I2SO_Stream steps instead of your RMT.

It sounds like the steppers motors are not related to this issue.

I just tested about 100 moves on A and it never caused B to move. Same with B moves.

Can you compile and load the the devt branch? It allows you to set the servo update interval with a timer_ms: setting. The default is 75, but 20 would be better for servos.

    motor0:
      rc_servo:
        pwm_hz: 50
        output_pin: gpio.4
        min_pulse_us: 1000
        max_pulse_us: 2000
        timer_ms: 20

The stepper drivers went creazy couse the low voltage of the logic, dm556 need 4/5V mininum for the logic. U need to amplify the dir ena and pulse signals from 0÷3.3V to 0÷5V

This could be true but it is not necessarily true. Many optocouplers are much more sensitive than their guaranteed ratings. I have driven optocoupled steppers from 3.3V with great success.

The low value (2) for pulse_us could also be the problem. There is no advantage to using a short pulse, because the fastest axis only moves at 2000 mm/min * 80 steps/mm / 60 sec/min = 2667 steps/sec, or 375 us/step.

Another possible concern is the use of AP mode for the WiFi. That is a known source of issues due to memory problems in the Espressif AP code. We recommend using AP mode only for initial setup. To eliminate this as a contributor to the problem, please either switch to STA mode or turn off the radio.

I compiled it and tested. It looks like it works much better.

But… I get some weird coordinates when jogging. Am I doing something wrong?

1. Homing A and B axis
2. Jogging -10 with A axis and machine coordinate shows -1.713
3. Then pressing +1 and machine coordinate changes to -4

You have soft limits set, with an A axis range of 0..5 mm. Jogging by -10 is not going to work.

What probably happened was that there is a work coordinate offset so +5 in machine coordinates is 0 in work coordinates and 0 in machine coordinates is -5 in work coordinates. When you tried to jog to -10, the jogging code truncated that to stay within the machine range of 0..5 (work -5..0). The jog ended up at -5, but the ending position of -5 did not get reported because you hit the +1 jog before the final report was issued; the -1.713 was an interim report. Then the +1 jog went from -5 to -4.

Well, according to the display, there is no WCO offset – but it is possible that the UI has not picked up on that offset yet. There could be a glitch in the auto reporting. The offset field is not issued in every report, per longstanding GRBL behavior.

The stepper drivers went creazy couse the low voltage of the logic, dm556 need 4/5V mininum for the logic. U need to amplify the dir ena and pulse signals from 0÷3.3V to 0÷5V

This could be true but it is not necessarily true. Many optocouplers are much more sensitive than their guaranteed ratings. I have driven optocoupled steppers from 3.3V with great success.

The low value (2) for pulse_us could also be the problem. There is no advantage to using a short pulse, because the fastest axis only moves at 2000 mm/min * 80 steps/mm / 60 sec/min = 2667 steps/sec, or 375 us/step.

Another possible concern is the use of AP mode for the WiFi. That is a known source of issues due to memory problems in the Espressif AP code. We recommend using AP mode only for initial setup. To eliminate this as a contributor to the problem, please either switch to STA mode or turn off the radio.

Well the stepper motors are working great with my setup. Only sometimes it gets crazy and starts to move randomly when servo axis is moved. I think it could be because the voltage drops and the pin becomes floating between HIGH and LOW, but I use external power source for servo motors, and only GND and signal is connected to ESP32, so voltage should not drop when I move servo axis.

Let’s say the voltage drops too much causing stepper motors vibrate and move in random direction, in which case FluiNC wouldn’t know and wouldn’t display the changed coordinates, right? But coordinates changes – so is this is a software bug?

The thing that is a little odd with your config is the range. On X it is (150 to 1050). I would have to see your current x axis config to fully explain it.

Send $axes/x to see the full config for X.

The negative homing and soft limits could create a weird edge case that is not handled right. It should home and set the mpos to 150, but it is setting it to 0. Now you are outside the range with soft limits on.

[MSG:INFO: Axis X (150.000,1050.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     standard_stepper Step:gpio.18 Dir:gpio.27:low Disable:NO_PIN]

Also, in the future. please ? before and after each command. I need to see if the mode has returned to idle and where it thinks it is.

The “jog” status is weird too.

I have some theories to check.

1. repost the current config file. Send $CD to get it.
2. Send $message/level=debug to get debug messages and send $H.

I have an explanation for why the soft-limit-enforced range for A and B is -5..0 instead of 0..5. It is because

1. There are no limit switches for A and B, thus actual homing cannot be performed, and
2. The homing cycle for A and B is set to 1. If you want homing to set mpos_mm for an axis to the value of mpos_mm , without actually performing homing motion, you must set cycle: -1 for that axis.

Edit: The above is incorrect because Servo homing works differently; it does not use limit switches, but rather moves to a fixed position.

This is what I’m trying to achieve:

1. Simply home X, Y and Z axis to it’s 0 position. For this mpos_mm should be set to 0 as I understand. Maximum travel is correct, X axis 900mm, Y axis 1200mm, Z axis 150mm.
2. Home servo motors to 0 (in the middle), but be able to control it from -5 to 5 for example.

Question:
I would like to calibrate servo motor that I could enter degree and it will move to that degree. As I understand step_per_mm should be changed and with that setting I should be able to get what I want. But changing step_per_mm on servo does nothing. Maybe some other option should be used on servo?

I will try my best to debug machine and will provide logs as soon as possible @MitchBradley @bdring

I will explain servo calibration after we solve the other issue.

Please provide your current config file and the log during homing.

We need good data in order to debug this. In the report above, you wrote:

ok
G91 G21 F500 A-1
ok
<Jog|MPos:2.480,2.480,2.475,4.980,5.000|FS:500,0|Ov:100,100,100>
?
<Idle|MPos:150.000,150.000,150.000,4.000,5.000|FS:0,0>

The <Jog|..> status is consistent with a “$J=G91 G21 F500 A-1” command but not with a “G91 …” command that is not preceded by “$J=”. So I think you might not have provided accurate data.

The lack of complete and accurate data is wasting everyone’s time.

I think we understand the problem. This is the first time we have seen it due to you doing several non standard things.

It appears you are jogging before homing all axes. You have soft limits enabled. Soft limits should not be used on any axis that has not been homed. Nothing has established the true machine location until it is homed.

You also have axes defined with a range that does not include 0. The machine turns on at 0 for each axis. The true location is not known so 0 is used. The machine starts with a soft limit issue.

There is a function to makes sure jogs are forced to work in the axis range for all axes with soft limits. This prevents accidentally jogging into a soft limit error. This is causing the unintended motion.

We are not going to change the basic behavior. We are going to add some messages and alarms. You will not be able to move any axis that has not been homed and has soft limits on.

I apologize for the reply delay.

@bdring I think you are right. I set mpos_mm to 0 on X, Y and Z axis. After homing all axis, seems that the problem gone. X, Y or Z axis does not move when controling servo A or B axis.

Are the debug logs still needed and I should gather them?

With new config problem does not occur:
solo1.yaml.txt

So could you tell me how should I calibrate my servos?

You have a pulse length range and a units range. These ranges are linearly mapped to each other.

You can adjust the width of the ranges and slide them up or down.

The pulse lengths can be adjusted live. Be sure to permanently save them to the config after you get what you want.

Please check the wiki on live tuning. Also be aware the most RC servos are not as accurate or repeatable as steppers.

Thank you! I calibrate them that millimeters would be equal to degree! Nice!

What about homing servo in the middle, is it possible? @bdring

No, homing only works to ends.

It appears you are jogging before homing all axes. You have soft limits enabled. Soft limits should not be used on any axis that has not been homed. Nothing has established the true machine location until it is homed.

Okay. Servo motors does not require homing to use soft limits theoretically, because they does not have any limit switches and uses simple PWM to get to the right position.

As I understand it’s not possible to use soft limits without homing servo axis now, I’m right? But it should be possible.

You do not need to home the RC Servos. You can use soft limits if you stay within the axis range. This means the range should include 0, because the machine starts at 0.