simple_test: Input mapping values

[prabhakarlad]

Hi,

I have made some changes to simple_test application [1] to work with lan9252 chip, I see after a while the ec_slave[0].inputs doesnt change, nor does ecatcheck() report anything, has anybody seen some similar issue ?

Master: 1.3.3 release Hardware: LAN9252-HBPI plus EVB. OS: Linux-RT

[1] https://github.com/prabhakarlad/soem-lan9252-hbiplus/blob/master/simple_test.c

Cheers, --Prabhakar

[ArthurKetels]

You messed up the program flow. You use ec_send_processdata() both in main context and in realtime thread context at the same time. Either do process data transfer in main or in rt, not both.

[prabhakarlad]

Hi Arthur,

ec_send_processdata in main context is never executed if you follow the code in the main thread is never executed as its in ifdef block only one in the rt thread ec_send_processdata is run.

Cheers, Prabhakar

[nakarlsson]

Sounds like the slave stack/application stops running?

[prabhakarlad]

nakarlsson what could be the best way to nail it down if its stack code is causing the issue ?

[nakarlsson]

Try to step down to SAFEOP, verify that the slave follow or not?

[prabhakarlad]

Okie so I tried stepping down the slave to SAFEOP when I get 100 same samples from the potentiometer. The slave goes into EC_STATE_SAFE_OP, but gain doesn’t resume to OP mode. When stepped down to SAFEOP, reading the inputs gives proper values (for example the button press)/but the outputs is screwed up I am toggling the led which doesn’t work. Does it still mean its SSC stopping ?

[nakarlsson]

No, seems the slave stack is still running. So, your initial problem is something else, if you can provide a wireshark it might help. The inputs should be valid even in SAFEOP, if they stop updating is strange, unless the slave for some reason stop updating them.

[prabhakarlad]

Attached is the wireshark dump.

lan9252.pcapng.zip

[nakarlsson]

I think you should run the CTT to verify the slave, the fact that it refuse to re-enter OP without setting the ERROR flag for over 10s is strange,

[prabhakarlad]

Will do that, In the meantime I ran it using twincat and never saw this happening, but not sure if twincat is doing asynchronous reads.

[prabhakarlad]

I think you should run the CTT to verify the slave, the fact that it refuse to re-enter OP without setting the ERROR flag for over 10s is strange,

If I add a bit of delay in rt thread osal_usleep(500);, I don’t see this issue happening.

[nakarlsson]

This issue of inputs not updating or slave re-entering OP? If the issue is solved please close the issue.

[prabhakarlad]

This issue of inputs not updating

But is this a correct solution to add a delay in rt thread where ec_send_processdata() is called ?

[nakarlsson]

where do you add the delay? how fast is your slave cycle? how often does it update the values?

If the slave stops to update the IO, please verify with wireshark,while you're still in OP and the wck is correct, have very little to do with SOEM. Adding a delay between send/recv whould prevent you from doing timeouts, eg wck to differ from the expected. Adding a delay before send would just slow down the cycle and should still update the IO, given that the IO actually is updated on/of the slave.

If the LRW frame doesn't appear to have updated IO in wireshark, the issue must be in the slave.

[prabhakarlad]

where do you add the delay?

I added a delay in ecatthread()

how fast is your slave cycle? how often does it update the values?

From ESI its:

            <CycleTimeSync0 Factor="1">0</CycleTimeSync0>
            <ShiftTimeSync0>0</ShiftTimeSync0>
            <CycleTimeSync1 Factor="1">0</CycleTimeSync1>

So its the EtherCAT cycle time which is 1ms.

changing the ctime to 4000 (4ms), no more problems happen. So my question is what is best way to calculate the ctime ?

[nakarlsson]

Depends on SW/HW platform, for non-real-time systems there will never be any guarantees.