Closed Dominykasssx closed 1 year ago
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?
-10
with A axis and machine coordinate shows -1.713
+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?
What happens if you disconnect the power to the servos?
If you only move an RC Servo and the stepper moves and reports that it has moved it would be a bug. The only thing that connects axes together is kinematics and cartesian doesn't do any of that. We have never seen that in any rev of the firmware.
Can you do your testing with FluidTerm. It is hard to follow what you are doing in the WebUI. Manually request status before and after moves. Show the offsets with $#.
Okay, so I connected my ESP to my local network.
Maybe my homing configuration is still wrong?
A-1
This is maybe because of mpos_mm: 150.000
is set on X, Y and Z axis?
Not FluidTerm, but webui terminal by manually writing commands:
[MSG:INFO: '$H'|'$X' to unlock]
$H
ok
<Idle|MPos:0.000,0.000,0.000,5.000,5.000|FS:0,0|WCO:0.000,0.000,0.000,0.000,0.000>
$#
[G54:0.000,0.000,0.000,0.000,0.000]
[G55:0.000,0.000,0.000,0.000,0.000]
[G56:0.000,0.000,0.000,0.000,0.000]
[G57:0.000,0.000,0.000,0.000,0.000]
[G58:0.000,0.000,0.000,0.000,0.000]
[G59:0.000,0.000,0.000,0.000,0.000]
[G28:0.000,0.000,0.000,0.000,0.000]
[G30:0.000,0.000,0.000,0.000,0.000]
[G92:0.000,0.000,0.000,0.000,0.000]
[TLO:0.000]
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>
$#
[G54:0.000,0.000,0.000,0.000,0.000]
[G55:0.000,0.000,0.000,0.000,0.000]
[G56:0.000,0.000,0.000,0.000,0.000]
[G57:0.000,0.000,0.000,0.000,0.000]
[G58:0.000,0.000,0.000,0.000,0.000]
[G59:0.000,0.000,0.000,0.000,0.000]
[G28:0.000,0.000,0.000,0.000,0.000]
[G30:0.000,0.000,0.000,0.000,0.000]
[G92:0.000,0.000,0.000,0.000,0.000]
[TLO:0.000]
ok
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.
$CD
to get it.$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
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:
mpos_mm
should be set to 0 as I understand. Maximum travel is correct, X axis 900mm, Y axis 1200mm, Z axis 150mm.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.
Controller Board
Custom board.
Machine Description
I'm using external stepper drivers DM556. Stepper motors works fine for X, Y and Z axis. Servo does not work properly on any axis.
Input Circuits
Configuration file
Startup Messages
User Interface Software
WebUI
What happened?
I have a problem while trying to use RC servo motors. I want to use 2 servo motors on A and B axis. Servos are moving very weird. For example I'm moving A axis, but B axis starts to spin too sometimes.
I do not know why my servos are not working with FluidNC correctly, I'm using 12v servos and they work just fine with ESP32 and it doesn't require signal to be 0-12V or similar. I'm using external power source of 12V. Ground and Signal is connected to ESP32
Maybe my config is wrong?
I already tried to change value of idle_ms and remove it completely. Change pwm_hz, steps_per_mm. Configure those Servo motors on X, Y or Z axis. Nothing helped
Problem video: https://youtu.be/33M7h_5wbLg
Other Information
I trought maybe my servo motors are connected wrong or something bad with wiring. So I tested my servo motors with simple sketch:
And it worked just fine without any lagging or delay.
Video: https://youtube.com/shorts/PDRU53byrSg
So what can be wrong with my configuration?