crinq
commented
7 years ago 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.
andypugh
rene-dev
corrylaz
HUANGJIN169
artayasa
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