EtherCAT coupler is misconfigured in OES

[IAreCBTEF]

Hello,
I have an EtherCAT coupler from another brand here (similar to  the BECKHOFF EK1100),

but it's not in the STD/Peripherals catalog, and I hope it's available in OES.

I have tested that its configuration in TWINCAT3 is ok and can be used normally.

Thank you!

Thank you.

[MarvinWerner]

Hello,

if you want to use it in OES, then you will need a peripheral for it. That is, somebody needs to create one for you if you don't know how to do it yourself (generally requires the Object Creation training, it's not super easy).

Depending on what the terminals do, you may get away without a peripheral by creating the required %I and %Q variables in TwinCAT yourself and linking manually or with pragmas. But if you are using objects that require the signals of these terminals in their parameters, e.g. you want to use a BasMove and connect it to a digital input terminal, then you will need the peripheral. Otherwise your objects in the model tree will not work correctly in almost all cases.

Is this the Lingchen terminal from Suzhou? I investigated those as a Beckhoff alternative before but decided against them at that time because the way they provided the ESI (EtherCAT slave information) was not really compatible with Nexeed peripherals. But judging from your screenshot it looks like you have a different ESI file, which would allow creating proper peripherals for it.

[IAreCBTEF]

Yes，

How to get this RefId?Is it randomly generated? Still need to find its source and write it.

[nexidator]

The refId in in line 2 is randomly generated for every peripheral or object definition. If you start creating a new peripheral OOD by copying an existing one, please exchange this ID with a newly created, e.g. by using an online GUID generator.

The refLink in line 20 specifies what object description you want to derive from. So, if you want to derive from NxEcSlave, which makes sense for EtherCAT slaves, it is always the one from your screenshot.

Most important for new peripheral objects is line 23. This is the ID by which OES finds the correct OOD file for the device.

[MarvinW]

Judging from your question, you are not so familiar with how objects work, yet.

The LCT coupler may look almost the same as the Beckhoff EK1100 but it is not, internally. Trying to use the same peripheral is probably going to fail, and even if it works for the EK1100 coupler then you will probably run into problems with the terminals that you are trying to use.

But to answer your question about the RefId: Each object (and also peripheral) has its own unique RefId that the creator of the object is setting once when they start creating the object. The BCI objects take the RefIds from a predefined range, or used to do that up until some recent point at least (not sure if they continue this practice or not). So if you create your own peripheral, you need to create your own RefId for it.

The RefLink you marked in the second box refers to the RefId of another object, the NxEcSlave in this case. If you open the .ood of that object, you will find its RefId is identical to the one in the RefLink of the EK1100 .ood file.

In the case of bus peripherals, the id in the DeviceType element is also important. This tells OES which peripheral to use when you are reading the IOs from TwinCAT. You cannot use the Beckhoff EK1100 peripheral for your LCT coupler, because the Beckhoff EK1100 and the LCT coupler have different DeviceTypes ids.

Note: I sometimes use the word object also for peripherals, because much of the logic in the .ood and accompanying files is the same for both.