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

Complete-Access mode for reading / writing PDO items? #849

Open
pingplug opened this issue Aug 21, 2024 · 7 comments
Open

Complete-Access mode for reading / writing PDO items? #849

pingplug opened this issue Aug 21, 2024 · 7 comments

Comments

@pingplug
Copy link

EL6695 has a virtual RxPDO (0x1608) and a virtual TxPDO (0x1A08).
Is there any plan for support virtual PDO?

@ArthurKetels
Copy link
Contributor

A virtual PDO has no entries. Support would also be "virtual". So what would be the point?

@pingplug
Copy link
Author

pingplug commented Aug 22, 2024

in EL6695 manual:

If no TwinCAT EtherCAT Master with [Load PDO info from device] is available on the other side, the PDO upload mechanism must be reproduced there:
- Read PDO assignment objects 0x1C12, 0x1C13
- then read out the PDO Mapping Objects 0x160x (outputs), 0x1A0x (inputs) and 
- read out the PDOs 0x60xx, 0x70xx accordingly

I find the PDO Mapping Objects becomes a mess after starting SOEM or IgH master. So I wonder if there is an option to disable writting PDO Mapping Objects?

@ArthurKetels
Copy link
Contributor

SOEM does exactly what you have copied above from the EL6695 manual. Can you describe what is a "mess"? And does the configuration succeed with SOEM?

@pingplug
Copy link
Author

pingplug commented Aug 25, 2024

I set 128 BYTE inputs and 128 BYTE outputs in EL6695, and run slaveinfo from another side (EL6695-0002)
the topology is: master -- EK1100 -- EL2008 -- EL6695-0002
what I expected:

0x1C12: 0x1608
  0x1608: 0x7000:01:08 ... 0x0700:80:08
0x1C13: 0x1A01, 0x1A08
  0x1A01: 0x0000:00:0C 0x1802:09:01 0x1802:07:01 0x0000:00:01 0x10F4:10:01
  0x1A08: 0x6000:01:08 ... 0x0600:80:08
0x6000
 01: BYTE "OUT1_1" (it is the output in EL6695, mapped to the input in EL6695-0002)
 ...
 80: BYTE "OUT1_128"
0x7000
 01: BYTE "IN1_1" (it is the input in EL6695, mapped to the output in EL6695-0002)
 ...
 80: BYTE "IN1_128"

the output form slaveinfo and wireshark capture is there:
slaveinfo.zip

for comparison, the wireshark capture from TwinCAT is there:
the topology is: master -- EL6695-0002
in config mode and freerun mode, OP -> INIT -> PREOP -> OP -> INIT
twincat.zip

@ArthurKetels
Copy link
Contributor

There is something funny going on with this slave. When reading the PDO mapping with Complete-Access mode the PDO items are as you expected, so we have 128 entries each with length 8 bits for outputs. But when we do the same in standard mode we get a different response from the slave and it outputs a compressed PDO as shown by slaveinfo.

The the messing up happens in the slave and not with SOEM.

There is another issue that when requesting the pre-OP to safe-OP transition the slave responds with error 0x0003. And this code does not exists in the specification.

@pingplug
Copy link
Author

So is there a way to force SOEM to use CA in PDO items?

@pingplug pingplug changed the title support for virtual PDO in EL6695? Complete-Access mode for reading / writing PDO items? Aug 31, 2024
@ArthurKetels
Copy link
Contributor

SOEM does use CA when mapping the PDO items. You can see this in the Wireshark capture. It is only when slaveinfo prints out the PDO mapping it uses the single object read method. Both should return the same answer however. And this is a slave issue.

If you look at the code of slaveinfo you see why it is easier to not use CA there. Secondly there multiple slaves out there that do not handle CA very well and crash.

If your application needs the detailed PDO mapping information, there is nothing holding you back using CA to read the PDO objects. SOEM does give you all the tools you need.

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