Problem: fluidnc versions 3.9.0 and 3.9.3 dual y axis one motor rotates in same direction regardless of jog direction #1408

Just to clarify

• It it does not work with 3.9.0 and 3.9.3.
• It works with 3.9.1
• It works with versions earlier than 3.9.0

What closed loop motors are you using?

Just to clarify

• It it does not work with 3.9.0 and 3.9.3.
• It works with 3.9.1
• It works with versions earlier than 3.9.0

this is correct

What closed loop motors are you using?

nema 23 from stepper online 3nm model 23HS45-4204D-E1000 closed loop motors 4.2A per phase. motor controller is cl57T v4.1 closed loop drivers

Is it possible to place an LED on the direction signal of the controller on the axis that is having trouble?

Is it possible to place an LED on the direction signal of the controller on the axis that is having trouble?

yes, I can put an led, oscilloscope or multimeter

(I can jog for about 10-20mm before the gantry skews so much it jams)

The direction signal is persistent. just jog a few millimeters. The state of the direction signal will stay until you reverse.

It is very strange that there is different behavior between 3.9.0 and 3.9.1. The changes between those versions are in an area that is very far removed from the step/direction generation code.

Y motor connected to motor socket B on rootcnc : (bad motor always turns same way)
multimeter negative on dir and positive on ref = -4.95V (motor connector B)

Y motor connected to motor socket Y on rootcnc : (good motor operates as expected)
multimeter negative on dir and positive on ref = -0V (motor connector Y)

I presume that the voltage on the good motor socket changes depending on the command direction, while the bad one does not change?

I presume that the voltage on the good motor socket changes depending on the command direction, while the bad one does not change?

correct the motor on socket B has -5V dir to ref regardless of the direction of travel Y requested,.

I just put 3.9.1 back on, switched off and on the power and jogged in the y positive direction and BOTH motors work correctly and both motors have 0V between dir and ref when moving positive Y and -5V when moving negative Y.

In the previous test, where the B voltage did not change, was it 3.9.0 or 3.9.3?

In the previous test, where the B voltage did not change, was it 3.9.0 or 3.9.3?
3.9.3
(I had exactly the same motor behaviour from 3.9.0 but stopped using it when it got pulled from the releases)

@mattydboom Try a lot of jogs in both direction on all axes. Make sure all moves go the right way. If any go the wrong way, let us know ASAP

I must have just jogged a hundred or so times is whole host of directions and hasn’t placed a step in the wrong direction. Also reset the controller a few times, and re-run. Seems rock solid to me.

Thanks for doing the test. This is a good data point to support my belief that the direction problem was caused by overclocking the 74HC595 shift registers that both MKS DLC32 and Root Controller use, contrary to our recommendation fo 74AHCT595 parts which are 5x faster than their HC counterparts.

@jkingdcs Can you do some testing? We want to close this issue.

Glad to be of help, and will continue testing on this branch of firmware over the next few days. Hope it puts the issue to bed and can then be brought over to the main branch.

@mattydboom Can you ask on the Root CNC support forum to see if anyone else has seem the issue?

I think both you and @jkingdcs use the Root.

Yes, I already had this thought so will follow up with Pete from RootCNC to make him aware (if he isn’t already). I suspect this will affect more RootISO users if/as/when they update their version of Fluidnc to these newer builds.

@jkingdcs Can you do some testing? We want to close this issue.

I certainly will as soon as I am back at my cnc machine – which I am afraid will not be until will be early Jan.
Since I was getting motor port C direction fails with all release versions of 3.9.x I tried including 3.9.1 it should be relatively reliable to test the better clocking code. For me the direction fails are almost always consistent with version and occur straight from boot rather than breaking randomly and so testing should give reliable solid data (I hope).

Yes, I already had this thought so will follow up with Pete from RootCNC to make him aware (if he isn’t already). I suspect this will affect more RootISO users if/as/when they update their version of Fluidnc to these newer builds.

I highly agree. I think when I am in a position to do some testing, if the new clocking code works for me then I think there will be very strong evidence that the current rootcnc build needs better shift registers. Looking at the circuit diagram for the older version 2 rootcnc, it looks like the HC shift registers are powered from 3.3V. The faster hct variant requires 5V – which is going to mean more changes to the rootcnc pcb than just a direct shift register chip swap.

You can run AHCT (and HCT) from 3.3V, despite the data sheet. http://wiki.fluidnc.com/en/support/controller_design_guidelines#i2so-chips, which, apparently, no one reads, explains why. The manufacturer doesn’t bother to characterize the parts at 3.3V because their purpose in life is to interoperate with TTL, so why bother to spec at 3.3V? But the chip is identical except for the doping on one of the input transistors (which modifies the input threshold), so the otherwise-identical rest of the circuit can run at 3.3V just like the non-T variants.

HCT is not hugely faster than HC. It is the “A” prefix that gets you the speedup.

The build with the min_pulse_us fix will work with existing Root Controllers and DLC32s, because it defaults to a clock rate that is okay for HC. You have to boost the clock rate by setting min_pulse_us:1 in order to get the fastest clock that only works with AHC(T).

If Pete changes to faster chips, that might just make the situation worse because then there would be two versions and of course nobody who files a bug report will bother to tell us which version they have. So it will just waste more time when we have to ask and they have to try and figure out which.

What I really wish is that more Root Controller users would sponsor the project. Ideally the vendor would contribute too.

Hey All,

@mattydboom thank you for sending me a message and pointing me into the direction of this issue, I wasn’t aware of this happening. I can confirm the shift registers used on all batches of the Rev 3 is the 74HC_HCT595.

https://assets.nexperia.com/documents/data-sheet/74HC_HCT595.pdf

The new I2S clocking is now in v3.9.4. Try using 2 or 4 for the min_pulse_us: If that does not work for you, there is not much more we can do.

initial testing of 3.9.4 looks good!
Motor channel C of the rootcnc now works correctly with min_pulse_us set to 4 over multiple moves, and multiple controller resets and controller reboots. ALL previous 3.9.x including 3.9.1 would consistently not step correctly with motor channel C and so I believe this to be a reliable test.
Thank you for adding the min_pulse_us to provide support for those of us with inferior shift registers.

P.S
A small amount of testing also seems to indicate that min_pulse_us set to 2 works. However I intend to run the CNC with min_pulse_us set to 4 to be on the safe side.