3.9.1 & 3.9.2pre1 – Direction not working #1389

Ahh, I think I know the problem. I’ll guess that it’s something to do with :low which is not being read. It would also explain the weird behaviour with door switch and macro button.

The direction is being read. You can see it in your start messages.

[MSG:INFO: safety_door_pin gpio.33:low:pu]
[MSG:INFO: macro0_pin gpio.19:low:pu]

I am using the latest firmware and both switches and direction pins read and function correctly when :low :high are swapped.

Hi @bdring,

The direction is being read. You can see it in your start messages.

Perhaps read, but not being applied? Or low+pullup is somehow broken? Just a suggestion.
I can assure you that switching to the latest firmwares resulted in my axes only being able to be driven in one direction. I have seen the crashes during homing with my own eyes. After reverting to an old version and changing nothing else, both directions are working again.
If there is a debug version I can install to help track this down, I’m happy to do so.

Yesterday I fired up my CNC again after several months, updated FNC and UGS but I was experiencing a bunch of problems, including door switch getting stuck in the triggered state even after closing the switch. I think if my suggestion is possible, it would probably explain that as well.

I am going to look into it, but as I mentioned, I am really busy with paying work at the moment.

Try swapping the active state in the config file on the door switch. Check the response to the ? command for each version of the config file in both the open and closed state.

Getting “Stuck in” a state may be unrelated to the :high or :low value.

I spend several hours trying to reproduce your problem without success. I used your config file on an MKS DLC32 v1.1, but modified the config file as follows:

• commented out the limit pins, so I could use it with an almost-bare DLC32
• changed soft_limits: to false, so I could issue negative moves immediately without soft limit violations

My DLC32 has stepstick drivers in all the sockets, with a stepper motor on X

I issued the following commands from FluidTerm, starting from reset:

G0
X-1
X1
X-1

I also tried in the other order, namely positive first, then negative, then positive. The motor moved in the correct direction in all cases.

I did experience one initial motion in the “wrong” direction, but realized that the Work Coordinate Offset was originally set so that the initial work position was -100, so the initial move to -1 was (correctly) in the positive direction. After zeroing the WCO, all moves happened correctly.

I put a scope on the STEP and DIR lines for the X socket. Testing with both v3.6.2 and 3.9.2pre1, I observed the following conditions on both versions:

• Upon DLC32 hardware reset, the DIR line initially went to LOW, then went HIGH as the config file was read. HIGH is the expected initial state for a :low signal.
• When X-1 was executed (after G0, and starting from WPos.X=0), DIR went from HIGH to LOW, and 1.7 msec later the first STEP pulse occurred.
• When X1 was executed, DIR went from LOW to HIGH, again 1.7 ms prior to the first STEP.

Lacking a clear recipe to reproduce the problem, I will not be able to make further progress. Your statement “Negative control command = negative movement. Positive control command = negative movement.” is too vague. I need step by step description with exactly what you did, starting from power on, with specific commands and how you issued them, omitting nothing.

Hello, I appear to be having a similar problem, sorry I’m not near my cnc laptop to give you the yaml or startup files. I upgraded to 3.9.1 so I could use my rapidchange magazine with the .nc files from Rocco on the Rapidchange discord site. When I use homing: false and do a manual homing my X axis reports 480 when it should be 0, the 480 is the X length in config.yaml. The X axis then only goes in the negative direction. If I set homing to true the problem goes away but I cannot use my toolchanger. My Machine home is the far right corner with Z at the top.

@jappiemike Create your own issue. We need to see all the info and don’t want to get it confused with OP data.

@jappiemike When you create the issue, please use accurate wording. “homing: false” is not a possible setting, since “homing:” is a section name, not an item. We can try to guess what you actually mean, but if we get it wrong, we will waste a lot of time that we don’t have.

@daxliniere Can you test the latest pre release?

Hey Bart,
I loaded 3.9.2pre2 and then ran my homing macro and immediately the Z-axis started moving DOWN instead of up.
I hit the door switch (my e-stop) and stopped motion.

This is the console from UGS:

*** Resetting controller
*** Fetching device status
*** Fetching device status (2 of 10)...
*** Fetching device firmware version
*** Fetching device status codes
*** Fetching device state
*** Fetching device settings
*** Connected to FluidNC 3.6.9
> $J=G21G91Z-3F300
ok
> $J=G21G91Z-3F300
ok
> $J=G21G91Z3F300
ok
> $J=G21G91Z-3F300
ok
*** Connection closed
*** Connecting to jserialcomm://COM13:115200
*** Fetching device status
*** Fetching device firmware version
*** Fetching device status codes
*** Fetching device state
*** Fetching device settings
*** Connected to FluidNC 3.9.2
> $H
ALARM:7

Can you move the Z up or does it always go down?

Video incoming, this is pertinent to that.

