stepper precision
-
@arhi Can you post your Python code for this?
I suspect there's an "off-by-one" somewhere and you're getting better results than you see in your graph.
I'm probably wrong, but if so, you might be happy.
SeemeCNC Rostock Max V3 converted to V3.2 with a Duet2 Ethernet Firmware 3.2 and SE300
-
This post is deleted! -
@alankilian said in stepper precision:
@arhi Can you post your Python code for this?
I suspect there's an "off-by-one" somewhere and you're getting better results than you see in your graph.
I'm probably wrong, but if so, you might be happy.
I hoped but it's not
anyhow .. here it is:#!/usr/bin/env python3 import pyprofibus import time import RPi.GPIO as GPIO def main(watchdog=None): master = None forwarddata = [] backwardsdata = [] #poserem se na jezik for i in range(410): forwarddata.append(0); backwardsdata.append(0); try: config = pyprofibus.PbConf.fromFile("arhi_readencoder.conf") master = config.makeDPM() outData = {} for slaveConf in config.slaveConfs: slaveDesc = slaveConf.makeDpSlaveDesc() master.addSlave(slaveDesc) outData[slaveDesc.slaveAddr] = bytearray((0x00, )) master.initialize() GPIO.setmode(GPIO.BCM) GPIO.setup(12, GPIO.OUT) GPIO.setup(13, GPIO.OUT) GPIO.output(12, GPIO.LOW) GPIO.output(13, GPIO.LOW) totalsteps = 0 for i in range(400): done = False counter = 0 average = 0 while not done: outData[slaveDesc.slaveAddr] = bytearray((0x00,0x00,0x00,0x00, )) for slaveDesc in master.getSlaveList(): slaveDesc.setOutData(outData[slaveDesc.slaveAddr]) handledSlaveDesc = master.run() if handledSlaveDesc: inData = handledSlaveDesc.getInData() if inData is not None: print(inData[3] + inData[2]*256) average = average + inData[3] + inData[2]*256 counter = counter + 1 if (counter > 9): done = True average = average / 10 if watchdog is not None: watchdog() print("AVERAGE: ", totalsteps, ", ", average, flush=True) forwarddata[totalsteps] = average; # now do a step GPIO.output(12, GPIO.HIGH) time.sleep(0.0001) GPIO.output(12, GPIO.LOW) time.sleep(1) totalsteps = totalsteps + 1 GPIO.output(13, GPIO.HIGH) for i in range(400): done = False counter = 0 average = 0 while not done: outData[slaveDesc.slaveAddr] = bytearray((0x00,0x00,0x00,0x00, )) for slaveDesc in master.getSlaveList(): slaveDesc.setOutData(outData[slaveDesc.slaveAddr]) handledSlaveDesc = master.run() if handledSlaveDesc: inData = handledSlaveDesc.getInData() if inData is not None: print(inData[3] + inData[2]*256) average = average + inData[3] + inData[2]*256 counter = counter + 1 if (counter > 9): done = True average = average / 10 if watchdog is not None: watchdog() print("AVERAGE: ", totalsteps, ", ", average, flush=True) backwardsdata[totalsteps] = average; # now do a step GPIO.output(12, GPIO.HIGH) time.sleep(0.0001) GPIO.output(12, GPIO.LOW) time.sleep(1) totalsteps = totalsteps - 1 for i in range( len(backwardsdata) ): print(i, forwarddata[i], backwardsdata[i], forwarddata[i] - backwardsdata[i]) except pyprofibus.ProfibusError as e: print("Terminating: %s" % str(e)) return 1 finally: GPIO.cleanup() if master: master.destroy() return 0 if __name__ == "__main__": import sys sys.exit(main())The "off by one" is imho "not a problem" as if you look at the printout ..
0 20828.0 0 20828.0 1 20835.0 20869.0 -34.0 2 20840.0 20876.0 -36.0 ... 398 23964.0 23972.0 -8.0 399 23972.0 23976.0 -4.0 400 0 23979.0 -23979.0you see that firs read is 20828.0, 0 - so going backwards I did not read backwards at all, and last read is 0, 23979.0 so going forward I didn't read that one ...
also you see the "end" going forward it goes up (last dataset, for the TMC driver it's reversed)
23964.0
23972.0then first read backwards (actually it was not stepped backwards yet that's position after last step forward)
23979.0 so larger than 23972and then it goes down again
23976.0
23972.0also, if you look how error is down to nothing when you just turn direction and how it rises... takes some 20+ steps in reverse for error to catch up the average values..
First step back the error is 0.02 degrees
-
I managed to get S42B v1.0 to work (no clue how any more), now it's running in closedloop mode too so waiting for results... interesting - I have no clue what microstepping it is running at, lcd configured 1/32 but what it is actually doing - no clue, will run the original one direction full circle after this back-forth finish
need to find my vallder (leadshine clone) .. dunno where I put the darn thing in this chaos
-
S42B V1.0 - in closed loop mode def does not work ok .. having ton of issues with it, was not working at all, now it moves but .. the worse part is it's not even showing that there is an error here
.. other ppl also report issues with it so won't waste more time on it ..
-
@arhi said in stepper precision:
if you look how error is down to nothing when you just turn direction and how it rises... takes some 20+ steps in reverse for error to catch up the average values..
If I'm understanding you correctly, that's probably the flexibility in your tape/ziptie connection causing "backlash"
When I move datapoints around to fake-eliminate that backlash (if that's what it is) I get a very nice chart of error values.
-
@alankilian said in stepper precision:
If I'm understanding you correctly, that's probably the flexibility in your tape/ziptie connection causing "backlash"
very possible. I tested 10 steps back/forth and was getting values 0-2 for error so assumed that's it but looks like it's not holding water... darn encoder have shaft larger than nema17 and smaller than 8mm so none of my couplers fit.. ordered some new but..
-
S42B, closed loop mode - changed menu to 1/16 (from 1/32) and let it calibrate again
-
enough for now, need to stiffen this coupling
-
If you have it available somewhere you can use some 6mm/8mm inner diameter petrol hose. The rubber kind with a (cotton?) braid as reinforcement embedded in the rubber. Due to the reinforcement that stuff is quite stiff in rotation, due to it being rubber a hose clamp clamps it stiffly around a shaft.
I stumbled over M569.1 in the G-code reference today. Is that already implemented?
In case you have to return the encoder before finishing you tests: I probably have some 2500-line incremental encoders with quadrature output (10000 pulses/rev) lying around over here somewhere. I can miss one or two. If I can find them..
(you may think your mancave is a mess, but I am fairly certain I win that battle) -
@DaBit said in stepper precision:
If you have it available somewhere you can use some 6mm/8mm inner diameter petrol hose. The rubber kind with a (cotton?) braid as reinforcement embedded in the rubber. Due to the reinforcement that stuff is quite stiff in rotation, due to it being rubber a hose clamp clamps it stiffly around a shaft.
no way to get it as most shops are closed but I expect monday to arrive the aluminium 5-5 that I'll drill on one side to 6mm should work ok I'll try to put it in a lathe
I stumbled over M569.1 in the G-code reference today. Is that already implemented?
no idea
In case you have to return the encoder before finishing you tests: I probably have some 2500-line incremental encoders with quadrature output (10000 pulses/rev) lying around over here somewhere. I can miss one or two. If I can find them..
Thanks :), the idea with 16bit was to get really precise data about microstepping, I think I'll manage to get all the testing I want before I return it
(you may think your mancave is a mess, but I am fairly certain I win that battle)
uh, I doubt, not 'cause my mancave is normally total chaos but because I purchased a house in 2019 and started renovating and it features a small 50m2 guest house (with 50m2 under roof storage too) in the yard that I planned to use as my new mancave, and since the plan was to move in summer 2020 I started converting my current mancave (a 20m2 room 5m high in appartment) into storage room, so I'm now working from something one could call storage and not mancave, stuff falls on me non stop, if I move too fast stuff falls of my desk, keyboard drawer etc .. very nasty place to work, not at all "artistic chaos", more like "garbage dump"
... and due to #$%^#^% we did not move yet so .. house is still being renovated and I work berried in "garbage" .. not something I am happy with -
alu coupling mounted.. repeating the measurements..
-
Fingers crossed...
-
@DaBit initially the "vibrations" are still there (1/16, closed loop, s42b)
AVERAGE: 449 , 205.2 221 221 221 222 222 222 222 221 222 221 AVERAGE: 450 , 221.5 234 234 234 234 234 235 234 235 234 234 AVERAGE: 451 , 234.2 256 256 255 256 255 256 256 255 256 256 AVERAGE: 452 , 255.7after it finish we'll check the positional error but.. imho this S42B is a complete and utter POS
this is measured second after step!!! so the vibration is either $#^#@ motor or S42B dancing around the target location (same vibration 10sec after step too)
-
@arhi Do you mean that the values you are reading are changing by plus or minus one if you read the encoder a lot of times?
Because that's not unusual for such a high-resolution encoder where one count is 0.005-degrees of angle.
Also, it's possible to get a +/- 1 oscillation if you stop RIGHT ON the edge of a line and move an infinitesimally-small angle. But I wouldn't expect that on every step. You showed three steps where it was doing it, so I think it's the controller.
Hey, depending on how the s42b reads the TLE5012B angle sensor it can really only get either 15 bits or 16 bits of value from the angle of the magnet, so your encoder might have twice the resolution of the controller.
15 bit representation of absolute angle value on the output (resolution of 0.01°)
16 bit representation of sine / cosine values on the interface
So I think the controller is doing about as well as it can.
SeemeCNC Rostock Max V3 converted to V3.2 with a Duet2 Ethernet Firmware 3.2 and SE300
-
-
@alankilian said in stepper precision:
@arhi Do you mean that the values you are reading are changing by plus or minus one if you read the encoder a lot of times?
Yes. But if I turn motor off that does not happen.
Also, it's possible to get a +/- 1 oscillation if you stop RIGHT ON the edge of a line and move an infinitesimally-small angle. But I wouldn't expect that on every step. You showed three steps where it was doing it, so I think it's the controller.
Exactly, happens almost every time, and with TLC for e.g. it was not happening (we'll see how it will behave with alu coupler) and when I turn the driver off it does not happen so it's def "dancing", not by much but..
So I think the controller is doing about as well as it can.
WRT "dancing", probably. WRT "position", not really
The LCD is not showing errors, the "error" led (lost step) is off .. and 800 steps in forward and then 800 back we have error of 0.75° .. that's HUGE IMHO especially considering 1step/second speed -
@arhi said in stepper precision:
The LCD is not showing errors, the "error" led (lost step) is off .. and 800 steps in forward and then 800 back we have error of 0.75° .. that's HUGE IMHO especially considering 1step/second speed
If you were to configure the stepper (if possible) to only use whole steps would the error go away?
Frederick
Printers: a E3D MS/TC setup and a RatRig Hybrid. Using Duet 3 hardware running 3.4.6
-
That's half a step. I would expect a simple open-loop motor to perform better.
On the other hand, I am sure you can interpolate a single rotating magnet with 15 bit resolution, but resolution != precision.
A long time ago I did approximately the same for a customer, but back then it was an entire board with an FPGA, Burr-Brown ADC's and discrete analog frontend. We got ~9 bits of accuracy, the rest got lost in noise and nonlinearities. -
@fcwilt said in stepper precision:
@arhi said in stepper precision:
The LCD is not showing errors, the "error" led (lost step) is off .. and 800 steps in forward and then 800 back we have error of 0.75° .. that's HUGE IMHO especially considering 1step/second speed
If you were to configure the stepper (if possible) to only use whole steps would the error go away?
Frederick
with S42B - not that I know ... I'll do as much tests with S42B first (open and closed loop) then moving to 2208 with different motors ... I'll add graphs as I go trough different tests but as you can see it is all rather slow as I'm doing 1step/sec
