State Transition and SDO Write Timeouts with ELM3604-0002

[tdehaeze]

Thanks for creating EtherCrab! Really appreciate having such a well-documented Rust implementation for EtherCAT :)

Please note that I am a beginner with Rust (that I want to learn for a long time). So I might do stupid mistakes.

My goal

Acquire voltage values (1ms sampling time) from ELM3604 and store in .txt file (for my PhD thesis).
Do you think Ethercrab is a good fit for my simple need?

Setup

• Hardware: EK1100 + ELM3604-0002
• Master: Raspberry Pi 4 (Linux raspberrypi 6.6.51)
• Branch: master

Issues Encountered

1. SDO Write Timeout but Successful Operation

subdevice.sdo_write(0x8000, 0x01, 100u16).await?;

• This operation always returns a timeout error
• However, subsequent sdo_read on the same address confirms the write was successful
• In contrast, SyncManager configuration works without timeout:

  subdevice.sdo_write(0x1c12, 0, 0u8).await?;

Do you have any idea why I have these timeout?

2. State Transition Timeout Despite Successful Transition

let group = group.into_safe_op(&maindevice).await.expect("PRE-OP -> SAFE-OP");

Output:

[2025-02-19T09:02:21Z DEBUG ethercrab::subdevice_group] Waiting for group state Safe-Operational
thread 'main' panicked at examples/ek1100.rs:134:50:
PRE-OP -> SAFE-OP: Timeout

However, the EK1100's LED indicates it is in SAFE-OP state.
Note that I only need SAFE-OP (I don't have "outputs", only "inputs"), and not OP, but I got the same error when trying to go to OP.
Do you have any idea about the issue?

[jamwaffles]

Thanks for the kind words and well described issue :). To answer one of your questions straight up:

Do you think Ethercrab is a good fit for my simple need?

Yes! EtherCrab is deployed in far more complex systems so it'll be fine for your use case.

Before I write out some things to try, could you please upload here a Wireshark capture of another run that exits with the same errors? This will help me debug timing issues and other failures. You can use tshark from another terminal, e.g.

tshark -w ./ethercrab.pcapng --interface eth0 -f 'ether proto 0x88a4'

(might need sudo)

[tdehaeze]

Awesome ! This is a great project for me to start learning Rust more seriously :)

It's good that Wireshark is able to "decode" EtherCAT frames.

Please find attached the rust example I tried to run (I modified it a little bit to adapt to the ELM3604):

ek1100.txt

And the wireshark capture:

ethercrab.txt

[tdehaeze]

I ran another test that includes the SDO write command subdevice.sdo_write(0x8000, 0x01, 100u16).await?; (that I commented for the last test).

The wireshark output is here attached:

ethercrab_bis.txt

and the debug output is:

rust_output.txt

[jamwaffles]

My best guess right now is that the ELM3604 is just a bit slow to confirm the write in the mailbox response, so it might be setting the value, but EtherCrab times out waiting for the report that the value was updated. In your Timeouts config, can you please try adding mailbox_echo: Duration::from_millis(1000)? By default it's 100ms, so this is 10 times longer. This is the timeout that's being hit as shown in your most recent Wireshark trace.

As for the device not going into SAFE-OP, this is likely due to misconfigured PDO mappings. Please try:

1. Powering off the EtherCAT devices
2. Commenting out all the code that writes to 0x1c12 or 0x1c13 so the device uses its factory defaults
3. Powering on the devices
4. Running the test program again

More Wireshark captures appreciated if none of this works :)

[tdehaeze]

Increasing the timeout to 1s resolved the issue, thanks !

Regarding the device reporting not going to SAFE-OP, I was wrong by saying that the LED was reporting SAFE-OP.
It was the case for the EK1100, but not for the ELM3604 for which the LED reports PRE-OP.
I confirmed that by looking in Wireshark, the ELM3604 well reports its PRE-OP state and never goes into SAFE-OP.

