Problem: Y-Axis not homing / moving correctly after upgrade from 3.5.1 to 3.6.3 #667

Try it with FluidTerm. Set $message/level=debug and then home with $hy . Show us the messages from the terminal.

This are the messages:

FluidNC v1.2.0 using COM3
Exit: Ctrl-C, Ctrl-Q or Ctrl-], Clear screen: CTRL-W
Upload: Ctrl-U, Reset ESP32: Ctrl-R, Send Override: Ctrl-O
$X
[MSG:INFO: Caution: Unlocked]
ok
$message/level=debug
ok
$hy
[MSG:DBG: Homing Cycle Y]
[MSG:DBG: Homing nextPhase FastApproach]
[MSG:DBG: Starting from 0.000,0.000,0.000]
[MSG:DBG: Planned move to 0.000,825.000,0.000 @ 400.000]
[MSG:DBG: Y2 Pos Limit 1]
[MSG:DBG: Homing limited Y2]
[MSG:DBG: Y Pos Limit 1]
[MSG:DBG: Homing limited Y Y2]
[MSG:DBG: Homing nextPhase Pulloff0]
[MSG:DBG: Starting from 0.000,20.000,0.000]
[MSG:DBG: Planned move to 0.000,19.000,0.000 @ 100.000]
[MSG:DBG: CycleStop Pulloff0]
ALARM:8
ok

You do not have pulloff_mm defined for Y so it is defaulting to 1 mm, which is apparently too small for your machine. The 1 mm pulloff move is not releasing the switch.

Ok, is there any difference between the “stepstick” definition in compare to the “standard stepper” definition?

stepstick has configurable mode select and reset pins; standard stepper does not. standard stepper is basically an external driver where everything is configured with dip switches on the driver itself.

http://wiki.fluidnc.com/en/config/axes#standard-stepper
http://wiki.fluidnc.com/en/config/axes#stepstick

Can we close this ticket now?

Give me a second, i try it right now.

Ok, i changed the pulloff to 5 mm, the machine pulls off but not symetrically. If i start the homing after that again i get the same problem with the stopping stepper and the Alarm 8. So the Problem is not solved…

Did you change the pull off for both motors on that axis?

Yes

Show your current config file.

Just send the $axes/y command. That is enough

I have changed now also the stepstick config to the standard stepper config.

I figured out a new detail of the problem. The axis, which is not homing correctly has the right idle signal state, the other axes are inverted. With the following configuration file i geht the following signal states if the machine is not moving: X = high, Y1 = high Y2 = high, Z = low.
This stayes the same even after a power cycle.

name: "ModuloController"
board: "ModuloControl V1"

stepping:
  engine: RMT
  idle_ms: 255
  dir_delay_us: 5
  pulse_us: 5
  disable_delay_us: 5
  
start:
  must_home: true
  deactivate_parking: true
  check_limits: true

axes:
  shared_stepper_disable_pin: gpio.23
  
  x:
    steps_per_mm: 400.000
    max_rate_mm_per_min: 5000.000
    acceleration_mm_per_sec2: 150.000
    max_travel_mm: 510.000
    soft_limits: true
    
    homing:
      cycle: 2
      mpos_mm: 510.000
      feed_mm_per_min: 200.000
      seek_mm_per_min: 400.000
      positive_direction: true

    motor0:
      limit_pos_pin: gpio.35:low
      hard_limits: true
      pulloff_mm: 5.000
      standard_stepper:
        direction_pin: gpio.27
        step_pin: gpio.26:high

  y:
    steps_per_mm: 400.000
    max_rate_mm_per_min: 5000.000
    acceleration_mm_per_sec2: 150.000
    max_travel_mm: 750.000
    soft_limits: true

    homing:
      cycle: 3
      mpos_mm: 750.000
      feed_mm_per_min: 100.000
      seek_mm_per_min: 400.000
      positive_direction: true

    motor0:
      limit_pos_pin: gpio.39:low
      hard_limits: true
      pulloff_mm: 2.000
      standard_stepper:
        direction_pin: gpio.32:low
        step_pin: gpio.25:high

    motor1:
      limit_pos_pin: gpio.36:low
      hard_limits: true
      pulloff_mm: 2.000
      standard_stepper:
        direction_pin: gpio.22:low
        step_pin: gpio.21:high

  z:
    steps_per_mm: 400.000
    max_rate_mm_per_min: 5000.000
    acceleration_mm_per_sec2: 150.000
    max_travel_mm: 150.000
    soft_limits: true
    
    homing:
      cycle: 1
      mpos_mm: 150.000
      feed_mm_per_min: 100.000
      seek_mm_per_min: 400.000
      positive_direction: true

    motor0:
      limit_pos_pin: gpio.34:low
      hard_limits: true
      pulloff_mm: 5.000
      standard_stepper:
        direction_pin: gpio.18
        step_pin: gpio.19:high


probe:
  pin: gpio.4:high
  
control:
  safety_door_pin: gpio.33:low
  reset_pin: NO_PIN
  feed_hold_pin: NO_PIN

