Sensing Pulses from dual Y-axes

Basically my re-animated Stepcraft CNC is working.

Homing of the dual Y-axis is working, too.

Therefor the start point is synchronized.

During moving the portal, the two axis are getting out of synch. I do not know the cause, either missing pulses or just plain mechanics.

The two Y-axis do have magnetic indicators used together with hall sensors to count pulses per revolution.

Question: Do you consider an enhancement in that direction, using feedback pulses to synchronize the two axis during movement?

In the moment I am thinking about a separate µC to act like a digital "Phase Locked Loop", counting the pulses and suppress pulses from the faster axis.

If I am successful, I can share that solution.

In the moment I do not have the time to dig into your software to find the right place for this.

It will be a "standalone solution".

Kind regards Klaus P. Stock

Using closed-loop feedback to "force fix" an underlying problem is unwise, like applying more force to turn a cross-threaded screw. In the long term, it will overstress the problem area and cause it to fail.

You need to fix the underlying problem. You did not give us enough information to do a good job of helping you - which Stepcraft machine, photos of its mechanical system, which controller you are using for FluidNC, stepper driver details, config file contents, etc. If I knew that I could give more precise suggestions. Without that information I can only give vague suggestions.

Some external stepper drivers need long step pulses, otherwise they will sometimes miss pulses. FluidNC's stepping: pulse_us: parameter sets the length of the step pulse in microseconds. Try increasing that value.
There could be a problem with a stepper driver, a stepper motor, or the wiring. Try swapping the cables from the controller to external drivers, the cables from drivers to motors, etc, to see if the "racking" (misalignment) changes from one side to the other.
Try running at different speeds to see if there is a speed below which racking does not occur. Steppers develop more torque at lower speeds, so racking at higher speeds could indicate mechanical problems with one side or the other.
Check the alignment and lubrication of the bearings. I believe that Stepcraft machines have roller bearings. If one side is misaligned or the bearings are not rolling well, it could make it harder for that side to move.
Check the alignment of the lead screw nut. If it is misaligned the lead screw could bind at some places along the travel length.
Check that the lead screw can turn freely all along the length of the screw. To do that it might be necessary to disconnect the gantry and test each side separately.
Check for loose shaft couplers or pulleys. If a coupler is slipping on its rod, it will not transmit torque reliably.

If the system components are all working properly, the machine will not rack.

Since you did not tell us which Stepcraft machine you have, I do not know if this is relevant, but ... The Stepcraft D-series machines that are shown in some Stepcraft installation videos have only one Y motor. The two screws are driven by a belt and pulley system along the back of the machine. If a machine like that is racking, the problem must be mechanical.

Good morning Mitch,

thank you for the reply.

You are right, the basic D-series do use one motor and a belt to drive the second axis.

In addition they sell a "performance kit" providing a second motor and couplings with six magnets per revolution.

the magnets are embedded in the aluminium part of the coupling.

I didn't know about these when ordering the missing parts, because it is not mentioned either in the videos nor the documentation.

Anyhow, I am trying to get the necessary hall sensors and solve that problem.

Kind regards Klaus P. Stock

On 2022-04-13 20:13, Mitch Bradley wrote:

Since you did not tell us which Stepcraft machine you have, I do not know if this is relevant, but ... The Stepcraft D-series machines that are shown in some Stepcraft installation videos have only one Y motor. The two screws are driven by a belt and pulley system along the back of the machine. If a machine like that is racking, the problem must be mechanical.

-- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: @.***>

Links:

[1] https://github.com/bdring/FluidNC/issues/374#issuecomment-1098343887 [2] https://github.com/notifications/unsubscribe-auth/AYTKUV7QMP6WZLLOOAJUSCDVE4FEPANCNFSM5TJWP5OQ

-- Klaus P. Stock Stock & Partner Advanced Education GmbH

Good morning Mitch,

I agree, I didn't provide enough details.