I tried with a EL3702 module, and it worked out of the box ! (the module went into SAFE-OP and I got no error)

I then looked at the documentation of the ELM3604 to see it some configuration needs to be done before going into SAFE-OP.
The following "modes" supported by the module are:

DistributedClocks: min. 100 µs, max. 10 ms
FrameTriggered/Synchron: min. 200 µs, max. 100 ms
FreeRun: not yet supported

Therefore, I think I have the issue because I don't properly configure the "Synchrotrous mode" or the "distributed clock".
Distributed clock seems complicated to configure, and I don't really need it as I only have one device.
I then tried to use the Synchronous with SM event operation mode.

By using the following code to check the current configuration of the device:

let sync_type = subdevice.sdo_read::<u16>(0x1c33, 1).await?;
let cycle_time = subdevice.sdo_read::<u32>(0x1c33, 2).await?;
let min_cycle_time = subdevice.sdo_read::<u32>(0x1c33, 5).await?;
let supported_sync_modes = subdevice.sdo_read::<SupportedModes>(0x1c33, 4).await?;
log::info!("--> sync mode {sync_type}, cycle time {cycle_time} ns (min {min_cycle_time} ns), {supported_sync_modes:?}");

I got:
--> Inputs sync mode 2, cycle time 1000000 ns (min 100000 ns), supported modes SupportedModes { free_run: false, sm2: true, dc_supported: true, sync1: false, dynamic: false }

I suppose this is what I want: 1ms cycle time using SM event.

But it is still not going into SAFE-OP, and I don't know if I should configure something else to make it work.
Can I have some information about why the device does not go into SAFE-OP?

[tdehaeze]

And here are the rust program used and the wireshark logs:

ek1100.txt
ethercrab.txt

[tdehaeze]

After some more investigations, I decided to start with the simpler EL3702 module (two analog inputs, +/-10V, 16bits).
I can reach OP state with the ek1100 example, and I captured frames with wireshark.
I could see the LRW commands with 12 bytes of data (which is expected from the EL3702 documentation), but all data were zeros.

The EL3702 XML description shows two TxPDOs that I want to acquire:

<TxPdo Fixed="1" Sm="0" OSFac="20" OSMin="1" OSMax="100" OSIndexInc="16" Su="0">
    <Index>#x1a00</Index>
    <Name>Ch1 Sample</Name>
    <Entry>
        <Index>#x6000</Index>
        <SubIndex>1</SubIndex>
        <BitLen>16</BitLen>
        <Name>Ch1 Value</Name>
        <DataType DScale="+/-10">INT</DataType>
    </Entry>
</TxPdo>
<TxPdo Fixed="1" Sm="1" OSFac="20" OSMin="1" OSMax="100" OSIndexInc="16" Su="1">
    <Index>#x1a80</Index>
    <Name>Ch2 Sample</Name>
    <Entry>
        <Index>#x6000</Index>
        <SubIndex>2</SubIndex>
        <BitLen>16</BitLen>
        <Name>Ch2 Value</Name>
        <DataType DScale="+/-10">INT</DataType>
    </Entry>
</TxPdo>

I tried to find an example in ethercrab where some input data are acquired cyclically, but I could not find.

I did read this issue, and more particularly your comment, but I am not sure if this is relevant for me and how to implement it in my case.

I tried to understand a bit more by looking the logs bellow.
It seems that ethercrab looked in the EEPROM to determine the size of PDO and PDI, which seems correct.

