Stepper precision +-5%
-
@arhi said in Stepper precision +-5%:
not sure how half step can be "more precise" than full step,
the mode was half step and the positions alternate full step and half step. The half step positions were said to be better. If I remember right, the magnetic forces were higher for them. (only slightly)
Maybe http://users.ece.utexas.edu/~valvano/Datasheets/StepperHalfstep.pdf page two torque variations and higher current at the half step positions.
-
@JoergS5 said in Stepper precision +-5%:
@LB said in Stepper precision +-5%:
might be wise to use also half-steps si
I read somewhere that half steps are even more precise than the full steps. Torque is a different matter. I don't find the source of the information.
I guess what you are referring to might be (please look up here https://www.zaber.com/w/Microstepping_Tutorial) :
old wave-stepping for full-stepping with only 1 phase on of course is torque-wise inferior to full-stepping with 2 phase on. So regarding the springiness of a position you would of course use 2-phase-on-fullstepping nowadays
BUT
If you use that with microstepping interpolation you get a "torque-square" on 1 full Β° electric rotation (4 full steps for a 2phase stepper) -> Most modern drivers DO NOT use that any more but rather have a "circular-torque" distribution for 1 electrical rotation (4 full steps for a 2phase stepper). People rather tend to go "torque-true" instead of an uneven torque-max, which makes sense in terms of vibrations/jitter or whatever you wanna call it.
The benefit of having an even torque will be the smoother run and that is part of the accuracy discussion here.
If the application needs higher torque I would rather go for a bigger motor then having an uneven torque distribution
Edit: Typed this when you already replied, but the BUT section might be of interest for you
-
@JoergS5 Old stepper drivers that only did full and half step operations ran both coils at full current on the half steps. That might have resulted in better positioning, but the motors got hot as hades if you left them parked there. Modern sine/cosine microstepping drivers would have slightly higher (sqrt(2)) total current, split between the two windings, at the half step, but I would be surprised if this would be enough to really compensate for being away from the poles.
-
You are probably both right, modern steppers and drivers will have changed all. The document I found seems to be very old.
Maybe the best approach is to build a test station, measure and compare different solutions, then select the best for the requirement. I wished there were better books about measuring. I have problems finding good sources how to use dial gauges etc.
-
@arhi said in Stepper precision +-5%:
anyhow I have often access to these (and similar) encoders so we can do it in second batch if not now
Sounds good - letΒ΄s wait for a time to do this when almost nobody speaks any more about coron...
-
@JoergS5 said in Stepper precision +-5%:
BTW think of me at 11th, this is my birthday.
happy birthday
Unfortunately, I did not do anything with this yet. I managed to find some code that simulates profibus slave but I'm having issues making code that simulates master in order to talk with this encoder. My profibus adapter is missing, ordered a new one but I doubt it will arrive quickly (not yet sent by the seller)... Still working on getting the master code to work but I have to slow down since today as ... work
-
@arhi thank you!
Improving precision is a continuous process, so take your time. Unfortunately, I don't know Profibus yet, I cannot help you.
-
@arhi There seems to be a python package which can be a profibus master:
-
@mendenmh thanks that's awesome, testing immediately
-
@JoergS5 said in Stepper precision +-5%:
Improving precision is a continuous process, so take your time.
yeah but I can't keep the encoder indefinitely .. this one will have to go back in a week or two ... I'll get another one next time they get a new order for few weeks again but it's not something I have on a shelf forever (these things go into some nasty military equipment made to do some ugly military stuff)
-
@mendenmh said in Stepper precision +-5%:
@arhi There seems to be a python package which can be a profibus master:
I have some data out of the encoder
PS D:\dev\profibus\pyprofibus> python3.8.exe .\arhi_readencoder.py bytearray(b'\x00\x00\xa4\xc8') bytearray(b'\x00\x00\xa4\xc8') bytearray(b'\x00\x00\xa4\xc8') bytearray(b'\x00\x00\xa4\xc8') bytearray(b'\x00\x00\xa4\xc8') bytearray(b'\x00\x00\xa4\xc8') bytearray(b'\x00\x00\xa4\xc8') bytearray(b'\x00\x00\xa7\x19') bytearray(b'\x00\x00\xb1f') bytearray(b'\x00\x00\xb5E') bytearray(b'\x00\x00\xb9\xc3') bytearray(b'\x00\x00\xbdJ') bytearray(b'\x00\x00\xc4\x87') bytearray(b'\x00\x00\xcb\x89') bytearray(b'\x00\x00\xd3\xd0') bytearray(b'\x00\x00\xd6/') bytearray(b'\x00\x00\xe1E') bytearray(b'\x00\x00\xeby') bytearray(b'\x00\x00\xf7\xe7') bytearray(b'\x00\x00E\x9f') bytearray(b'\x00\x00x\xd5') bytearray(b'\x00\x00\x97\x89') bytearray(b'\x00\x00\x97i') bytearray(b'\x00\x00\x97i') bytearray(b'\x00\x00\x97i') bytearray(b'\x00\x00\x97i') Traceback (most recent call last): File ".\arhi_readencoder.py", line 65, in <module> sys.exit(main()) File ".\arhi_readencoder.py", line 41, in main handledSlaveDesc = master.run() File "D:\dev\profibus\pyprofibus\pyprofibus\dp_master.py", line 714, in run if self.debug: KeyboardInterrupt PS D:\dev\profibus\pyprofibus>
it changes when I rotate the shaft and it's different if I select 13bit and 16bit singleturn "module" so .. hopefully that's that ... now to use this numbers somehow and connect step pin with this code, will probbly need to move this to a pi or something else with gpio
I'm not the python person, need to figure out wth is
\x97i
and\xbdJ
and why I have in byte array value like\xb5E
-
So, if you look up the 'struct' module, I think struct.unpack on those, assuming they are big-endian 4-byte integers will convert them. The funny mixture of backslash codes and regular characters is because some of the return values fall in the printable ascii character set, and get printed normally, which others fall outside and get printed as a hex byte preceded by a backslash.
-
@mendenmh thanks, I see it now, it does not print bytearray always as bytes but will output hex only for non-printable chars .. interesting .. anyhow, I'm moving this to RPI or OPI today so that I can add a "step" function to it so I can record a full circle data