[oscmejia08]

I’m setting up a new CNC router table. I’m doing the step configuration, and I notice that my motion on all axis is not lineal.

I calibrated the steps for 100mm and every time jog it 100mm it moves 100mm. However, if I try to move it, let’s say 45mm, it just moves 25mm. If I change the feed rate it changes the travel.

I know the issue is not mechanical since I have consistente results for the same command.

Universal Gcode Sender (UGS).
firmwareName": "GRBL 1.1f.
Teensy 4.1.
CNC Breakout board
This is my UGS firmware settings:

```
$0: 10.0 #Step pulse time
$1: 25 #Step idle delay
$2: 0 #Step pulse invert
$3: 1 #Step direction invert
$4: 7 #Invert step enable pin
$5: 7 #Invert limit pins
$6: 1 #Invert probe pin
$8: 0 #
$9: 1 #
$10: 511 #Status report options
$11: 0.010 #Junction deviation
$12: 0.002 #Arc tolerance
$13: 0 #Report in inches
$14: 0 #
$15: 0 #
$16: 0 #
$17: 0 #
$18: 0 #
$19: 0 #
$20: 1 #Soft limits enable
$21: 1 #Hard limits enable
$22: 1 #Homing cycle enable
$23: 3 #Homing direction invert
$24: 25.0 #Homing locate feed rate
$25: 500.0 #Homing search seek rate
$26: 250 #Homing switch debounce delay
$27: 10.000 #Homing switch pull-off distance
$28: 0.100 #
$29: 0.0 #
$30: 18000.000 #Maximum spindle speed
$31: 0.000 #Minimum spindle speed
$32: 0 #Laser-mode enable
$33: 5000.0 #
$34: 0.0 #
$35: 0.0 #
$36: 100.0 #
$37: 0 #
$39: 1 #
$40: 0 #
$43: 1 #
$44: 4 #
$45: 3 #
$46: 0 #
$62: 0 #
$63: 3 #
$64: 0 #
$65: 0 #
$100: 89.08000 #X-axis travel resolution
$101: 86.47000 #Y-axis travel resolution
$102: 200.00000 #Z-axis travel resolution
$110: 2000.000 #X-axis maximum rate
$111: 2000.000 #Y-axis maximum rate
$112: 2000.000 #Z-axis maximum rate
$120: 200.000 #X-axis acceleration
$121: 50.000 #Y-axis acceleration
$122: 50.000 #Z-axis acceleration
$130: 1200.000 #X-axis maximum travel
$131: 1200.000 #Y-axis maximum travel
$132: 220.000 #Z-axis maximum travel
$170: 0.000 #
$171: 0.000 #
$172: 0.000 #
$342: 30.0 #
$343: 25.0 #
$344: 200.0 #
$345: 200.0 #
$346: 1 #
$347: 2.0 #
$348: 2.500 #
$349: 25.000 #
$370: 0 #
$372: 0 #
$384: 1 #
$398: 35 #
$481: 0 #
$484: 1 #
$486: 0 #
$650: 0 #
```

I have very conservative number for acceleration (150mm/sec2), feed rate (1000 mm/min).

At this point I know that the lower the acceleration, the longer the travel for the same value.

[hfjbuis]

You could run to fast and are losing steps. Reduce the max speed and acceleration 10 times for all axis and try again. It will be slow but within 5 minutes you know if you are moving to fast.
If you are loosing steps, you also won't return to the starting point after moving to fast.

Mark the position of the coupler and check if the shaft(s) are moving inside the couplers.

[oscmejia08]

thanks @hfjbuis. Tested lowered acceleration and makes no difference. I also double checked hardware and I'm pretty sure that's not the issue.

I contacted StepperOnline since I'm using their nema 34 steppers and driver. They suggested I ran a test with an Arduino board, so I did.
I connected 2 pins and ground from an Arduino Uno to the driver, for the X axis.
I tested the same distance with different speeds and I always got the same travel.
I then reconnected the teensy and ran the same test using UGS, and:
1) If i send a command for the same distance with the same feed rate, it always travels exactly the same
2) If I change the feedrate for the same distance, actual travel changes
3) Even at a very low acceleration, If I change the feedrate, the actual travel is not the same.