[2025-02-20T09:21:02Z DEBUG ethercrab::subdevice::eeprom] Discovered sync managers:
    [
        SyncManager {
            start_addr: 0x1000,
            length: 0x0000,
            control: Control {
                operation_mode: Normal,
                direction: MasterRead,
                ecat_event_enable: false,
                dls_user_event_enable: true,
                watchdog_enable: false,
            },
            enable: SyncManagerEnable(
                ENABLE,
            ),
            usage_type: ProcessDataRead,
        },
        SyncManager {
            start_addr: 0x1400,
            length: 0x0000,
            control: Control {
                operation_mode: Normal,
                direction: MasterRead,
                ecat_event_enable: false,
                dls_user_event_enable: true,
                watchdog_enable: false,
            },
            enable: SyncManagerEnable(
                ENABLE,
            ),
            usage_type: ProcessDataRead,
        },
        SyncManager {
            start_addr: 0x0998,
            length: 0x0000,
            control: Control {
                operation_mode: Normal,
                direction: MasterRead,
                ecat_event_enable: false,
                dls_user_event_enable: false,
                watchdog_enable: false,
            },
            enable: SyncManagerEnable(
                IS_VIRTUAL,
            ),
            usage_type: ProcessDataRead,
        },
    ]
[2025-02-20T09:21:02Z DEBUG ethercrab::subdevice::eeprom] Discovered FMMUs:
    [
        Inputs,
        Inputs,
        Inputs,
        Unused,
    ]
[2025-02-20T09:21:02Z DEBUG ethercrab::subdevice::configuration] SubDevice 0x1001 has CoE: false
[2025-02-20T09:21:02Z DEBUG ethercrab::subdevice::eeprom] FMMU mappings: [
        FmmuEx {
            sync_manager: 255,
        },
        FmmuEx {
            sync_manager: 254,
        },
        FmmuEx {
            sync_manager: 0,
        },
        FmmuEx {
            sync_manager: 2,
        },
    ]
[2025-02-20T09:21:02Z DEBUG ethercrab::subdevice::configuration] SubDevice 0x1001 PDI inputs: PdiSegment { bytes: 0..12 } (12 bytes), outputs: PdiSegment { bytes: 12..12 } (0 bytes)
[2025-02-20T09:21:02Z DEBUG ethercrab::subdevice_group] SubDevice FMMUs configured for group. Able to move to SAFE-OP
[2025-02-20T09:21:02Z DEBUG ethercrab::subdevice_group] Group PDI length: start 0x00000000, 12 total bytes (12 input bytes)
[2025-02-20T09:21:02Z DEBUG ethercrab::subdevice] Set state Safe-Operational for SubDevice address 0x1000
[2025-02-20T09:21:02Z DEBUG ethercrab::subdevice] Set state Safe-Operational for SubDevice address 0x1001
[2025-02-20T09:21:02Z DEBUG ethercrab::subdevice_group] Waiting for group state Safe-Operational
[2025-02-20T09:21:02Z DEBUG ethercrab::subdevice_group] --> Group reached state Safe-Operational
[2025-02-20T09:21:02Z DEBUG ethercrab::subdevice] Set state Operational for SubDevice address 0x1000
[2025-02-20T09:21:02Z DEBUG ethercrab::subdevice] Set state Operational for SubDevice address 0x1001
[2025-02-20T09:21:02Z DEBUG ethercrab::subdevice_group] Waiting for group state Operational
[2025-02-20T09:21:02Z DEBUG ethercrab::subdevice_group] --> Group reached state Operational

What should I do to effectively get the data?
It is the SyncManagers that are not properly configured? FMMUs?

Thanks a lot, and sorry for my poor understand of the etherCAT protocol (software like TwinCAT does all the hard work for you...)

[jamwaffles]

Increasing the timeout to 1s resolved the issue, thanks !

Great! I'm glad that part is an easy fix at least :)

Distributed clocks aren't too difficult to set up in EtherCrab. Have you looked at the dc example? It has a bunch of cruft in it for debug logging to CSV, etc, but it can be cleaned up quite significantly. It might be worth trying the ELM module with that example to see if you get any further. However...

Can I have some information about why the device does not go into SAFE-OP?

