rene-dev
How to deal with different encoder type with the same protocol?
I made a custom hardware based on the stmbl V4, and I managed it to work with Yaskawa servomotor. As my servomotor use 13bit incremental encoder instead of 16bits absolute encoder, the received frame data from this encoder is different, and contain more interesting data field like the Hal sensors state, compensation data and status bit that indicate if this last field is valid or no.
position 7: one bit indicate if Z index has been observed at least once since powering up the encoder, this is used to indicate if the compensation data is valid, ( 1: data not valid, 0: data is valid ) the absolute shaft angle can be calculated by subtract the compensation data from the incremental position data counter.
Position 58, 59 and 60 are the Hal sensors state ( U, V, and W ), can take six value (2, 3,1, 5, 4 and 6 ) this sequence repeat 3 times per revolution ( All Sigma II SGMAH series are 3 pole-pairs motors ) this signal can be used to do initial phasing without enabling auto-phasing feature .
Position 67: 13 bits of incremental position data.
position 81: 11 bits of compensation data ( need to be 2bits left shifted if used as absolute offset from Z index)
My question is how to deal with this kind of situation, 16bits absolute, 17bits incremental, 13bit incremental or absolute, 20bit and higher for Sigma III and Sigma V.. and the same situation with Mitsubishi encoders.
Is it doable to make each encoder type in separate .COMP file and rename it some thing like:
"Yaskawa_13b_inc.comp", "Mitsubishi_17b_abs.comp"...
or may be use only one .comps file that can handle all types but in this case each protocol must have sub-non-volatile parameter to indicate how to decode data frame.
Here a .comp file that handle Yaskawa Sigma II 13bits incremental encoder ( SGMAH series ) using FB0_45 ( some optimization still to be done ) and the config file for SGMAH-04-AAA .
yaskawa_13b_inc_FB0_45.txt Yaskawa_SGMAH-04AAA.txt
We don't have a good solution for protocol variants or hw instances yet. There are multiple options:
-
multiple comps (one / variant, see enc_fb.comp and enc_cmd.comp) "+" fast "-" code duplication
-
preprocessor switch in comp "+" fast "-" ugly code "-" config at compile time
-
runtime switch in comp "+" config at runtime "-" slow
-
load time switch in comp (bend function pointers in RT_INIT) "+" fast "-" needs a lot "setup" code (could be implemented in HAL)
-
multiple comps (hw, protocol, interpretation) "+" separation of concerns "-" runtime overhead "-" communication is limited to float or float[] "-" complex HAL graph
Currently i would prefer option 4 with better support in HAL.
The Mesa BiSS / SSI etc functions handle this using a string parameter that encodes the number of bits and their HAL pin names: http://linuxcnc.org/docs/2.7/html/man/man9/hostmot2.9.html#Synchronous Serial Interface (SSI) This might have too much overhead for STMBL, however. It re-uses the code that allows smart-serial devices to choose their own pin-names and types.
good idea, but our hal implementation cannot do that. components and their pins are fixed at compiletime. I also support option 4.
Components and pins used to be fixed at compile-time in LinuxCNC too. I had to change that to support smart-serial. It's just a matter of keeping the pins in a Union with a type code: https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/drivers/mesa-hostmot2/sserial.c#L1385 But I did mention that I thought there might be too much overhead for STMBL.
This isn't related to the issue, but sacidu93, do you have information on the sigma-V protocols? The project I wasn't to use the STMBL on I need to read some existing Yaskawa sigma-V motors for position information. Can you point me to information on reading the encoder data?
Hello, first of all thank you for your project
Does this project support the 22-bit encoder in the picture?
https://www.google.com/imgres?imgurl=http%3A%2F%2Fimg30.360buyimg.com%2Fimgzone%2Fjfs%2Ft1%2F58475%2F25%2F2185%2F118223%2F5d021e66E6c388d4e%2F2822882d565505a9.jpg&imgrefurl=https%3A%2F%2Fi-item.jd.com%2F50031585455.html&tbnid=DC6OU_J7Sk47SM&vet=12ahUKEwiDk6376KHtAhUIZ5QKHUHuDJEQMygKegUIARCmAQ..i&docid=HXahkNw1rqnPeM&w=750&h=460&q=%E9%95%BF%E6%98%A522%E4%BD%8D%E7%BC%96%E7%A0%81%E5%99%A8&ved=2ahUKEwiDk6376KHtAhUIZ5QKHUHuDJEQMygKegUIARCmAQ
Ok thanks for your reply
Nico Stute [email protected] 于2020年11月27日周五 下午5:44写道：
@HUANGJIN169 https://github.com/HUANGJIN169 that's an incremental encoder with 2500 pulses per revolution
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rene-dev/stmbl/issues/58#issuecomment-734744587, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALJJK7R2RDJIKMDN7CH5QALSR5YHHANCNFSM4C652DTA .
Hello there Can this driver board flash other firmware? For example, MMOS ffb simulation racing force feedback firmware
Servo Sim Racing [email protected] 于2020年11月27日周五 下午8:28写道：
Ok thanks for your reply
Nico Stute [email protected] 于2020年11月27日周五 下午5:44写道：
@HUANGJIN169 https://github.com/HUANGJIN169 that's an incremental encoder with 2500 pulses per revolution
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rene-dev/stmbl/issues/58#issuecomment-734744587, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALJJK7R2RDJIKMDN7CH5QALSR5YHHANCNFSM4C652DTA .
I want to use this drive board to imitate the analog racing control drive board The following is my project and MMOS ffb force feedback simulation racing car: https://hackaday.io/project/168801-diy-mmos-ffb-stm32-and-servo-drive-servo-motor MMOS firmware: https://forum.virtualracing.org/showthread.php/92420
Servo Sim Racing [email protected] 于2020年11月27日周五 下午8:44写道：
Hello there Can this driver board flash other firmware? For example, MMOS ffb simulation racing force feedback firmware
Servo Sim Racing [email protected] 于2020年11月27日周五 下午8:28写道：
Ok thanks for your reply
Nico Stute [email protected] 于2020年11月27日周五 下午5:44写道：
@HUANGJIN169 https://github.com/HUANGJIN169 that's an incremental encoder with 2500 pulses per revolution
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rene-dev/stmbl/issues/58#issuecomment-734744587, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALJJK7R2RDJIKMDN7CH5QALSR5YHHANCNFSM4C652DTA .
Yes you could flash other firmware, but you have to modify it. MMOS ffb will not run out of the box. You can use STMBL to drive the motor and run stock MMOS ffb on a different board.
good idea, but our hal implementation cannot do that. components and their pins are fixed at compiletime. I also support option 4.
Hi sir it posible to modif the hardware sir? I want to used only main board with stm32f4, i just want to used arount 40-60v dc input sir. Or that need modif the frimeware also?
