Stepper precision +-5%

arhi

Would ship from germany -> is there any reliable parcel service like UPS or DPD that would work?

dhl, dhl-express, fedex, ups ... they all work but can be rather expensive, I have best experiences with fedex so far ... we are "so close but so far away" ... EU all around us and we are the hole in the middle .. would be rather easy to organize the shipment in "normal times" as ton of ppl normally go from de to rs every day but due to the known issues we face now that transfer of ppl is not there any more... I'll ask around if I can find someone arriving soon but since holidays are "in progress" I think most who planned to arrive are already here, if I knew few weeks ago...

anyhow I have often access to these (and similar) encoders so we can do it in second batch if not now

arhi

@JoergS5 said in Stepper precision +-5%:

I read somewhere that half steps are even more precise than the full steps.

not sure how half step can be "more precise" than full step, but "same" might work... def way more precise than microsteppings. I was doing some halfstep+gearing on one mill platform (nema23 motors) and I didn't like it too much, while precision is much better than with microstepping (especially on those 3Nm motors where microstepping was heavily grouping around half and full step) the sound was terrible (imno 3-4times more loud than with microstepping) and there was a lot of vibrations during acceleration, took me a looooooooong time to configure the accel curve to get rid of vibrations... I had no backlash that I could measure on that machine (double ballnut for bot x and y and 30mm wide 5mm pitch belt between motor and ballscrew)

JoergS5

@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.

A Former User

@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

mendenmh

@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.

JoergS5

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.

A Former User

@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...

arhi

@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

JoergS5

@arhi thank you!

Improving precision is a continuous process, so take your time. Unfortunately, I don't know Profibus yet, I cannot help you.

mendenmh

@arhi There seems to be a python package which can be a profibus master:

https://pypi.org/project/pyprofibus/

arhi

@mendenmh thanks that's awesome, testing immediately

arhi

@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)

arhi

@mendenmh said in Stepper precision +-5%:

@arhi There seems to be a python package which can be a profibus master:

https://pypi.org/project/pyprofibus/

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

mendenmh

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.

arhi

@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