... this bit will probably still be an issue. You need to make sure the SubDevice is configured correctly for it to transition state, and it will give you no information as to what you got wrong other than just refusing to go into SAFE-OP and timing out. If you can look at TwinCAT and see what parameters it writes, that would be a good place to start - you should be able to reimplement the config in EtherCrab. You can find this in the Process Data tab, i.e. this window:

I decided to start with the simpler EL3702 module

Good idea! It's good that at least this device is going into OP.

What should I do to effectively get the data?

I'm... not really sure. If it's going into OP and giving the correctly sized PDI then I feel like it should be reading non-zero data. Do you have any sensors connected? Maybe it's defaulting to zeros if it doesn't detect any attached hardware? These devices also support oversampling which I haven't looked into yet, but could be causing more problems if it defaults to an oversampling mode.

I also looked at the EL3702 ESI file and it seems to only support DC sync modes, but this is odd considering it goes into OP without configuring DC sync. This could be a cause for the zeroed data.

I'm afraid I don't have an EL3702 or similar to test with, but please send me any progress you make and/or Wireshark captures which might help. If you have spare hardware you want to ship to the UK, I'd be happy to help debug your setup with hardware in hand.

Finally, if you'd rather have a more realtime chat, do head on over to the EtherCrab Matrix room and/or send me a DM.

[jamwaffles]

P.s.

Thanks a lot, and sorry for my poor understand of the etherCAT protocol (software like TwinCAT does all the hard work for you...)

No problem at all! EtherCAT has a lot of moving parts and is nicely abstracted away by most MainDevice implementations which makes it difficult to learn.

[jamwaffles]

Hey @tdehaeze, just thought I'd check in on this issue. Did you manage to make any progress?

[tdehaeze]

Hi @jamwaffles ,
I did some more tests last week, but I could not get any data.
I was planning to try again this weekend, and post some updates here.
I have also joint the Matrix room :)

[tdehaeze]

I could do further tests, but I still cannot get any analog input data.

I now have one EL4732 (two +/-10V analog outputs) and one EL3702 (two +/- 10V analog inputs).
I modified the DC example, and I could reach OP state.
However, when I try to get the analog inputs in ethercrab, I only have zeros.
Same for analog outputs, I try to set some values but I always get 0V at the output.

However, the number of bytes for inputs and outputs seems correct and it do corresponds to the documentation.
It is just that I get zeros despite the OP state.

        loop {
            let now = Instant::now();

            let response @ TxRxResponse {
                working_counter: _wkc,
                extra:
                    CycleInfo {
                        dc_system_time,
                        next_cycle_wait,
                        cycle_start_offset,
                    },
                ..
            } = group.tx_rx_dc(&maindevice).await.expect("TX/RX");

            // Debug logging
            {
                let cycle_start_offset = cycle_start_offset.as_nanos() as u64;

                let stat = ProcessStat {
                    ecat_time: dc_system_time,
                    next_iter_wait: next_cycle_wait.as_nanos() as u64,
                    cycle_start_offset,
                };

                if print_tick.elapsed() > Duration::from_secs(1) {
                    print_tick = Instant::now();
                }

                process_stats.serialize(stat).ok();
            }

            log::info!("Status: {:?}", response.group_state());

            for subdevice in group.iter(&maindevice) {
                if subdevice.name().contains("EL4732") {
                    let mut o = subdevice.outputs_raw_mut();
                    log::info!("EL4732 output data length: {:}", o.len());
                    // Set voltage outputs
                    let adc_value = (((3.5 / 10.0) * 32767.0 + 32768.0) as u16).min(65535);
                    o[2..4].copy_from_slice(&adc_value.to_le_bytes());
                    let adc_value = (((-3.5 / 10.0) * 32767.0 + 32768.0) as u16).min(65535);
                    o[6..8].copy_from_slice(&adc_value.to_le_bytes());
                } else if subdevice.name().contains("EL3702") {
                    let io = subdevice.io_raw();
                    log::info!("EL3702 complete input data: {:02X?}", io.inputs());
                }
            }

            smol::Timer::at(now + next_cycle_wait).await;

            // Hook signal so we can write CSV data before exiting
            if term.load(Ordering::Relaxed) {
                log::info!("Exiting...");

                process_stats.flush().ok();

                break;
            }
        }