> $H
ALARM:9
> $J=G21G91Z-0.05F300
ok
> $J=G21G91Z-0.05F300
ok
> $J=G21G91Z-0.05F300
ok
> $J=G21G91Z-0.05F300
ok
> $J=G21G91Z-0.05F300
ok
> $J=G21G91Z-0.05F300
ok
> $J=G21G91Z-0.05F300
ok
> $J=G21G91Z-0.05F300
ok
> $J=G21G91Z-0.05F300
ok
> $J=G21G91Z-0.05F300
ok
> $J=G21G91Z-0.05F300
ok
> $J=G21G91Z-0.05F300
ok
> $J=G21G91Z-0.05F300
ok
> $J=G21G91Z-0.05F300
ok
> $J=G21G91Z-0.05F300
ok
> $J=G21G91Z-0.05F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $H=Z
ALARM:8
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $H=Z
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91X99Y-99F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z-1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok
> $J=G21G91Z1F300
ok

Ahhhh shit. I was filming but had paused without realising. I would have caught it going up with Z+ for a few manual steps from UGS, THEN DOWN, then up again. (There is no chance I accidentally hit the Z- button, it just went on its own.)

Just jog up and down with one jog each way. Use the console rather than buttons.

Try increasing dir_delay_us. You could also, separately, try inverting the step pulse.

Hey Mitch. I’m happy to do either of those things, but any idea why this would be different/necessary between the two firmware versions?
I don’t believe the streaming changes were implemented until some time after 3.8.2 and that version is affected by this bug.

All data helps us figure out the problem.

The idea is that the I2S clock speedup may have improved the time resolution of the dir delay, so it is effectively shorter than before, instead of being rounded up to a multiple of the older, slower clock.

The information that 3.8.2 fails is not spelled out clearly in this ticket, whose title refers to 3.9.1. If you look carefully at the startup messages and at the long comment that is mostly off the screen unless you scroll horizontally, you can maybe see something about 3.8.2, but the meaning doesn’t exactly jump out at you.

I looked at the source code for the MKS Servo57 board. It is a C program running on an ARM processor. The DIR pin is handled by an interrupt, so a software-mediated action, while the STEP pin clocks a hardware counter. The time relationship between those two processes is hard to figure out without very deep system analysis. I can easily imagine that 1 microsecond is not enough to guarantee that the DIR pin is recognized soon enough. This is yet another example where the extreme diversity of the barely-supported, barely-documented components that can be used with the FluidNC ecosystem causes us to spend ridiculous amounts of support time.

Would that only account for 1 step the wrong way?

I don’t know. It depends on when and how the code ultimately takes into account the pin change. Here is the code if you want to analyze it https://github.com/makerbase-mks/MKS-SERVO42B/blob/master/firmware

One diagnostic would be to put an LED on the DIR signal to see if it is in fact incorrect during the suspicious movement. Another would be to hook up a different motor/driver to that axis, to see if it happens without a Servo57 – but you might still need more dir delay even with a different driver.

If the OP had just done what was asked instead of pushing back, we might be farther along.

Hey Mitch, not sure where I was pushing back? I just looked through this issue and couldn’t see anything.

The discovery that the problem existed in 3.8.2 was only made after further investigations that came after I created this GH issue.

Adding LEDs at the servo seems like a great step. I think there would also be a lot of value in pinning down the exact version change that introduced this bug.
I will download and install each version between 3.6.9 and 3.8.2 on Monday when I’m back in the workshop.

Questioning the utility of my suggestion of increasing dir_delay_us, instead of just trying it, was “pushing back”. That caused me to spend a lot of time explaining my thought process and we still don’t have the result of the proposed experiment.

Bisecting versions might be helpful ultimately, but the only guess that I have right now is that the servo57 can’t handle the tighter timing. If that guess turns out to be correct, I don’t really care which version changed the timing, because it means that the solution is just to fix the config file to be less aggressive.

Questioning the utility of my suggestion of increasing dir_delay_us, instead of just trying it, was “pushing back”.

Mate, it’s the weekend, I’m not at my workshop. Also, I’m not sure how “I’m happy to do either of those things” is pushing back. I just asked if you had idea why it would be different.

Bisecting versions might be helpful ultimately, but the only guess that I have right now is that the servo57 can’t handle the tighter timing. If that guess turns out to be correct, I don’t really care which version changed the timing, because it means that the solution is just to fix the config file to be less aggressive.

Sure, but the problem occurred before you changed improved I2S, so that seems to suggest it is unrelated to timing, no?

https://youtube.com/shorts/Cz_opgrN8nM?si=TxoAf8yRnem3f4NM

I could not make it fail. That’s a DLC32 v1.1 with MKS Servo57C in the Z socket, FluidNC v3.9.1, your config file with limit pins at NO_PIN and soft_limits: false. UGS 20240308

I like the LED idea.

It feels like a timing or or circuit sensitivity. We recently solved a 485 issue that worked on only some revs with a circuit change.

I could not make it fail.

Is there any chance that when I run install-wifi.bat something is not being cleared? While I’ve been troubleshooting, I think I may have run erase.bat as well, at some point.

Let’s see what the LED tests show when I’m back on Monday.

Closing this issue. See similar issue #1408