Ethercat 3rd Party Device Profile XML File not complete

[ZhouShanghai]

Hi Sebastien,

Could you include the latest in use XML profile? Or how many in total bytes are there for the devices?

[Jesse_D]

Hey Sebastien,

We can't benchmark your code but we can look at our latest testing benchmarks once we figure out how many bytes are being transfered. 

Your local field contact should be the best contact for getting a loaner 9068. Do you know who he is? 

[smi38]

Hi all,

Sorry for answering so late.

I don't know how many bytes are used, and I don't know how to know how many bytes are used

Attached files : devices profiles, 2 files, but three devices (1 LTI and 2 Schneider).

My local field contact lend me a 9068, I'll do the tests on this Thursday.

Thank you guys for your time.

[ZhouShanghai]

Hi,

The Schneider device is 25Bytes, while the LTi devices have several different types in that XML, each has <20bytes. Please note that NI master doesn't support multiple SM tags.

I suggest to use RawData API to get faster scan rate. But for a scan data around 100Bytes, I suspect  9068 would not meet that scan. Do you have contact of local AEs? Contact him/her to loan a 9068 to have a actual test.

[smi38]

Hi,
I did all the tests I need.
With a 9068, and just one of my slaves, I can configure the scan engine to 400 us.
This is not fast enough, especially when Ethercat is known as a faster bus.
So, I did the same test with the Ackermann library which run on a pc : I can run my Ethercat network to 100 us very easily !
I'm a litlle bit desapointed, I think a cRIO is not a real Ethercat master because it not matches the
Ethercat specifications. This is worrying, especially when Beckoff tries more and more to make a TwinCat software plateform which allows the same kind of stuff that LabVIEW in test and measurement field.

[ZhouShanghai]

Hi Sebastien,

I understand your concern totally. The cRIO, as far as I know, is an RT platform that makes deterministism possible. The CPU on it may not be as comparable as some of the most powerful intel CPUs. The scan rate performance itself, though affected by the design of the LabVIEW stack, is largely dependent on CPUs as a basis. So for an RT appliation and also with a high scan rate, I would recommend to use PXI platform which has more powered options on the computing volumn. However, I do agree that some parts of the stack put on an overhead that might drag down the scan on the application for EtherCAT, but those might be for other use cases on the overall platforms. Try Raw data mode if possible.

[smi38]

Hi ZhouShanghai,

A PXI would have been too expensive, and it's too late for this solution.

About the raw data AP, Jesse told me "The raw data API is something that can speed up the data transfer on a 9144. I think you are using just third party hardware though,it may not help."

so I'm a little bit confused if I could use it or not.

I'd like to thank the both of you for your time and precise answers.

[ZhouShanghai]

Hi Sebastien,

I would still recommend RawData APIs for maximizing the performance.

It is beneficial to modules on 9144 for eliminating calibration process embeded, and it is also helpful for external devices because it grabs all data once from the PDO image and does no extra data copying at least, which is expensive for a fast scan system. I am not sure whether it would meet your original expectation, but I believe it will speed up the scan.

[佳云]

Hi

I am dealing with the LXM23 now. Did you make the LXM23 ethercat successfully work? Can you share the LabVIEW project?

Sincerely hope to get your reply!