This video shows my test: https://youtu.be/-V0ec9jldtY

Also attached is the Arduino code that I used in my test.

So, looks like the issue is Universal Gcode Sender? I can't find what could be wrong in the configuration, looks, simple.
Any ideas will be appreciated, I'm running out of them at this point.

[hfjbuis]

The arduino code sends a symmetrical pulse, all cnc controllers send a pulse that is 1..10 usec active. You could change the active high time to 10 usec and double the active low time. I should not make any difference but who knows. If it makes a difference, it is the driver, wiring or the step pin voltage or max current.

After you changed the controller and the gcode sender, you have a problem. That could be caused by UGS or by the Teensy. Both have a reputation of being reliable.

You could use the arduino serial connector to send the gcode to the Teensy. That should/could rule out UGS or the Teensy.

Please post your gcode so I can have a look at it to rule out the gcode.
How is the teensy connected to the driver?

[oscmejia08]

thank again for your response @hfjbuis.

I'm using this Break Out Board for the Teensy https://www.tindie.com/products/phil...y-41-t41u5xbb/
I have the proper divers for my steppers.
Each motor/driver has its power supply.

If you look at my initial post, looks like the active pulse is by default 10 ($0), so, I'm going to double active low ($1 to 50) and try:

$0: 10.0 #Step pulse time
$1: 25 #Step idle delay
$2: 0 #Step pulse invert
$3: 1 #Step direction invert
$4: 7 #Invert step enable pin
$5: 7 #Invert limit pins
$6: 1 #Invert probe pin
$8: 0 #
$9: 1 #

I'm going to also try a different computer with a different Gcode sender.

[hfjbuis]

I'm using this Break Out Board for the Teensy https://www.tindie.com/products/phil...y-41-t41u5xbb/

The boards from phill are well designed and up for this job.

If you look at my initial post, looks like the active pulse is by default 10 ($0), so, I'm going to double active low ($1 to 50) and try:

I mean you should adopt the UNO program to send a 10 usec step pulse so it behaves the same as the Teensy board.

I'm going to also try a different computer with a different Gcode sender.

That is a proper way to rule out 2 causes of the problem.

Don't give up,

Regards Huub

[oscmejia08]

I see what you mean Huub (see attachment)

BTW, I tested a different computer running Open Builds Control and I got the exact same results.

I will test the updated code using the Arduino Uno shortly.

[oscmejia08]

Updated Arduino code attached.

I ran these test in X:

speedDelay = 1000
travelDistanceMM = 10 (mm)

speedDelay = 1000
travelDistanceMM = 50 (mm)

speedDelay = 1000
travelDistanceMM = 75 (mm)

speedDelay = 1000
travelDistanceMM = 100 (mm)

speedDelay = 1000
travelDistanceMM = 300 (mm)

For every one I punctured a hole by lowering Z. I took measurements using a digital caliper

Then, I offset by a few mm Y and ran the same tests, but faster, speedDelay = 300

Conclusion:

1) Travel different distances at the same speed is linear, as it should be
2) Travel the same distances faster, actually moves the same distances.
3) If this Arduino code is correct and similar in essence to what Teensy is doing, AND since I already tested a different computer with OpenBuild Control + Teensy, the issue appears to be with Teensy or the break out board.

Any ideas?


EDIT: I take back conclusion #3. When I run the test with OpenBuilds Control, I noticed that it used the same configuration values that I had in UGS.

[hfjbuis]

I assume you have a 48V PSU and pretty heavy steppers. The problem could be you are "generating steps" at lower speed (highest amps are at the lowest speed). That can be caused by electric interference. The high speed "low impedance" Teensy is more vulnerable for this than the low speed lower impedance UNO board.
You could setup the UNO using grbl firmware and configure the settings the same as the Teensy and use the same computer and gcode sender. If it works, you have a cause, provisional solution and a backup in case the Teensy breaks down in future.

