[Etherlab-users] EK1960 (TwinSAFE PLC) "This object does not exist" error and related warnings

Graeme Foot Graeme.Foot at touchcut.com
Tue Aug 4 00:25:36 CEST 2020


Hi,

I'm testing an EK1960 TwinSAFE PLC device.  It integrates a TwinSAFE PLC and a bunch of safe inputs and outputs.  I am creating the safety project in TwinCAT 3.1.4024.10 (with Visual Studio 2019 16.5 Community).

I have exported the safety project and successfully loaded it onto the EK1960 (via TwinSAFE Loader and the EtherCAT Mailbox Gateway server I wrote last year).

I have created my pdoEntries, pdos and syncs structures based off TwinCAT 3's Process Data information that is available if I map the EK1960 safety project to an EK1960 device under the I/O section of TwinCAT.  There are multiple pdo entries with the same index and subIndex (with 0x6000 and 0x7000 indexes).  I am using ecrt_slave_config_reg_pdo_entry_pos() to access the pdo entries to avoid this being a problem.

I get the slave configured and into OP and it is running happily, however the slave does not allow PDO config and mapping so I get a bunch of startup errors with "This object does not exist" and related warnings


The slave does not contain the pdos being configured (0x1600, 0x17F0, 0x1A00, 0x1BF0, 0x1BFE) or the pdo entry indexes (0x6000, 0x7000).  The master reports "This object does not exist in the object directory" for each of them.

The EtherLab master does however correctly map the Sync Manager and FMMU settings correctly (and match those that would be requested via TwinCAT).

So the question is, is there a way to get the master to skip checking and setting the pdo mapping for this slave and just go straight to configuring the sync manager and fmmu information?  (I'm using GavinL's patchset 20171108, a little old but AFAIK the latest patchset doesn't have this ability.)


(Doing so would also help me for slaves with multiple revisions, where the data hasn't changed but the index it gets it from has.)


Regards,
Graeme.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20200803/011224e4/attachment-0006.htm>


More information about the Etherlab-users mailing list