[androcles]

Hello

I have just been finetuning my new homemade CNC-Router.

I am using these on all axes:
https://www.aliexpress.com/snapshot/...Id=32712581167


I am having very big problems with them, and I cant figure out what is wrong.

The problem is that when I am milling parts, they often come out in the wrong dimensions. It is as if the machines 0,0,0 coordinates are shifting.

I am using Mach 4 and also tried using Mach 3, and I am controlling via an Ethernet Smoothstepper.

The test, which I think concludes that there is something wrong in the system, was just the machine being jogged a certain distance back and forth. Then when looking at the position loop feedback (1000 count encoder) on the servodrive it started off at lets say 0 then to 790 and then back, this time it ended at 10 and the sequence was like this: 0->790->10->781->19->770-->30 and so forth. So constantly adding and loosing approx. 10 "counts" pr. cycle?

What could be causing this?
Interference?
Software?
Pulsetrain from the computer and smoothstepper?

Best regards
Andreas Landsfeldt

[androcles]

I just made a short video showing the error with the positioning gradually getting worse, I have tested it on all 4 drives with load and without. This error is very sporadic, sometimes it is there other times I cant make it happen no matter what..

The other weird thing is that the encoder is constantly showing zero after powerup, then when I move the axis 1mm it goes up to 154 counts which should be 160 counts. Then when going 1mm the other way, it shows -6 counts, ie. moved 160 counts as it should. This also happens on all drives.

Here is the video:
https://streamable.com/kf5sl

Best Regards
Andreas

[James Newton]

The Aliexpress link doesn't work except for you... e.g. it wants a login. Can you describe the unit you purchased? Find a sales link for it?

I ask because I'm trying to understand what is the controller for the servo. E.g. is it an all in one unit with motor, driver, encoder, and servo controller in one package? Or is it motor / encoder, and then a separate driver, encoder, and what is the controller in that case?

Because the error is apparently in the encoder signal, there are a few sources:
1. The encoder could be slipping or otherwise not putting out correct signals (unlikely)
2. The wires from the encoder could be picking up RF interference, cross talk (RF interference from each other) or just be weak. More likely if the wires are long, unshielded, or thin.
3. The controller could be losing counts. Usually there is an error indicator for this (there is on my BOB PID) but god knows what the stuff from China has in it. This is more likely if it happens more often when moving quickly or when the unit is shaking.

Once you have a likely cause, you can move on to how to resolve that issue.

[androcles]

Hello

Here is another link to a similar unit:
https://www.aliexpress.com/item/NEMA...ceBeautifyAB=0


Hope that clears it up about the motor configuration.


I will try to go through your answer:

Because the error is apparently in the encoder signal, there are a few sources:
I am not sure it is in the encoder signal as it shows the correct counts - I had a dial indicator hooked up, and the counts it were off, also showed on the indicator, therefore the encoder must be working correctly in my opinion?

1. The encoder could be slipping or otherwise not putting out correct signals (unlikely)
Agree

2. The wires from the encoder could be picking up RF interference, cross talk (RF interference from each other) or just be weak. More likely if the wires are long, unshielded, or thin.
This I am more likely to accept as the culprit. I have many different voltages running together in unshielded wiring.
But the problem with interference is that it shouldn't be the same error all the time, but the error I am seeing is the same across 4 different drives?

3. The controller could be losing counts. Usually there is an error indicator for this (there is on my BOB PID) but god knows what the stuff from China has in it. This is more likely if it happens more often when moving quickly or when the unit is shaking.
I have the Chinese B.O.B DB-1205, if that helps?
But yes, there is no correlation between speed and error --> It happens when going 500mm/s at 200mm/s^2 acceleration and also at 15000mm/s at 1500mm/s^2.

[James Newton]

2. The wires from the encoder could be picking up RF interference, cross talk (RF interference from each other) or just be weak. More likely if the wires are long, unshielded, or thin.
This I am more likely to accept as the culprit. I have many different voltages running together in unshielded wiring.
But the problem with interference is that it shouldn't be the same error all the time, but the error I am seeing is the same across 4 different drives?

I'm not sure I understand what you mean by "the same across 4 different drives"? Of course RF interference would affect all the drives. If all the cables are unshielded, you will get errors on all the cables.

[androcles]

Yes, I know that.

What I mean is that the error that is occuring is the same, ie. the same numerical error on the drives. That seems strange in my opinion, although I am defininetly not an expert in regards to RF interference!

EDIT:
I just found an Arduino that I will try to connect to the drive later today and see if that works or if the error changes, also going to use different cables to test this.

[109jb]

If the errors are exactly the same on all axes then I would be looking at settings. The drives should have specifications for driver timing settings. You have to set your control software (Mach3, LinuxCNC, etc.) to adhere to these settings.

For example, my drivers require 5 microseconds before issuing a step pulse following a direction change. If the controller sends a step signal faster than this the drive will move the wrong direction at first.

There are several setting like this. On my drives they are as follows (This is just an example and your drives may have different values):
1. Enable must be ahead of DIR by 5 microseconds
2. DIR must be ahead of Pulse by 5 microseconds
3. Pulse width must be more than 1.5 microseconds
4. Pulse space must be more than 1.5 microseconds

If you don't have these settings correct in your control software then the drives will not respond correctly

[androcles]

Hey

If the errors are exactly the same on all axes then I would be looking at settings. The drives should have specifications for driver timing settings. You have to set your control software (Mach3, LinuxCNC, etc.) to adhere to these settings.

For example, my drivers require 5 microseconds before issuing a step pulse following a direction change. If the controller sends a step signal faster than this the drive will move the wrong direction at first.

There are several setting like this. On my drives they are as follows (This is just an example and your drives may have different values):
1. Enable must be ahead of DIR by 5 microseconds
2. DIR must be ahead of Pulse by 5 microseconds
3. Pulse width must be more than 1.5 microseconds
4. Pulse space must be more than 1.5 microseconds

If you don't have these settings correct in your control software then the drives will not respond correctly

I am using Mach 4 and a Smoothstepper, I have not seen any settings regarding the timing of pulses, only in Mach 3 I believe.


Regarding my testing today I found a piece of code and uploaded it to the arduino which was connected to the X-axis step and dir pins through the same wires as before, so it was only the pulses that were coming from a different source.

Lo and behold - https://streamable.com/vjq1g

It worked perfectly, and I tried jogging the Z and Y in between, they made the exact same error as in the video I posted yesterday.

So now I am thinking about buying the Planet-CNC board and software, so I can get rid of the chinese B.O.B, Smoothstepper and Mach 4, which has it fair share of problems.

[James Newton]

That's interesting. It does appear that the Smoothstepper plugin for Mach 4 has no place to set pulse widths. And your issue does appear to be related to the control signals. There is a slim chance that it's RF related if the control signal is traveling a longer path from the Smoothstepper than it is from the Arduino, but honestly I'm 99% that 109jb is correct and it's a pulse width / timing issue. That is a far better match to your finding about the error always being the same; RF is typically far more random.

You might also look at:
https://www.poscope.com/product/pokeys57cnc/
if you don't mind shipping from the EU.

Both Planet-CNC and pokeys are PMinMO compatible BTW.
techref.massmind.org/Techref/io/PMinMO.htm

[androcles]

Yes, it seems very likely that it is the cause!

I am just wondering what software supports changing the delay/timing of step/dir signals?

I know that Planet-CNC can change the pulse width, but not sure about the timing.

I also checked out the PoKeys, and I was not able to find anything about the timing or the pulse width?

Any suggestions there?

Best Regards

[James Newton]

Contact them.

[androcles]

I will try to do that even though I made a new discovery last night.

I tried changing the pulse edge, I believe it is from falling edge to rising edge, on the drive. Oddly enough it was still offset by 6 counts in the initial move but then afterwards it moved precisely as it should without "wandering" off.

Thanks for the help!