The things to do in any setup is:
- route the stepper motor cables away from the driver (step/dir/enable/alarm,etc) cables.
- route the driver cables away from the driver power supply cables.
- route the driver cables away from the mains cables.
- route the USB cable away from the mains, power supply and stepper motor cables.
- route a separate power supply cable to each driver.
- Earth wires on aluminum need a (new) toothed washer between the aluminum and cable clamp to improve conductivity.

Things you can do to solve the interference that is more trial and error. Just start with what is easy to do (quick fix):
- use a separate power supply for the controller board and the drivers.
- use the same power supply for the controller board and the drivers.
- connect the PC to the controller board using Bluetooth or WiFi to avoid ground loops (need extra hardware)
- connect the PC to the controller board using Ethernet. Ethernet is more immune for noise (need extra hardware)
- make a star earth connection between the PC, power supply's, router frame using a thick earth wire. This reduces the ground loops in the controller board.
- remove the earth connection between the PC, power supply's, router frame. That can eliminate a ground loop.
- reduce the max current of the driver. Lower current, less electrical interference.

If you have a 24V PSU, give it a try. (Max RPM=(Vpsu-Vmotor)*rated_current*60/(sqrt(2)*pi*rated_holding_torque)
If nothing works, you could swap the Teensy for another 32 bit board (only if the arduino has no problems)

[hfjbuis]

I forgot to mention the options for shielded cables:
Shielded cables can reduce the electric interference. For this to work, both sides of the cable need the shield connected to ground. That can cause ground loops if both sides of the cable don't have another much better (low resistance) ground connection. Shielded cables are thicker, stiffer, more expensive and may need new connectors. Replacing cables can be a lot of work, not something to do as a first option.

[oscmejia08]

Thanks for all the suggestions @Huub

TLTR: I found the issue, but I don't understand why.


So, I started with the gal of tests your suggestions.
First thing I did, was took out of the rail all the control wires from the Teensy to the drivers. See "img1".
This made no difference.

Then I remember that when I tested with the Arduno Uno, I only had 4 wires, Dir +/- and Pul +/-. But with the Teensy I also have enable +/-. I disconnected enable and It worked :|. See "Img2"

I ran a quick test, same distances at different feed rates and got the same travel. I will run more comprehensive tests to confirm, but so far, looks promising.

The big question is why having enable +/- makes travel non-lineal????

[hfjbuis]

Great you "found" the cause of your problems.

The big question is why having enable +/- makes travel non-lineal????

The CL86T driver is, like most drivers, enabled when the enable line is not connected.
The Teensy has a gnd/step/dir/enable pin for each driver. That implies, the Teensy step/dir/enable output is a sourcing output and that your connections are OK.

If enabled always on solves your problem, it could mean the enable timing is wrong or the enable signal is not stable.
The only timing requirement in the CL86T manual are for the step pulse that should be at least 2.5 usec and the direction signal should be at least 5usec.
In the manual, there are no timing requirements given for the Enable pin. Most stepper drivers require the enable pin to be active for at least 1..5 usec before step signals should be sent. My Lichuan A4 servo driver requires enable to be 0.1 sec active before step pulses can be sent. If the enable timing is off, there would be loss of steps at the start of the movement but your problem seems greater. Nevertheless, it is worth to look further in to this.
Grbl has a step Enable and Idle delay setting ($3) . GrblHAL has a step Idle delay ($1) setting but I assume it is also an enable delay. Set the GrblHAL step idle delay to 200 (200 msec) and check if it solves your problem.
If it does not solve your problem, it could be worth checking the signal at the driver using an oscilloscope to see if the enable signal is stable.

I have checked your settings and found that the direction and enable pin are inverted but the step pin is not. I am not sure if GrblHAL also inverted the step pin logic. Invert the step pin signal ($2=7) and check if it helped.

Regards Huub