My question was ment more general, because I think I am not the only one using two separate motors.

Anyhow, as I mentioned in an earlier request, my hardware is similar to the 6 pack hardware, just a different form factor, euro 160mm x 100mm.

And yes, like Münchhausen pulling himself out of the swamp with his own hair, the first project should be a contour milled PCB for the electronics replacing the haywiring.

The machanical problems you mentioned I think I managed them properly. I am an educated mechanic.

The elctronics are build aroundthe ESP32 Wroom UE, TMC2209 stepper drivers, 1,5A stepper motors with 200 steps per revolution - 8 fine steps, I2S with 74xxx595 (which I know since the early 70s).

My idea is to use a separate µC, checking the two step outputs for equalty, checking the two hall sensors for equalty and based on the result, suppress pulses for the faster axis. I did something like this many years ago.

I am not sure if the FluidNC is able to handle this in the moment.

And as I mentioned earlier, too, I don't have enough time in the moment to dig into the source code.

I will keep you informde about any progress. In the moment I am waiting for the hall sensors.

But I can start thinking ;-))

Kind regards Klaus P. Stock

On 2022-04-13 19:49, Mitch Bradley wrote:

Using closed-loop feedback to "force fix" an underlying problem is unwise, like applying more force to turn a cross-threaded screw. In the long term, it will overstress the problem area and cause it to fail.

You need to fix the underlying problem. You did not give us enough information to do a good job of helping you - which Stepcraft machine, photos of its mechanical system, which controller you are using for FluidNC, stepper driver details, config file contents, etc. If I knew that I could give more precise suggestions. Without that information I can only give vague suggestions.

Some external stepper drivers need long step pulses, otherwise they will sometimes miss pulses. FluidNC's stepping: pulse_us: parameter sets the length of the step pulse in microseconds. Try increasing that value.

There could be a problem with a stepper driver, a stepper motor, or the wiring. Try swapping the cables from the controller to external drivers, the cables from drivers to motors, etc, to see if the "racking" (misalignment) changes from one side to the other.

Try running at different speeds to see if there is a speed below which racking does not occur. Steppers develop more torque at lower speeds, so racking at higher speeds could indicate mechanical problems with one side or the other.

Check the alignment and lubrication of the bearing. I believe that Stepcraft machines have roller bearings. If one side is misaligned or the bearings are not rolling well, it could make it harder for that side to move.

Check the alignment of the lead screw nut. If it is misaligned the lead screw could bind at some places along the travel length.

Check that the lead screw can turn freely all along the length of the screw. To do that it might be necessary to disconnect the gantry and test each side separately.

Check for loose shaft couplers or pulleys. If a coupler is slipping on its rod, it will not transmit torque reliably.

If the system components are all working properly, the machine will not rack.

-- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: @.***>

Links:

[1] https://github.com/bdring/FluidNC/issues/374#issuecomment-1098324125 [2] https://github.com/notifications/unsubscribe-auth/AYTKUV6U4IDD7VCTTUCTSEDVE4CKNANCNFSM5TJWP5OQ

-- Klaus P. Stock Stock & Partner Advanced Education GmbH

board: 6 Pack lookalike name: 6 Pack StepStick XYZABC stepping: engine: I2S_STREAM idle_ms: 250 pulse_us: 4 dir_delay_us: 1 disable_delay_us: 0

axes: shared_stepper_disable_pin: NO_PIN x: steps_per_mm: 533.333 max_rate_mm_per_min: 600.000 acceleration_mm_per_sec2: 5.000 max_travel_mm: 400.000 soft_limits: false homing: cycle: 2 positive_direction: false mpos_mm: 0.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: gpio.32:low
  limit_pos_pin: NO_PIN
  limit_all_pin: NO_PIN
  hard_limits: false
  pulloff_mm:5.000
  stepstick:
    direction_pin: i2so.0
    step_pin: i2so.1
    ms1_pin: NO_PIN
    ms2_pin: NO_PIN
    ms3_pin: NO_PIN
    disable_pin: i2so.3