Only the last 4 bytes are not zeros and are corresponding to DCoutputshift and DCinputshift.

In terms of DC configuration, I only did:

subdevice.set_dc_sync(DcSync::Sync0);

Here the the log output:

[2025-03-05T18:08:43Z INFO  dc] Status: GroupState(OP)
[2025-03-05T18:08:43Z INFO  dc] EL4732 output data length: 8
[2025-03-05T18:08:43Z INFO  dc] EL3702 complete input data: [00, 00, 00, 00, 00, 00, 00, 00, 00, 18, 67, F1]
[2025-03-05T18:08:43Z INFO  dc] Status: GroupState(OP)
[2025-03-05T18:08:43Z INFO  dc] EL4732 output data length: 8
[2025-03-05T18:08:43Z INFO  dc] EL3702 complete input data: [00, 00, 00, 00, 00, 00, 00, 00, 40, 63, B3, F1]
[2025-03-05T18:08:43Z INFO  dc] Status: GroupState(OP)
[2025-03-05T18:08:43Z INFO  dc] EL4732 output data length: 8
[2025-03-05T18:08:43Z INFO  dc] EL3702 complete input data: [00, 00, 00, 00, 00, 00, 00, 00, 80, AE, FF, F1]
[2025-03-05T18:08:43Z INFO  dc] Status: GroupState(OP)
[2025-03-05T18:08:43Z INFO  dc] EL4732 output data length: 8
[2025-03-05T18:08:43Z INFO  dc] EL3702 complete input data: [00, 00, 00, 00, 00, 00, 00, 00, C0, F9, 4B, F2]
[2025-03-05T18:08:43Z INFO  dc] Status: GroupState(OP)
[2025-03-05T18:08:43Z INFO  dc] EL4732 output data length: 8
[2025-03-05T18:08:43Z INFO  dc] EL3702 complete input data: [00, 00, 00, 00, 00, 00, 00, 00, 00, 45, 98, F2]
[2025-03-05T18:08:43Z INFO  dc] Status: GroupState(OP)
[2025-03-05T18:08:43Z INFO  dc] EL4732 output data length: 8
[2025-03-05T18:08:43Z INFO  dc] EL3702 complete input data: [00, 00, 00, 00, 00, 00, 00, 00, 40, 90, E4, F2]
[2025-03-05T18:08:43Z INFO  dc] Status: GroupState(OP)
[2025-03-05T18:08:43Z INFO  dc] EL4732 output data length: 8
[2025-03-05T18:08:43Z INFO  dc] EL3702 complete input data: [00, 00, 00, 00, 00, 00, 00, 00, 80, DB, 30, F3]
[2025-03-05T18:08:43Z INFO  dc] Status: GroupState(OP)
[2025-03-05T18:08:43Z INFO  dc] EL4732 output data length: 8
[2025-03-05T18:08:43Z INFO  dc] EL3702 complete input data: [00, 00, 00, 00, 00, 00, 00, 00, C0, 26, 7D, F3]
[2025-03-05T18:08:43Z INFO  dc] Status: GroupState(OP)
[2025-03-05T18:08:43Z INFO  dc] EL4732 output data length: 8
[2025-03-05T18:08:43Z INFO  dc] EL3702 complete input data: [00, 00, 00, 00, 00, 00, 00, 00, 00, 72, C9, F3]
[2025-03-05T18:08:43Z INFO  dc] Status: GroupState(OP)
[2025-03-05T18:08:43Z INFO  dc] EL4732 output data length: 8
[2025-03-05T18:08:43Z INFO  dc] EL3702 complete input data: [00, 00, 00, 00, 00, 00, 00, 00, 40, BD, 15, F4]
[2025-03-05T18:08:43Z INFO  dc] Status: GroupState(OP)
[2025-03-05T18:08:43Z INFO  dc] EL4732 output data length: 8
[2025-03-05T18:08:43Z INFO  dc] EL3702 complete input data: [00, 00, 00, 00, 00, 00, 00, 00, 80, 08, 62, F4]
[2025-03-05T18:08:43Z INFO  dc] Status: GroupState(OP)
[2025-03-05T18:08:43Z INFO  dc] EL4732 output data length: 8
[2025-03-05T18:08:43Z INFO  dc] EL3702 complete input data: [00, 00, 00, 00, 00, 00, 00, 00, C0, 53, AE, F4]
[2025-03-05T18:08:43Z INFO  dc] Status: GroupState(OP)
[2025-03-05T18:08:43Z INFO  dc] EL4732 output data length: 8
[2025-03-05T18:08:43Z INFO  dc] EL3702 complete input data: [00, 00, 00, 00, 00, 00, 00, 00, 00, 9F, FA, F4]
[2025-03-05T18:08:43Z INFO  dc] Status: GroupState(OP)
[2025-03-05T18:08:43Z INFO  dc] EL4732 output data length: 8
[2025-03-05T18:08:43Z INFO  dc] EL3702 complete input data: [00, 00, 00, 00, 00, 00, 00, 00, 40, EA, 46, F5]

Maybe the issue comes from some specific configuration of these oversampling devices?
On the other hand, it seems these devices do not support mailboxes...

I don't really now what should I investigate now.

[jamwaffles]

I haven't done anything with oversampling devices, but reading up a bit and inspecting the EL3702 ESI file, I think you might need to enable SYNC1 as well as SYNC0. Can you try configuring DC with Sync01 and see what happens? I think if you set the SYNC1 cycle time to the same as your process data cycle it will give normal sampling, which is a good point to start from.

Please attach a full log and a Wireshark trace if it still doesn't work.

I have an EL2262 to do some local testing with oversampling on, and I'll update this issue if I find anything out. Also, I'd be happy to debug the EL3702 or other SubDevices you have on hand if you have a spare you're willing to ship to the UK.

[tdehaeze]

With using:

                subdevice.set_dc_sync(DcSync::Sync01 {
                    sync1_period: Duration::from_millis(1),
                });

It works !
I get the +/-10V analog input.

However, I only get the data of the first input.
The data of the second input are all zeros.

[2025-03-06T19:23:14Z INFO  dc_el] EL3702 complete input data: [D5, 00, 05, 00, 00, 00, 00, 00, 40, 90, 8A, 90]
[2025-03-06T19:23:14Z INFO  dc_el] Status: GroupState(OP)
[2025-03-06T19:23:14Z INFO  dc_el] EL3702 complete input data: [D6, 00, 01, 00, 00, 00, 00, 00, C0, 14, A9, 90]
[2025-03-06T19:23:14Z INFO  dc_el] Status: GroupState(OP)
[2025-03-06T19:23:14Z INFO  dc_el] EL3702 complete input data: [D6, 00, 01, 00, 00, 00, 00, 00, C0, 14, A9, 90]
[2025-03-06T19:23:14Z INFO  dc_el] Status: GroupState(OP)
[2025-03-06T19:23:14Z INFO  dc_el] EL3702 complete input data: [D7, 00, F6, FF, 00, 00, 00, 00, 40, 99, C7, 90]
[2025-03-06T19:23:14Z INFO  dc_el] Status: GroupState(OP)
[2025-03-06T19:23:14Z INFO  dc_el] EL3702 complete input data: [D7, 00, F6, FF, 00, 00, 00, 00, 40, 99, C7, 90]
[2025-03-06T19:23:14Z INFO  dc_el] Status: GroupState(OP)
[2025-03-06T19:23:14Z INFO  dc_el] EL3702 complete input data: [D8, 00, F0, FF, 00, 00, 00, 00, C0, 1D, E6, 90]
[2025-03-06T19:23:14Z INFO  dc_el] Status: GroupState(OP)
[2025-03-06T19:23:14Z INFO  dc_el] EL3702 complete input data: [D8, 00, F0, FF, 00, 00, 00, 00, C0, 1D, E6, 90]
[2025-03-06T19:23:14Z INFO  dc_el] Status: GroupState(OP)
[2025-03-06T19:23:14Z INFO  dc_el] EL3702 complete input data: [D9, 00, FF, FF, 00, 00, 00, 00, 40, A2, 04, 91]
[2025-03-06T19:23:14Z INFO  dc_el] Status: GroupState(OP)
[2025-03-06T19:23:14Z INFO  dc_el] EL3702 complete input data: [D9, 00, FF, FF, 00, 00, 00, 00, 40, A2, 04, 91]
[2025-03-06T19:23:14Z INFO  dc_el] Status: GroupState(OP)
[2025-03-06T19:23:14Z INFO  dc_el] EL3702 complete input data: [DA, 00, 05, 00, 00, 00, 00, 00, C0, 26, 23, 91]
[2025-03-06T19:23:14Z INFO  dc_el] Status: GroupState(OP)
[2025-03-06T19:23:14Z INFO  dc_el] EL3702 complete input data: [DA, 00, 05, 00, 00, 00, 00, 00, C0, 26, 23, 91]
[2025-03-06T19:23:14Z INFO  dc_el] Status: GroupState(OP)
[2025-03-06T19:23:14Z INFO  dc_el] EL3702 complete input data: [DB, 00, 01, 00, 00, 00, 00, 00, 40, AB, 41, 91]
[2025-03-06T19:23:14Z INFO  dc_el] Status: GroupState(OP)
[2025-03-06T19:23:14Z INFO  dc_el] EL3702 complete input data: [DB, 00, 01, 00, 00, 00, 00, 00, 40, AB, 41, 91]
[2025-03-06T19:23:14Z INFO  dc_el] Status: GroupState(OP)
[2025-03-06T19:23:14Z INFO  dc_el] EL3702 complete input data: [DC, 00, F8, FF, 00, 00, 00, 00, C0, 2F, 60, 91]
[2025-03-06T19:23:14Z INFO  dc_el] Status: GroupState(OP)
[2025-03-06T19:23:14Z INFO  dc_el] EL3702 complete input data: [DC, 00, F8, FF, 00, 00, 00, 00, C0, 2F, 60, 91]
[2025-03-06T19:23:14Z INFO  dc_el] Status: GroupState(OP)
[2025-03-06T19:23:14Z INFO  dc_el] EL3702 complete input data: [DD, 00, F2, FF, 00, 00, 00, 00, 40, B4, 7E, 91]
[2025-03-06T19:23:14Z INFO  dc_el] Status: GroupState(OP)
[2025-03-06T19:23:14Z INFO  dc_el] EL3702 complete input data: [DD, 00, F2, FF, 00, 00, 00, 00, 40, B4, 7E, 91]
[2025-03-06T19:23:14Z INFO  dc_el] Status: GroupState(OP)
[2025-03-06T19:23:14Z INFO  dc_el] EL3702 complete input data: [DE, 00, FE, FF, 00, 00, 00, 00, C0, 38, 9D, 91]

First 4 bytes are for 1st input, and next 4 byte for 2nd input and last 4 bytes for diagnostics.

Input 1 is "using" SM0, while input 2 is "using" SM1.
Could it be that the SyncManager1 is not enabled somehow, or not properly configured in ethercrab?

Here are the wireshark logs and the program.

ethercrab.txt
dc_el.txt

[tdehaeze]

Similarly for the outputs (DAC, EL4732), the first output works perfectly (between -10 and 10V), but I get zero output for the second DAC.

This may also be due to the syncmanager as shown in the doc: