Problem: Turning on the motors when loading. What for?

[AlexMoiseevs]

Wiki Search Terms

I searched everywhere

Controller Board

6-pack

Machine Description

test

Input Circuits

No response

Configuration file

board: 6 Pack
name: 6 Pack OLED
stepping:
  engine: I2S_STATIC
  idle_ms: 255
  pulse_us: 4
  dir_delay_us: 1
  disable_delay_us: 0

i2c0:
   sda_pin: gpio.14
   scl_pin: gpio.13

oled:
   i2c_num: 0
   i2c_address: 60
   width: 128
   height: 64
   radio_delay_ms: 1000

i2so:
  bck_pin: gpio.22
  data_pin: gpio.21
  ws_pin: gpio.17

spi:
  miso_pin: gpio.19
  mosi_pin: gpio.23
  sck_pin: gpio.18

sdcard:
  card_detect_pin: NO_PIN
  cs_pin: gpio.5

axes:
  shared_stepper_disable_pin: gpio.16:low
  x:
    steps_per_mm: 100.000
    max_rate_mm_per_min: 6000.000
    acceleration_mm_per_sec2: 1000.000
    max_travel_mm: 500.000
    soft_limits: false
    homing:
      cycle: 2
      positive_direction: false
      mpos_mm: 150.000
      feed_mm_per_min: 100.000
      seek_mm_per_min: 200.000
      settle_ms: 500
      seek_scaler: 1.100
      feed_scaler: 1.100

    motor0:
      limit_neg_pin: NO_PIN
      limit_pos_pin: NO_PIN
      limit_all_pin: NO_PIN
      hard_limits: false
      pulloff_mm: 1.000
      standard_stepper:
        step_pin: i2so.0
        direction_pin: i2so.1

  y:
    steps_per_mm: 100.000
    max_rate_mm_per_min: 6000.000
    acceleration_mm_per_sec2: 1000.000
    max_travel_mm: 500.000
    soft_limits: false
    homing:
      cycle: 2
      positive_direction: false
      mpos_mm: 150.000
      feed_mm_per_min: 100.000
      seek_mm_per_min: 200.000
      settle_ms: 500
      seek_scaler: 1.100
      feed_scaler: 1.100

    motor0:
      limit_neg_pin: NO_PIN
      limit_pos_pin: NO_PIN
      limit_all_pin: NO_PIN
      hard_limits: false
      pulloff_mm: 1.000
      standard_stepper:
        step_pin: i2so.2
        direction_pin: i2so.3:low

    motor1:
      limit_neg_pin: NO_PIN
      limit_pos_pin: NO_PIN
      limit_all_pin: NO_PIN
      hard_limits: false
      pulloff_mm: 1.000
      standard_stepper:
        step_pin: i2so.4
        direction_pin: i2so.5

  z:
    motor0:
      null_motor:

Startup Messages

OK

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

[bdring]

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?

[AlexMoiseevs]

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?

[bdring]

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?

[AlexMoiseevs]

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?

[bdring]

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.

http://wiki.fluidnc.com/en/hardware/esp32_pin_reference

[AlexMoiseevs]

GPIO_NUM_16 Will it do?

[AlexMoiseevs]

" 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.

[bdring]

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.

[AlexMoiseevs]

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?

[bdring]

Send a picture of your controller

[AlexMoiseevs]

Why if it's not a secret?

[MitchBradley]

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.

[AlexMoiseevs]

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?

[MitchBradley]

no

[AlexMoiseevs]

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?

[MitchBradley]

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.

[AlexMoiseevs]

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.

[bdring]

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.

[AlexMoiseevs]

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.