y: steps_per_mm: 533.333 max_rate_mm_per_min: 600.000 acceleration_mm_per_sec2: 5.000 max_travel_mm: 500.000 soft_limits: false homing: cycle: 2 positive_direction: false mpos_mm: 0.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: gpio.33:low
  limit_pos_pin: NO_PIN
  limit_all_pin: NO_PIN
  hard_limits: false
  pulloff_mm:5.500
  stepstick:
    direction_pin: i2so.4
    step_pin: i2so.5
    ms1_pin: NO_PIN
    ms2_pin: NO_PIN
    ms3_pin: NO_PIN
    disable_pin: i2so.7

motor1:
  limit_neg_pin: gpio.35:low
  limit_pos_pin: NO_PIN
  limit_all_pin: NO_PIN
  hard_limits: false
  pulloff_mm:4.500
  stepstick:
    direction_pin: i2so.8
    step_pin: i2so.9
    ms1_pin: NO_PIN
    ms2_pin: NO_PIN
    ms3_pin: NO_PIN
    disable_pin: i2so.11

z: steps_per_mm: 533.333 max_rate_mm_per_min: 600.000 acceleration_mm_per_sec2: 5.000 max_travel_mm: 300.000 soft_limits: false homing: cycle: 1 positive_direction: true mpos_mm: 0.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: gpio.34:low
  limit_pos_pin: NO_PIN
  limit_all_pin: NO_PIN
  hard_limits: false
  pulloff_mm:1.000
  stepstick:
    direction_pin: i2so.12
    step_pin: i2so.13
    ms1_pin: NO_PIN
    ms2_pin: NO_PIN
    ms3_pin: NO_PIN
    disable_pin: i2so.15

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

control: safety_door_pin: NO_PIN reset_pin: NO_PIN feed_hold_pin: NO_PIN cycle_start_pin: NO_PIN macro0_pin: NO_PIN macro1_pin: NO_PIN macro2_pin: NO_PIN macro3_pin: NO_PIN

coolant: flood_pin: NO_PIN mist_pin: NO_PIN delay_ms: 0

probe: pin: NO_PIN check_mode_start: true

macros: startup_line0: startup_line1: macro0: macro1: macro2: macro3:

start: must_home: false

PWM: pwm_hz: 5000 output_pin: NO_PIN enable_pin: NO_PIN direction_pin: NO_PIN disable_with_s0: false s0_with_disable: true spinup_ms: 1000 spindown_ms: 1000 tool_num: 0 speed_map: 0=0.000% 1000=100.000%

Many people use separate motors, but after-homing racking problems are so rare that nobody else has reported it.

What is common, however, is

Electrical problems with "haywired" I2S systems. Shift registers are susceptible to false clocking from poor signal quality - and "haywiring" often has very poor signal quality. In the 6 pack design, we paid very careful attention to signal and ground wiring to ensure clean edges without ringing.
Configuration / tuning problems with TMC drivers. If the parameters are not set exactly right, TMC drivers can cut out at seemingly random times. We respond to TMC driver config problems every few days. They often present as jerky motion or intermittent stalls, which could easily explain your racking problem.

Applying closed-loop correction to a system with fundamental step-loss problems will not result in smooth motion. You must fix the problem at the source. If you have an engine that is misfiring, you might be able to get from point a to point b with human correction, but the trip will not be pleasant.

FluidNC is fundamentally designed for open-loop operation with stepper motors that are assumed to be reliable. There is no simple way to convert it for closed-loop operation. Instead of going down a difficult path that will not fit well with the overall system design, you need to discover exactly why the motors are not staying synchronized. The two possibilities that I mentioned above are high-probability failure modes.

bdring / FluidNC

Sensing Pulses from dual Y-axes #374

Links:

Links: