Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More than SM2/3 #28

Open
marcfir opened this issue Feb 7, 2025 · 5 comments
Open

More than SM2/3 #28

marcfir opened this issue Feb 7, 2025 · 5 comments

Comments

@marcfir
Copy link
Contributor

marcfir commented Feb 7, 2025

Hi Robert,
I play with a EL2912 which has more than multiple SyncManagers for Inputs and Outpus.
I adapted this to check all SMs

for (osal_uint32_t sm_idx = 2u; sm_idx <= 3u; ++sm_idx) {

But I get an error. Any ideas?

2025-02-07T14:16:20.047Z INFO  [libethercat_rs::master] PREOP_2_SAFEOP      : slave  9: configuring actiavtion reg. 7, cycle_times 1000000/0, cycle_shift 0
2025-02-07T14:16:20.048Z INFO  [libethercat_rs::master] DC_SYNC             : slave  9: dc_systime 0.722614480 s, dc_start 1.721614680 s, slv dc_time 0.0 s
2025-02-07T14:16:20.048Z INFO  [libethercat_rs::master] DC_SYNC             : slave  9: cycletime_0 1000000, cycletime_1 0, dc_active 7
2025-02-07T14:16:20.048Z INFO  [libethercat_rs::master] PREOP_2_SAFEOP      : slave  9: sm2, adr 0x1200, len   8, flags 0x00010064
2025-02-07T14:16:20.048Z INFO  [libethercat_rs::master] PREOP_2_SAFEOP      : slave  9: sm3, adr 0x1D00, len   9, flags 0x00010020
2025-02-07T14:16:20.049Z INFO  [libethercat_rs::master] PREOP_2_SAFEOP      : slave  9: sm4, adr 0x2E00, len   0, flags 0x00000024
2025-02-07T14:16:20.049Z INFO  [libethercat_rs::master] PREOP_2_SAFEOP      : slave  9: sm5, adr 0x2F00, len   0, flags 0x00000020
2025-02-07T14:16:20.049Z INFO  [libethercat_rs::master] PREOP_2_SAFEOP      : slave  9: sm6, adr 0x2FFA, len   1, flags 0x00010020
2025-02-07T14:16:20.049Z INFO  [libethercat_rs::master] PREOP_2_SAFEOP      : slave  9: log0 0x00010012/0/7, len   8, phys 0x1200/0, type 2, active 1
2025-02-07T14:16:20.050Z INFO  [libethercat_rs::master] PREOP_2_SAFEOP      : slave  9: log1 0x00010012/0/7, len   9, phys 0x1D00/0, type 1, active 1
2025-02-07T14:16:20.050Z INFO  [libethercat_rs::master] PREOP_2_SAFEOP      : slave  9: log2 0x0001001B/0/7, len   1, phys 0x2FFA/0, type 1, active 1
2025-02-07T14:16:20.050Z INFO  [libethercat_rs::master] PREOP_2_SAFEOP      : slave  9: log3 0x09000000/4/4, len   1, phys 0x080D/3, type 1, active 1
2025-02-07T14:16:20.051Z INFO  [libethercat_rs::master] PREOP_2_SAFEOP      : slave  9: SAFE-OPERATIONAL state requested
2025-02-07T14:16:20.051Z INFO  [libethercat_rs::master] PREOP_2_SAFEOP      : slave  9: state switch to 4 failed, alstatcode 0x001D : invalid sync manager out config
@marcfir
Copy link
Contributor Author

marcfir commented Feb 7, 2025

slv->sm[sm_idx].flags = (sm_idx == 2u) ? 0x10064u : 0x10020u;

I think this is the problematic line. Commenting out the line solves the problem.

I don't understand what this line is supposed to do.
Obviously it writes the flags for the SM.
The flags are (according to ETG.2010) Control Register, Status Register, Enable Synch Manager and Synch Manager Type in a single uint32?
So the status register is set to 0x10064 for output SM2 or 0x10020 for input SM3. Is this correct?
Looping through all SMs does not work for this line but still I don't understand the hex-values.
I assume the SM is initially loaded from the EEPROM and the EEPROM should already have the correct types?
Why force them to these values?

@robert-wm
Copy link
Collaborator

The intention to this was, that with CoE usually 0x1C12 maps outputs via SM2 and 0x1C13 maps inputs via SM3.

You're right, the 32-bit value represents control, status, enable and type. Maybe we should split this for better readability.

0x10064 means:
0x64 -> Control (Direction 0x04: Write, Interrupt ALEvent 0x20, Watchdog trigger enable 0x40)
0x00 -> Status
0x01 - > Activate (Sync Manager Enable)

0x10020 means:
0x20 -> Control (Direction 0x00: Read, Interrupt ALEvent 0x20)
0x00 -> Status
0x01 - > Activate (Sync Manager Enable)

I don't have a EL2912 (maybe i should order one). According to the ESI-XML it uses the following config:

<Fmmu Sm="2" Su="0">Outputs</Fmmu>
<Fmmu Sm="3" Su="0">Inputs</Fmmu>
<Fmmu>MBoxState</Fmmu>
<Fmmu Sm="4" Su="1">Outputs</Fmmu>
<Fmmu Sm="5" Su="1">Inputs</Fmmu>
<Fmmu Sm="6" Su="2">Outputs</Fmmu>
<Sm MinSize="256" MaxSize="256" DefaultSize="256" StartAddress="#x1000" ControlByte="#x26" Enable="1">MBoxOut</Sm>
<Sm MinSize="256" MaxSize="256" DefaultSize="256" StartAddress="#x1100" ControlByte="#x22" Enable="1">MBoxIn</Sm>
<Sm DefaultSize="7" StartAddress="#x1200" ControlByte="#x24" Enable="1">Outputs</Sm>
<Sm DefaultSize="9" StartAddress="#x1d00" ControlByte="#x20" Enable="1">Inputs</Sm>
<Sm DefaultSize="0" StartAddress="#x2e00" ControlByte="#x24" Enable="0">Outputs</Sm>
<Sm DefaultSize="0" StartAddress="#x2f00" ControlByte="#x20" Enable="0">Inputs</Sm>
<Sm DefaultSize="2" StartAddress="#x2ffa" ControlByte="#x24" Enable="1">Outputs</Sm>

So additionally there are also more FMMUs used. Can you tell me how the mapping should be generated here?

@robert-wm
Copy link
Collaborator

robert-wm commented Feb 10, 2025

in addition to the usual Rx/Tx PDO mapping assignment indices (0x1C12,0x1C13) they use further mapping assignments:

<Index>#x1c12</Index>
<Name>RxPDO assign</Name>

Index>#x1c13</Index>
<Name>TxPDO assign</Name>

<Index>#x1c14</Index>
<Name>PROFIsafe RxPDO assign</Name>

<Index>#x1c15</Index>
<Name>PROFIsafe TxPDO assign</Name>

<Index>#x1c16</Index>
<Name>STDOUT RxPDO assign</Name>

So there's more work to do to generate mapping over these indices, programm additional FMMUs and SMs.

@robert-wm
Copy link
Collaborator

robert-wm commented Feb 10, 2025

Also we need to evaluate 0x1C00 to determine the type (mailbox, read, write) of every sync manager. Then we could also replace the hardcoded settings values from above (0x10064...)

@marcfir
Copy link
Contributor Author

marcfir commented Feb 10, 2025

Ah, I see. I was confused about the byte order of the u32. So yes, splitting it up would make it easier to read.
I will do a little PR.
So for the control register, do we have to use the info from the ESI file or are there "defaults"? Assuming we have an ENI or somehow the config from the ESI, how do we pass the info down?
Can we split it into info provided via ESI/ENI and some defaults? Because the current code just sets 0x64 for SM2 and 0x20 for SM3 which seems to work fine in general?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants