Losing steps on closed loop stepper motors

12 Apr 2020 15:25 #163775 by goaran
I don't have a mesa board and am running directly from parallel port.
There sometimes is latency warning on startup of LinuxCNC in the right corner.
Where does StepConf set up the latency periode to 100K? When I try to enter anything above 50000 it automatically gets reduced to 50000?

Please Log in or Create an account to join the conversation.

12 Apr 2020 15:47 #163776 by tommylight
In the INI file.
Open file browser, got to home/linuxcnc/configs, open the config you are using, there are several files there but only one should have .ini extension. Right click on it, open with text editor. Look fo "base period" there you should have 100.000 set.
If you are getting latency warnings with 100.000 base period you can set it to 150.000 but that will greatly limit the step rate, and the overall velocity.
I do not recall, what drives are you using ?

Please Log in or Create an account to join the conversation.

13 Apr 2020 00:40 #163828 by BeagleBrainz

goaran wrote: @PCW: no I have not tried inverting the pulse, however the motors seem to move totally normal ig the slight drift over time.
How could that be a result of inverted step pulses?

@BeagleBrainz: it seems to be with all axis, however a bit more on the longer one.
No its not a linear error. If you move one axes and measure the distance, then the measured distance is totally fine within some few microns.
The error only occurs when milling for lets say half an hour and then measuring the position against the start position.
The coupling between the motors and the lead screw is done with those couplings that have red rubber in between.
The bearings at the end of the leadscrew are the bearing blocks that come with the leadscrew. I have tested pushing as strong as I can against the bearings and also moving the axis in between, that does not seem to have any effect on them.

The "procedure" I used for testing is. Measure the position of the tool in one axes. Then mill something. Measure it again. This results in an difference of up to 0.5 mm after half an hour of milling. Since 0.5mm is really a lot i cannot imagine how this could be from the leadscrew backlash.

The error is kind of random therefor I habe not tested from different start points.

Generally that's not the accepted method for testing backlash. Depending on the amount the leadscrew is changing directions it will eventually add up.
I would suggest using google to search for methods to measure backlash.
One backwards & forwards test really wont show much, the more you can repeat this procedure the more the commutative error will be.
Whilst you may measure "within a few microns" with one iteration, that will change to "within a few tens of microns" over 10 iterations, ie this measurement will be 10 times greater. Backlash can also come from the coupler itself. If you have a low quality coupler that can contribute to the issue. A good quality coupler from a reputable supplier\manufacturer with help mitigate the issue. A good quality coupler is not cheap. They cost somewhat more than the types you get from most ebay stores & "maker stores".
A little bit of looseness here some there and some more else where will add up.
It may even be that there is a non linear section of the leadscrew that could be enough to add to other issues.
Any tests you make should ideally be done with a dial indicator. It can be painful and time consuming to chase these issues.
One thing that comes to mind is that some of the cheaper bearing blocks use standard bearing and not angular contact bearings, I have 2 sets of bearing blocks that I bought at different times from different suppliers. On set has angular contact bearing on the fixed block and the other has plain bearing on the fixed end.
Then if you add issues with latency..............

Please Log in or Create an account to join the conversation.

14 Apr 2020 09:05 #163929 by goaran
@tommylight thanks for the hint with the ini file. I'll try that out.
@BeagleBrainz, ok, thx. I'll try to measure the backlash in a more professional way and see if there is some issue with that.

Please Log in or Create an account to join the conversation.

14 Apr 2020 11:50 #163938 by bbsr_5a
messuring backlasg is best on a dial (watch style 0,01mm 6mmway

move axes into the dial as 2mm
goto stepmode 0,01 hit 10 times same Direction you shoudt be seeing 2,1mm
if not somthing in Mechanic is wrong or the scale does not match
Move back 10 Ticks you shoudt see 2mm
repat 5 times if it is correct you are on the good side

If you need to change backlash start over

Please Log in or Create an account to join the conversation.

11 May 2020 19:13 #167407 by goaran
Ok, so i finally found some time to dig further into the problem.

What I've done so far:
- Removed the motors from the axes and added a rotation mark to the shaft.
- Changed the PC to a newer one with a Base Periode of less than 10000ns
- Changed the Settings for the latency and tried follwing configuration:

Steptime : 5000
Stepspacing: 5000
Dir Switch 20000
Dir Swicht2 20000

I've played around with these values in between 1000 and 10000 for the steps and in between 5000 and 35000 for the Dir Change delay.

Further I've inverted the dir signal in Stepconf as well on the dip switch on the motors.

The result is that when I set the position for e.g. the X-axis to 0.0 then run a short program and then again go to G0 X0 the rotation of the motor is off by something in between 10° - 30°. It seams to kind of reproducable from the value when I run twice with the same configuration, however It seems to change depending on the configuration.

TLDR: It cannot come from the mechanics since I've removed those. Further with the new PC i do not thing it can come from the latency or something like that. The Steptimes also seam reasonable with 5000 (the datashet mentions >2500 should be fine)

So what else could be the problem? Any ideas?

Please Log in or Create an account to join the conversation.

11 May 2020 19:29 #167410 by tommylight
To much microstepping can do that, so check the drive dip switches and set them to 800 or 1600 steps pre revolution.
Also open your hal file and look for any line containing something_maxerror some value, and delete those.

Please Log in or Create an account to join the conversation.

11 May 2020 20:15 #167418 by PCW
One possibility is marginal step/dir drive levels
can you check the high/low levels of both the step/dir signals?

Direction is easy, just measure when connected and jog in either direction
Measuring the Step signal levels may require temporarily unlinkp'ing and
setp'ing the appropriate parallel port pins in hal

Please Log in or Create an account to join the conversation.

08 Jun 2020 08:38 #170594 by goaran
I finally could solve the problem, so if someone has the same problem in the future maybe this post can help you as well:

I first added some markers to the stepper shaft so I can directly track the rotation, and disconnected them from the axes. From here it could be seen that the problem really comes from the steppers and not from the mechanics.

So the first thing I did was to try a new PC with less jitter. That did not help.
I tried to change some more timing settings in stepconf, however that did not help eighter.

What solved the problem was following:
On the stepper driver there is the possibility to select by a dip swich if a step should be triggered on rising or falling edge. I changed this from rising to falling and suddenly the problem was gone.
So my guess is, that the signal looks bad and somehow the stepper triggers multiple steps when the signal overshoots or something like that, unfortunately I do not have an oscilloscope at the location the cnc is at.
The following user(s) said Thank You: tommylight

Please Log in or Create an account to join the conversation.

Time to create page: 0.097 seconds
Powered by Kunena Forum