How to deal with different encoder type with the same protocol? #58
Comments
|
We don't have a good solution for protocol variants or hw instances yet. There are multiple options:
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: |
|
good idea, but our hal implementation cannot do that. |
|
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: |
|
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 |
|
@HUANGJIN169 that's an incremental encoder with 2500 pulses per revolution |
|
Ok thanks for your reply
Nico Stute <notifications@github.com> 于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
<#58 (comment)>, 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 <huangjin169@gmail.com> 于2020年11月27日周五 下午8:28写道：
… Ok thanks for your reply
Nico Stute ***@***.***> 于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
> <#58 (comment)>, 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 <huangjin169@gmail.com> 于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 ***@***.***> 于2020年11月27日周五 下午8:28写道：
> Ok thanks for your reply
>
> Nico Stute ***@***.***> 于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
>> <#58 (comment)>,
>> 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. |
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? |
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
The text was updated successfully, but these errors were encountered: