Closed AlexMoiseevs closed 10 months ago
The 6 Pack uses gpio.16
for one of the modules. how are you using it for shared_stepper_disable
?
Each motor connector has its own disable.
Where or what is the wild over current?
the controller board has its own. a4988 drivers.I tried managing the disable_pin output of each driver separately via i2so.n and via shared_stepper_isable_pin all at once. the result is the same. at the time of loading, the program immediately allows the drivers to work, the state of the pins step_pin: direction_pin: undefined, which leads to uncontrolled connection of the windings by the motor. and as a result, a large incomprehensible current up to a short circuit. the labotatory power supply cuts off at 5 amperes. The problem is solved simply: do not send a permission signal to the motors until the alarm is reset. but how to do it?
I2so drivers do not have a determinate state at turn on. You might be able to use the output enable of those chips to control the turn on.
I think you need a bigger power supply. The a4988 drivers should not be able to do that in any mode. Does it work with less motors connected?
assembled according to this scheme. the current is 5 amperes at 12 volts. the problem is at the time of download . then everything works. the current does not exceed 0.5 amperes. when 3 motors are running. is there any way to turn off the motor at the initial stage of loading?
I have tested the board with (6) 3.5Amp drivers. It works fine the the power supply can handle it. I think you are trying to temporarily solve a problem that will likely always occur under various conditions.
You could use an external pulling resistor on a GPIO pin. Be sure to pick a GPIO pin that does not have any turn on pulses.
GPIO_NUM_16 Will it do?
" I think you are trying to temporarily solve a problem that will likely always occur under various conditions." That's great! What's the problem? is there such a problem? Maybe this one: Startup States I have not found good documentation on this, but often I seen outputs turn on while the firmware boots. This is typically fraction of a second. A pull down on the I2S_BCK line appears to help but is not foolproof. Be careful about what you control with this outputs.
I would try a more robust power supply. You are probably going to need one anyway. I suggest using at least 10A.
The i2so issue has not been a problem when used with stepper motor signals.
there are also 15 amps. he'll just burn the drivers. It's not about the power supply. the problem has been identified: at the time of loading, the state of the 74hc595n pins is chaotic with a high frequency. the driver tries to execute these commands with a high frequency, which leads to a violation of the "dead time" of the driver itself. the program, when loaded, gives a shared_stepper_isable_pin signal to allow the drivers to work (why when nothing else can work?) which leads to overloads. Solution: do not give the "enabled" signal until the alarm is removed. is there such a possibility in the settings?
Send a picture of your controller
Why if it's not a secret?
74AHCT595s can be very sensitive to signal integrity problems. On Bart's boards, we were very careful with the PCB layout, ensuring that the trace routing was clean and that every signal in the I2S chain is paired with a nearby ground path back to the driving pin, without stubs that can cause reflections and undershoot. If you do not do that, you can easily get false triggering. Electrical engineering is more complicated that just connecting wires from point A to point B, especially for high speed signals.
thanks . I'm aware of that. there are no problems with the operation of the registers. there is a problem with the download. one more time: do not give the "enabled" signal until the alarm is removed. is there such a possibility in the settings?
no
and how to solve this problem? of course, you can use crutches like "alarm_pin" instead of "shared_stepper_isable_pin"... or to delay the power supply of the drivers... How does it work for you?
We don't have the problem with any of our boards. Their I2SO outputs do not rattle around. We do not provide free support for custom-built boards.
Their I2SO outputs do not rattle around. Startup States I have not found good documentation on this, but often I seen outputs turn on while the firmware boots. This is typically fraction of a second. A pull down on the I2S_BCK line appears to help but is not foolproof. Be careful about what you control with this outputs....... contradict yourself.
This my last post on this thread.
I mentioned that issue earlier in this post. We are not contradicting ourselves.
I have not seen values oscillate. I see some pins turn on in the on state, but they do not oscillate. They do not cause any problems. For some active low devices a low impedance connection to ground just as bad as a high.
I gave you a possible solution earlier. The chip has 3 state pins. It has an output enable circuit using the !OE pin. If that pin is high, all output pins go into a high impedance state. Use a resistor to pull that pin high and connect it to an ESP32 pin to enable the chips. You can probably use the shared_stepper_disable_pin:
BTW: I assume you have some seriously big capacitors hiding somewhere for those drivers.
thank you. the task is to save more pins for position sensors. (a 5-axis machine with paired axles is planned).I solved this problem as follows: at the time of startup, all the pins of the 74hc595n are at a low level (before loading the ESP32) the low level is the resolution for the A4988. I inverted the I2SO.0 output using a transistor switch. everything is working fine now! ps: condencators are not a problem.
Wiki Search Terms
I searched everywhere
Controller Board
6-pack
Machine Description
test
Input Circuits
No response
Configuration file
Startup Messages
User Interface Software
No response
What happened?
I2S_STATIC configuration, if you put shared_stepper_isable_pin on the contrary, then the download goes well. but the motors do not work accordingly. if shared_stepper_disable_pin is correct, then there is a wild overcurrent when loading . how can this be avoided?
GCode File
No response
Other Information
No response