relay:
  direction_pin: NO_PIN
  output_pin: gpio.5
  enable_pin: NO_PIN
  disable_with_s0: false
  s0_with_disable: true
  spinup_ms: 0
  spindown_ms: 0
  tool_num: 0
  speed_map: 0=0.000% 0=100.000% 1=100.000%

You have a shared pin that controls idle state.

axes:
   shared_stepper_disable_pin: gpio.23

It is not a problem with the firmware.

Now i erased the complete ESP and flashed it agian. Now i do not see any failures with homing and all step signals have the same idle state / polarity. But the idle state is still inverted, if i do not add :low or :high to the step pin the signal state it is HIGH if no stepper is moving and a step signal is done by pulling the pin low for 5 us. If i use :low after my step pin definition, the step signal is idle LOW and a step signal pulls the pin to high for 5us.
Now i have a new problem, if i jog the machine over 3000 mm/min i get short stops of the stepper during the movement…. I see it also in the step signals.
What has the disable pin to do with my step pins?

You said nothing about step pins…

“The axis, which is not homing correctly has the right idle signal state, the other axes are inverted”

I assumed you meant the disable signal, because that is controlled by the idle time.

There is no “idle state” signal.

Try using STA mode for the Wifi. The ESP32 AP mode is not good.

http://wiki.fluidnc.com/en/features/wifi_bt#wifi-ap-mode

Ok, with idle state i meant the signal state if no step signal is generated or if the stepper ist not moving. Now am back at the old homing problem. Here is the way i got back:

1. Upload a new config file with this line removed: shared_stepper_disable_pin: gpio.23
2. Power cycle the ESP
3. Testing, got a problem that now my steppers are disabled -> this is ok because of my hardware design.
4. Added the line shared_stepper_disable_pin: gpio.23 to the config file again to get the original config file
5. Uploaded the new config file to the ESP
6. Power cycle the ESP
7. And now i get the same homing problems again…

I try STA mode now. If this not solves my problem i am at the end with my latin how we used to say in germany….

After changing to STA mode and doing a power cycle, the homing worked again, but i get again short stops during a fast jogging movement over 3000mm/min.
Additional after the power cycle the polarity of the step signals agreed with the configuration. Because before, they where inverted i changed the config file back and power cycled the ESP.
After that, the polarity was again worng and the homing is again not working any more…..

So the change to the STA mode has changed nothing….

I am debugging this stuff the whole day now, with basically no solution, quite disappointing…

Why you closed the issue?

I thought you were done. You you want a refund?

Yes, for today i am done. But maybe someone else has the same issue?

By the way, when I said quite disappointing, I meant the situation of not to find the failure in general, not your support or the project! If thats what your question about a refund was about.

The very large amount of noise on your scope traces worries me. I can think of several possibilities:

1. The scope ground is not connected or is connected to a ground point that is very far away from the probe point.
2. The bypassing is inadequate. The schematic shows a few 470n capacitors of unknown type. A more typical value is 100n or even 10n in ceramic. As the capacitance increases, so does the self inductance, so larger values are worse for higher frequency noise. The gold standard is to have a variety of capacitors with different values, like 100u to handle low frequency noise, 100n for higher frequencies, and 10n for very high frequencies. TTL can generate impressive current spikes when it switches.
3. The grounding layout is inadequate. For grounding to be effective at high frequencies, there must be a path for return current to flow in the ground wires or plane that is physically close to the path that the signal takes, so the loop that is formed by the signal current and its associated return current is small. The impedance of the ground return must also be low enough (large traces or plane) to avoid IR voltage shifts between the ground nodes of different chips.
4. Noise could be coming in from outside components – steppers, spindles, anything else in the room – due to inadequate power line filtering, ground loops in the overall system, and many other factors. Overall system grounding and plug-in points are important. I run my spindles from separate outlets than my controllers. Separate circuits would be better but in my setup, separate outlets work. Every environment is different.

I do not know which – or any – of these problems pertain to your system. You showed us your schematic, but we haven’t seen your physical layout (PCB or otherwise), nor the overall wiring of the system (you just showed closeups, not the big picture).

Yes, the noise on the scope comes from bad grounding point of the scope-probe in the circuit (long grounding lead picks up a lot fo noise from the stepper driver). But my behaviour is comming with the change of the firmware from 3.5.1 to 3.6.3 and i measure definetly wrong signal states comming out of the ESP so this has less to do with EMC problems.
I am currently rebuilding the circuit anyway (switching to a new spindle with vfd and 0-10V control) and maybe if i am ready i can do some better measurements. If i get more information i let you know.

Just a last question, if i change / update the firmware is it correct to run the follwoing scripts on windows to get a completely clean and new installation on the ESP:

1. erase.bat
2. install-fs.bat
3. install-wifi.bat

Or is just the install-wifi.bat script needed?

I flashed https://github.com/bdring/FluidNC/releases/tag/v3.6.4-pre1 and first tests showed no problems with homing now! The signal levels of the step signals are agree with the config file too!