Problem: CL86T v4.1 external driver Timing config, Startup error using ":pu" or the CNC will not move.
Red5-3D opened this issue · comments
Wiki Search Terms
Controller timings, Controller enable, MKS tiny bee external controllers.
Controller Board
MKS TinyBee
Machine Description
CNC conversion to an import mill. Same size and most of the parts as a Grizzly G0704 mill. 3 axis, 3 stepperonline closed loop Nema 34 motors with Stepperonline CL86T V4.1 closed loop drivers. Each stepper/controller came as a kit from stepperonline. I am using the external stepper pins on the MKS tinybee board where all share a common ground. Steppers are direct drive to ballscrews.
Input Circuits
No response
Configuration file
: MKS TinyBee V1.0_001
name: Mill
meta: (6.7.2024) by Red5
kinematics:
cartesian:
#uart1:
#txd_pin: gpio.17
#rxd_pin: gpio.16
#rts_pin: NO_PIN
#cts_pin: NO_PIN
#baud: 1000000
#mode: 8N1
#uart_channel1:
#report_interval_ms: 75
#uart_num: 1
stepping:
engine: I2S_STREAM
idle_ms: 250
pulse_us: 4
dir_delay_us: 2
disable_delay_us: 200000
segments: 12
axes:
x:
steps_per_mm: 640
max_rate_mm_per_min: 1000
acceleration_mm_per_sec2: 39
max_travel_mm: 465
soft_limits: true
homing:
cycle: 1
positive_direction: false
mpos_mm: 0
feed_mm_per_min: 300
seek_mm_per_min: 1200
settle_ms: 500
seek_scaler: 1.1
feed_scaler: 1.1
motor0:
limit_neg_pin: gpio.33:high:pd
limit_pos_pin: NO_PIN
limit_all_pin: NO_PIN
hard_limits: false
pulloff_mm: 2
standard_stepper:
step_pin: i2so.1
direction_pin: i2so.2
disable_pin: i2so.0:low:pu
y:
steps_per_mm: 640
max_rate_mm_per_min: 1200
acceleration_mm_per_sec2: 39
max_travel_mm: 130
soft_limits: true
homing:
cycle: 1
positive_direction: true
mpos_mm: 0
feed_mm_per_min: 300
seek_mm_per_min: 1000
settle_ms: 500
seek_scaler: 1.1
feed_scaler: 1.1
motor0:
limit_neg_pin: NO_PIN
limit_pos_pin: gpio.32:high:pd
limit_all_pin: NO_PIN
hard_limits: false
pulloff_mm: 3
standard_stepper:
step_pin: i2so.4:low
direction_pin: i2so.5
disable_pin: i2so.3:low:pu
z:
steps_per_mm: 640
max_rate_mm_per_min: 800
acceleration_mm_per_sec2: 25
max_travel_mm: 150
soft_limits: true
homing:
cycle: 1
positive_direction: true
mpos_mm: 0
feed_mm_per_min: 300
seek_mm_per_min: 900
settle_ms: 500
seek_scaler: 1.1
feed_scaler: 1.1
motor0:
limit_neg_pin: NO_PIN
limit_pos_pin: gpio.22:high:pd
limit_all_pin: NO_PIN
hard_limits: false
pulloff_mm: 10
standard_stepper:
step_pin: i2so.7:low
direction_pin: i2so.8
disable_pin: i2so.6:low:pu
probe:
pin: gpio.35:low
toolsetter_pin: NO_PIN
check_mode_start: true
hard_stop: true
arc_tolerance_mm: 0.002
junction_deviation_mm: 0.010
verbose_errors: false
report_inches: false
enable_parking_override_control: false
use_line_numbers: false
planner_blocks: 16
i2so:
bck_pin: gpio.25
data_pin: gpio.27
ws_pin: gpio.26
spi:
miso_pin: gpio.19
mosi_pin: gpio.23
sck_pin: gpio.18
sdcard:
cs_pin: gpio.5
card_detect_pin: gpio.34:low
control:
safety_door_pin: NO_PIN
reset_pin: NO_PIN
feed_hold_pin: NO_PIN
cycle_start_pin: NO_PIN
macro0_pin: gpio.4:pu:low
macro1_pin: NO_PIN
macro2_pin: NO_PIN
macro3_pin: NO_PIN
fault_pin: NO_PIN
estop_pin: NO_PIN
macros:
macro0: $SD/Run=lasertest.gcode
macro1: $SD/Run=home.gcode
coolant:
# Heated Bed Terminal Block
flood_pin: i2so.16
# HE0 Terminal Block
mist_pin: i2so.17
delay_ms: 0
user_outputs:
analog0_pin: NO_PIN
analog1_pin: NO_PIN
analog2_pin: NO_PIN
analog3_pin: NO_PIN
analog0_hz: 5000
analog1_hz: 5000
analog2_hz: 5000
analog3_hz: 5000
digital0_pin: NO_PIN
digital1_pin: NO_PIN
digital2_pin: NO_PIN
digital3_pin: NO_PIN
start:
must_home: true
#PWM:
#pwm_hz: 5000
#direction_pin: NO_PIN
#output_pin: gpio.32
#enable_pin: gpio.27
#disable_with_s0: false
#s0_with_disable: true
#spinup_ms: 0
#spindown_ms: 0
#tool_num: 0
#speed_map: 0=0.000% 10000=100.000%Startup Messages
$Report/Interval=50
$G
[MSG:INFO: websocket auto report interval set to 50 ms]
ok
<Alarm|MPos:0.000,0.000,0.000|FS:0,0|WCO:330.300,-105.300,-109.600>
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0]
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0]
ok
<Alarm|MPos:0.000,0.000,0.000|FS:0,0|Ov:100,100,100|A:>
$ss
[MSG:INFO: FluidNC v3.7.17 https://github.com/bdring/FluidNC]]
[MSG:INFO: Compiled with ESP32 SDK:v4.4.4]]
[MSG:INFO: Local filesystem type is littlefs]]
[MSG:INFO: Configuration file:Bees_active.yaml]]
[MSG:ERR: ERR: i2so.0:low:pu - Unsupported I2SO option 'pu]
y:
steps_per_mm: 640
positive_direction: true
mpos_mm: 0
[MSG:INFO: UART1 Tx:gpio.17 Rx:gpio.16 RTS:NO_PIN Baud:1000000]]
[MSG:INFO: uart_channel1 created at report interval: 75]]
[MSG:INFO: I2SO BCK:gpio.25 WS:gpio.26 DATA:gpio.27]]
[MSG:INFO: SPI SCK:gpio.18 MOSI:gpio.23 MISO:gpio.19]]
[MSG:INFO: SD Card cs_pin:gpio.5 detect:gpio.34:low freq:8000000]]
[MSG:INFO: Stepping:I2S_stream Pulse:4us Dsbl Delay:200000us Dir Delay:2us Idle Delay:250ms]]
[MSG:INFO: Axis count 3]]
[MSG:INFO: Axis X (0.000,465.000)]]
[MSG:INFO: Motor0]]
[MSG:INFO: standard_stepper Step:I2SO.1 Dir:I2SO.2 Disable:NO_PIN]]
[MSG:INFO: X Neg Limit gpio.33:pd]]
[MSG:INFO: Axis Y (-130.000,0.000)]]
[MSG:INFO: Motor0]]
[MSG:INFO: standard_stepper Step:I2SO.4:low Dir:I2SO.5 Disable:I2SO.3:low]]
[MSG:INFO: Y Pos Limit gpio.32:pd]]
[MSG:INFO: Axis Z (-150.000,0.000)]]
[MSG:INFO: Motor0]]
[MSG:INFO: standard_stepper Step:I2SO.7:low Dir:I2SO.8 Disable:I2SO.6:low]]
[MSG:INFO: Z Pos Limit gpio.22:pd]]
[MSG:INFO: macro0_pin gpio.4:low:pu]]
[MSG:INFO: Kinematic system: Cartesian]]
[MSG:INFO: Connecting to STA SSID:Dockingbay94]]
[MSG:INFO: Connecting.]]
[MSG:INFO: Connecting..]]
[MSG:INFO: Connected - IP is 192.168.50.40]]
[MSG:INFO: WiFi on]]
[MSG:INFO: Start mDNS with hostname:http://fluidnc.local/]]
[MSG:INFO: SSDP Started]]
[MSG:INFO: HTTP started on port 80]]
[MSG:INFO: Telnet started on port 23]]
User Interface Software
Web Ui, also G sender
What happened?
I had problems getting the .yaml file setup to make the mill move. At first all the CNC would do nothing trying to jog. I had no limit switches set up at that time. I could double click on a movement and it would move but not consistently. Sometimes when choosing 30mm jog it would move with one click. I worked on the stepping: section setup to my external controller specs and that seemed to help but did not resolve the issue. I tried many things and the one that seemed to work was the disable_pin: set to :low and :pu.
Having "pu gives me at startup error but without it jogging or now that I have endstops homing doesn't work.
If I have only one axis with :pu and not on the others only the axis with "pu will Jog.
The CNC mill will run gcode and cut parts as expected. Over the last couple weeks I needed to make hundreds of profile cuts on parts and the code runs fine. Every time I start it up I just have to clear the start error in the "Tablet" tab >menu>Reset then Unlock.
Controller manual pdf link.
One option presented on Discord was to leave the enables unconnected on the drivers. Will this limit an E-stop function?
GCode File
No response
Other Information
No response
Does the motor enable and disable work with $ME and $md?
See this page.
http://wiki.fluidnc.com/en/support/setup/motion
Do you have a link to your schematics?
Once reset and unlocked $me and $md shows all motors enabled and disabled in the commands screen. There is no change in the jogging movements with either $me or $md on an axis with :pu in the config file. I tried it with a config that has no :pu and there is no response. There is a slight click from a motor and I can feel the motor coupler move a little. This noise seems to be there anytime a motor should start moving but it does not. In a config with X axis has :pu Y and Z do not, the X axis will jog as expected but not Y or Z.
Perhaps These Cl86T controllers are not as compatible as others? I did a drawing showing the 4 pin external stepper header on the MKS tinybee board connected to the all - negitive pins connected to GND. STP+ connected to PUL+, Dir to DIR+ and En to ENA+
I did just disconnect the ENA+ and - from each driver. disable_pin: I2soxxx:low(:pu) was taken out of the config for all 3 axis and the motors move as expected.
You probably need to omit :low on the disable pins. Most external stepper drivers will disable when an active signal s applied to the ENA+- signal pair. Yes I know that is contrary to what the name ENA would imply, but it is what it is. No power, which is the same as ENA+- left unconnected, results in enablement, whereas current going through the ENA optocoupler means disable.
With :low on the disable pin, the controller output pin will be low when the controller wants to disable, and high when the controller wants to enable. Controller disable i.e. pin low, with the pin connected to ENA+ and ENA- grounded, means no current flows because both ENA+ and ENA- are at low/ground level, hence no current flows, hence the driver is enabled when the controller wants it disabled, and vice versa.
What may have been happening is that the erroneous ":pu" designation was causing the ":low" to be ignored, thus leaving the pin in the correct sense where controller disable causes pin high - and thus current flows from pin high to ground and thus driver is disabled when the controller thinks it should be.
Mitch than you for the reply. I was pretty sure that was a configuration I had already tried. I tried it again trying to note every step. Omitting :low from the disable pin did not work. I had the ENA+- wires removed. I homed the machine with the config :low and it moved as expected. Then restarted after loading the config omitting :low. I hooked up the x axis ENA+- wires and the X axis will not move( I do see the movement code in the commands box) but the other two do move when jogging
With low omitted from the disable pin I get 4.9v at the ENA+ pin /wire I added :low:pu to the Y axis pin and have about 0 volts at the ENA+ pin/wire. I then added the :low back into the last axis and checked it about 3.5v. So the only way to have 0 volts is to have :low:pu in the disable pin, or just have the wires disconnected. I'm wondering if an external 10k resistor will work but still allow the board to go High and disable them for Estop reasons. I'll see what I can test on that.
edit: with more testing I had some very erratic movements. I think it was the closed loop steppers trying to catch up for missed steps. I one case X moved in the wrong direction more rapidly than I have homing or moving speeds. The controller shut movement down and flashed it's red light. I tried the config omitting :low and :pu and added a 10k resistor. I got movement but it seemed a bit delayed.
I'm thinking this is a stepper controller specific problem and not the MKS board or FluidNC. I think some of the erratic movements I've had when testing is closed loop steppers trying to make up lost steps. The cause of these lost steps is the stepper controllers not seeing a clear 0 or 5v signal. Is my stepping"disable_delay_us: 200000" 200,000 micro seconds ok? the controller calls for 200 milliseconds but the config has it listed in microseconds. Is it being over the 0-10 value range ok or a possible problem?
I'm thinking I will just run it without the ENA wires connected. At least until I can check it with a better DVM. Maybe a 5k resistor depending on what I see if the 10K was not pulling the voltage low quick enough. If you think I'm off track with this line of thinking let me know. Thanks
The I2SO signals source and sink current. That means it can drive a load in the high or low state. An resistor is not needed for either the high or low states. In fact the high and low signals are strong enough to negate the effect of pulling resistors. The CL86T has opto isolators. It is unlikely a pulling resistor could supply enough current to activate them.
You often mention :low and :pu together, but they are separate and unrelated parameters. You only want to try the :low parameter.
You mentioned you tested $ME and $MD "shows all motors enabled and disabled in the commands screen". You must test by trying to rotate the motors in both cases. The command response text is only correct if your config file is correct.
Thank you for the further information on how the I2SO signals with the opto isolater. My thinking with the polling resistor was to help drop the signal low in the case that the voltage was not being a strong low or high signal. That was so to the various villages I was seeing. I will plan on getting a volt meter/osilicope and leads that I can better see what the voltages are doing real time and not holding leads in place.
The only reason I was mentioning :low and :pu together is that was the combination that my mill would operate with after the start error was cleared with the reset> unlock.
I will retest the $ME $MD commands. Thanks
There should be no floating, because the opto LED requires current.
When you add :pu to an I2SO pin the resulting configuration error means that we cannot guess what is happening on that pin.
The Tinybee schematic which is linked from the FluidNC Wiki Tinybee page shows that there are resistors between the I2SO outputs and the 4-pin external stepper connectors. As with most MKS schematics, the resistor values are not shown, but I measured the value on a Tinybee board at 100 ohms. That will reduce the current available to trigger the optocouplers on the external stepper drivers, but probably not by enough to cause problems. It should not affect the enable signal, because you must supply current to disable, and not enough current will result in the driver being enabled.
At this point we have spent a lot of uncompensated time helping you debug a problem that we cannot reproduce, using a low-cost controller that was sold by someone else. Perhaps you should just leave the ENA unconnected, since that seems to work, and make progress on other fronts. There is little downside to not being able to disable the drivers individually from software. It is typically not a safety problem, since a driver will stop moving as soon as the pulse train stops. In fact it will stop faster when enabled than when disabled. Disabling a driver can save some power and heat, but closed loop drivers are usually pretty good at lowering the current automatically when it is not necessary. Disabling a driver can also let you move the axis manually, but that can be done by cutting power. On some machines, a disabled driver can be a hazard because it can let a Z axis fall, and a disabled driver can cause loss of accurate position on some other machines.
I found this diagram in a CL56T manual
It shows 300 ms delay, not 200 ms. That is a long time for the FluidNC code to wait during the part of the code where that delay is applied, possibly resulting in loss of communications and other software problems. I don't think we can support this long of an enable delay, so leaving ENA unconnected is the way to go.
Thank you both for the wealth of information you provided. I did make a donation to the project before sending this reply. 300 milliseconds is almost 1/3 second. Quite a long time considering the other timings involved. The 200 comes from the remarks a) below that diagram saying ENA must be at least 200 milliseconds ahead of DIR. These numbers seem way higher than any of the examples in the Wiki so it may be unique to this controler.
I will plan on leaving ENA unconnected. My Z motor is oversized, being the largest Nema 34 at 12Nm. It should hold Z with no problems. I may look into things more later on my own. lf by chance I have any other useful information that may help others troubleshoot I will send that along on discord.
I use CL86T V3.0 and V4.0 closed loop drivers and can confirm as Mitch has noted, you do need a long delay after enabling the drivers (i.e. cutting current to the enable opto coupler) before requesting any motion. In your config, idle_ms is set at 250, so the drivers will stay enabled while a file is run, but could disable between jogging events (i.e. any gap in commands longer than 1/4 of a second). If the enable line is wired up for fluidNC control, I find setting idle_ms: 255 is needed to prevent normal timed driver disabling as the CL86T wakeup time is too slow and odd 'bangs' and position loss can happen otherwise when the first commands are sent (my motors hardly get warm if left on). My CL86T's are run via a transistor buffer from the I2SO chip. I have tried running the drivers direct from an ESP32 i/o pin for testing, but had no luck and needed an external transistor to drive the opto's reliably on both the 3.0 and 4.0 driver versions (I do not have any 4.1's to try unfortunately). Evan
Evan, thank you very much for that reply! I will set the delay to 255 as you do. I didn't know what time 250 = but figured it wouldn't power down in normal use but would if I forgot and left it on. Setting it at 255 won't be a problem.
I will research more on that transistor buffer and will consider that if it seems needed going through the board vs direct from the ESP32.
The spec says that the inputs are rated for 5-24V and the timing diagram says that at least 3.5V is necessary. Many optos will work at 3.3V volts, but the fact that this device allows up to 24V suggests that it has a relatively large series resistor, so the current at 3.3V is probably marginal.
If you leave ENA unconnected, it does not matter what idle_ms is set to. idle_ms controls how long FluidNC waits after motion before disabling the motors, with 255 meaning "never disable". If the ENA signal is not connected, the driver will never see the disable signal.
My guess is that this driver has some sort of software sleep mode that is controlled by ENA, and it takes a few hundred milliseconds to exit from that mode. That is very unusual. Most drivers respond to ENA within a very few microseconds.
Changing FluidNC to handle enable delays in the hundreds of milliseconds range would be a fair amount of work.
Re holding Z, so long as the motor can move the Z axis at the rate you want, it can easily hold it statically. The problem is not the motor size, but rather the fact that, if the motor is unpowered, it cannot hold anything, so you would depend on friction to prevent the axis from dropping. Fine-pitch lead screws sometimes have enough friction, while ball screws often do not. If you have a self-dropping Z axis, you need some way to keep it from crashing down when power is off.
There is a switch for 5v or 24v inputs on the CL86T 4.1 controller.
For the unpowered motor the detent torque is quite high. That notching movement of the motor shaft when powered off is easily enough (in my case) to hold the Z up with a 5mm pitch ballscrew. I went with the bigger option motor for Z becauseof this. It wasn't much more money and the height and weight didn't matter. As it would on X and Y. I used this detent torque feature on some Custom 3D printers to hold the bed up with the motors unpowered by simply using bigger ones than needed to move the bed. It won't hold micro stepping for either the mill or printers case but it won't let the Z just drop on an unpowered motor like e stop or power outage. Thanks again for all the great info.
I use ULN2003 chips (7-transistor array, open collector) in my controller design to drive the opto's of the CL86T from an ESP32 (i.e. the enable line, but also pulse and direction). There are breakout boards available that have a ULN2003 on them and then rows of solder pins that may provide a practical solution.
If you can work with leaving the enable lines disconnected, and then powering down the machine to disable the motors, that is certainly the simplest solution, and not that much different to having the enable line under software control for when running with the motors normally always active. The CL86T's are probably not common enough to warrant changing the code to support a really long enable delay; as they seem to power manage well when static, if anything, an note in the Wiki may be the most that is needed to say that for CL86T's, just leave them on!
On my machine, I have a 3kW spindle and the coolant pump runs-on for about 5 minutes after I stop cutting to remove any residual heat in the spindle. Often when I mess-up and am in a situation where I need to disable the motors to manually turn the drive shafts, it is just after doing a cut and the spindle coolant is still running. The coolant is on the same supply as the motors, so cutting the power also stops the coolant through the spindle. I am too impatient to wait until the coolant run ends, so need a separate way of disabling the motors. Rigging an independently wired manual switch to the enable lines is an option that can work well that I have used in the past. I have the machine configured now so that the motors are permananently on (idle_ms at 255), but I can use $MD/$ME from my laptop, and I also have a switch wired in parallel on the ENA line at the CNC itself so can also disable the motors from there too. I just make sure I leave a couple of seconds between enabling the motors and then commanding them to move.
Evan thank you again for that information. Great to hear from someone running the CL86T drivers and their unique specifics.
I agree with your comment of no need to change the code for this. Leave them on.
I for now ENA+ will stay disconnected as I work on others areas of the mill. I hope to explore some more options in the future. For the ULN2003chip you mentioned. I came across that before as I was researching what problem I was encountering. I didn't know the source of my issue was at the time. In the future I'll consider an improvement to the motor control. Perhaps a manual switch as you mentioned. It would be easy to add.
In this case it is highly unlikely that a ULN2003 will help. The 5V output from a Tinybee meets the CL86T driving specs. The crazy-long enable time delay is the likely culprit here.
Right, he did say it was from an ESP32 that would be only 3.3v
Just out of interest, I put my current meter on the opto-coupler inputs of the CL86T's I have (it is something I should have done before designing my CNC controller really, whoops!). The V3.0 units are specified as only a 5V option for the drive signals and the V4.0 units I have have a 5V or 24V switch option (like the V4.1). I powered each of the units on just in case there was any additional electronics between the pulse, direction and enable inputs and the opto-couplers that could influence the current that would be drawn from a control card (it made no difference to the devices being powered off in practice). The results were interesting, and certainluy explain why I could not drive the CL86T direct from an ESP32.
For the V3.0 units I have (I tested 5 for consistency), the pulse and direction inputs take between 16.8 and 17.3mA each from the 5V driver line, but the enable signal only needs between 11.6 and 12.1 mA. For the V4.0 unit (3 tested to get a spread of results), the pulse and direction lines take between 11.7 and 12.1 mA each, and the enable line only needs between 6.1 and 6.3mA. The pulse line will of course only be on for part of the time, so the average current drawn from a pin will be less, but any controller drive pin must still be able to source enough current reliably in order to trigger a pulse. The direction pin may take no current, or a continuous current, depending on which way the machine is moving.
Assuming that the latch chips on the I2SO in the TinyBee are 74AHCT595's, the TI and other data sheets recommend up to 8mA drive per pin, but the chips are stated as being able to sink/source up to 20mA per pin, with a limit of 50mA or 75mA total max per chip (depending on who the manufacturer is). The TinyBee circuit shows enable, step and direction of X, Y and the enable and step of Z all off U1. For using CL86T's, only one enable is needed for all, but the step and direction lines are required. So driving a machine using a set of V3 CL86Ts would be pushing the limits of the chip for some maching directions. Running a machine using all V4.0s (and I suspect the V4.1 is the same current draw as the V4.0) should be ok, but it will still be sourcing/sinking 50% more current per pin than the recommended design level. The TinyBee should therefore just about drive a machine based on CL86Ts directly from the I2SO chip outputs, but a ULN2003 or two would certainly take the pressure off and make the overall CNC design more reliable (EMC issues usually become more problematic when devices are pushed to their limits).
Evan
ENA and PUL are not continually high at the same time. If ENA is high, PUL will be low. If ENA is low, PUL will be on for at most 50% of the time, and typically much less than that. The worst case as far as the '595 is concerned is when ENA and DIR are both continually high, as when the motors are disabled but the previous directions are all at the state where DIR is high.
Sinking current is not an issue with the common minus wiring. Optocouplers cannot supply current into the output pin in that configuration.
If you want to drive V3.0 units, you could add 300 ohm resistors in series with the optocouplers. That would reduce the current to about half its present value. Optocouplers are nearly always much more sensitive than their worst-case ratings so they will "trigger" with currents down in the 5 mA range. It is not unusual for them to trigger at less than half a milliamp, depending on the circuit on the output side.
Optocouplers as used in stepper driver applications are not precision devices.
Mitch, yes the 300 ohm resistor is a good option and as you say, the opto's used in external drivers are designed to tolerate a wide range of signals. I think I have spent too many decades designing for high EMI environments and so naturally go for the higher-current/ high-voltage solutions!
Thank you both for the help. I updated the title to help make it more retentive to the issue. If you have a better suggestion to make it more searchable for someone using the CL86T drivers let me know.
Can we close the issue?