Data sharing between targets running VS and LV

[Izotop]

Hello all,

This is my first post on this forum as I just learned about it and am fairly new to LabVIEW as well as the whole NI environment. I was at NI Week 2019 and was very impressed by the size and the quality of this community.

I am currently working on building a test rig where we'll be doing HIL testing as well as dynamic load control. Basically, our first target (PXI-based) will be running VeriStand and dedicated to doing data acquisition and HIL. Our second target (still PXI-based) will be running LabVIEW RT 2018 and dedicated to performing load control. The first target will be equipped with a reflective memory module to share data with a third-party test infrastructure and a host-PC where the data logging will take place. I need to send over some data from the 2nd target (LV, load control) to the 1st target (VS, data acquisition and logging) as that data needs to be populated to the RM and logged. We're talking about 32 floats, double-precision, that I need to send at a rate of 200 hz.

1st option: buy a RM module for my second target and populate data directly from that target.

2nd option: send the data to the 1st target through Ethernet using "some" protocol.

The first option seems straight forward, but definitely more expensive.

 

The Questions:

1) Regarding the second option, I'm not sure how to implement that. To share data from a LV target to a VS target, would that be done through UDP, TCP, network-published shared variables, or another protocol?

2) As a side question, can I connect my two (2) targets + my two (2) host PCs (1 host for data logging, 1 host for load control) through an Ethernet switch? Then, use my data logging host to communicate (GUI) with my 1st target and my load control host to communicate (GUI) with my 2nd target?

[Gribo]

You will have to implement or choose a protocol that both sides can speak. 32 doubles at 200Hz means 52KB/sec, Which is relatively modest. Are there any hard real time requirements? What happens if you lose some values?

 

[ShaunR]

2 hours ago, Gribo said:

You will have to implement or choose a protocol that both sides can speak. 32 doubles at 200Hz means 52KB/sec, Which is relatively modest. Are there any hard real time requirements? What happens if you lose some values?

One aspect of reflective memory architectures is determinism. For that reason and without a full  detailed spec, I would err on a reflective memory network solution (option 1). You may have to start looking at ethercat and synchronising asynchronous systems depending on the reasoning for the insistance of the reflective memory in the first device since you get that for free with a reflective memory network.

Edited June 12, 2019 by ShaunR

[Izotop]

15 hours ago, Gribo said:

You will have to implement or choose a protocol that both sides can speak. 32 doubles at 200Hz means 52KB/sec, Which is relatively modest. Are there any hard real time requirements? What happens if you lose some values?

 

In fact, my initial thought is to transmit data at a rate of 200Hz from target 2 to target 1, even though I will likely log data at 100Hz at target 1. Logging rates are not yet fully defined, hence the reason why I leave myself some buffer. The data transmitted is solely for logging purposes, not control. However, skipping a few data points may make data interpretation trickier.

With regards to the protocol that both sides can speak, that is precisely what I'm looking for. If there already is a usable, well integrated solution for that I'd like to find out what it is. I'm trying to avoid low-level protocol integration if possible.

 

13 hours ago, ShaunR said:

One aspect of reflective memory architectures is determinism. For that reason and without a full  detailed spec, I would err on a reflective memory network solution (option 1). You may have to start looking at ethercat and synchronising asynchronous systems depending on the reasoning for the insistance of the reflective memory in the first device since you get that for free with a reflective memory network.

Of course, RM would be my pick, but I have to balance cost and need. If I get the same result through a well integrated ethernet solution, I'll go with it. However, if I need to spend a week integrating Ethernet data sharing between target 2 and target 1, then my time's certainly worth an additional RM module.

Regarding EtherCAT, I'll be using that technology on the load control side of my system. I'll have a master PXI with a few 9145 slaves, one for each of my loading station, where I'll be performing PID control at the FPGA level.

[ShaunR]

2 hours ago, Izotop said:

In fact, my initial thought is to transmit data at a rate of 200Hz from target 2 to target 1, even though I will likely log data at 100Hz at target 1. Logging rates are not yet fully defined, hence the reason why I leave myself some buffer. The data transmitted is solely for logging purposes, not control. However, skipping a few data points may make data interpretation trickier.

With regards to the protocol that both sides can speak, that is precisely what I'm looking for. If there already is a usable, well integrated solution for that I'd like to find out what it is. I'm trying to avoid low-level protocol integration if possible.

Transmittion of data at a rate (Hz) is not very conducive for ethernet. It is intended to move large amounts of data efficiently. Typically, ethernet connections use the nagle algorythm where data is transmitted after the accumulation of a certain number of bytes or after a timeout (typically 250ms). This is to solve the issue of small data packets flooding the connection (which is what happens at high rates with, say, a single double in the packet) If the nagle is turned off, then packet overhead comes into play and the network can start to behave irratically at high data rates. This is where ethercat comes into it's own.

2 hours ago, Izotop said:

However, if I need to spend a week integrating Ethernet data sharing between target 2 and target 1, then my time's certainly worth an additional RM module.

At least one week if you don't already have a solution in your toolkit.

[Izotop]

Thanks for your input. Looks like this is a case for RM.