Collect multiple data files simultaneously

[paris1_]

In an upcoming test, I will have something very close to the following.

1.  One piece of commercial hardware that collects data via a specific LabVIEW code.  The LabVIEW code communicates with the commercial hardware via Ethernet (TCP connection) on a specific IP address.

2.  A second piece of commercial hardware essentially identical to the one above that also collects data via the same, specific LabVIEW code as in (1) above.  As with the above, the LabVIEW code communicates with the second piece of commercail hardware via Ethernet on a specific IP address that is different than the address in 1 above (though they will be on the same subnet).  

The above two pieces of commercial hardware are NOT set up to be daisy chained and hence otherwise connected via the same, single IP address which is why I've called out steps 1 and 2 separately above.

3.  Then to complicate matters just a bit more, a third piece of hardware totally different than the above mentioned two nearly identical pieces of hardware will also take a different kind of data and communicate it's results also via Ethernet on yet another IP address.  And this third piece of hardware does NOT work via LabVIEW.  

All three pieces of data will be slow temperature and displacement data.  Data will be collected on each subsystem about once per minute and the goal is to have all three datasets all automatically placed into a single file with a single timestamp.  The time stamps can be approximate as long as the data is all taken at relatively the same time, within say the same minute...  

What would be the best way to go about hooking up this hardware (switch, hub or separate ethernet port for each of the three subsystems on the single data acq computer???) and what would be the best way to automatically merge all this data into a single file with a single timestamp???

thanks....  bob... 

[josborne]

So all three of these "data gathering" systems end up transmitting their values via Ethernet?

If so, my suggestion would be:  Add a FOURTH computer to the system which gathers data from the other three.  Connect all the devices together via an Ethernet switch and put them all on the same subnet.  Write a little pice of labview code that runs on the fourth computer.  Have that code poll all three data sources once per minute and append a row to a CSV file every minute.  The only downside is that the timestamp written to the file is not when the time when the data was actually acquired.  But maybe that is enough time-accuracy for you?

[Bob_Schor]

Let me see if I understand your question correctly.  You have a PC that can "talk" to one of three pieces of hardware via TCP/IP (all three have different hardware addresses).  Once a minute, you want to take a data point from each device and store all three points together in a file.

I'm assuming that the way you control the devices is to "send a message" to the device (via TCP), and then "get a response".  A message might be setup information or a request to take some data, the response might be a returned status or a piece of data.

Given your "relaxed" data rates and timing considerations, the simplest configuration for the devices is probably "put them all on the same network".  If you have a "wired" configuration with Ethernet ports in the wall, simply plug them all in.  Otherwise, if you are "stand-alone", get an inexpensive 5-port unmanaged switch and plug the three devices and your PC into the switch.  Be sure you can "ping" each of the devices ...

The routine to collect the data could look something like the following pseudo-code:

1)  Initialize each of the three devices.  Open a file for reading.

2)  Once per minute, get a reading from each device.  Assemble the three readings as desired (adding a TimeStamp, if appropriate), and write to file.

3)  When "done", close file and exit.

If I were doing this, I'd be tempted to make a State Machine that has the following states:  Initialize (do bookkeeping), Open Devices, Take Sample, Save Samples, Finish (more bookkeeping).  When you finish Save Samples, go back to Take Sample (which should have something like "Wait until Next Multiple" for simple clocking, which should be adequate for your task) unless the user has pushed the Finish button in which case go to Finish.

To make this really sexy (something I'm just learning about, so don't ask me (yet) how to do this), make each of your devices an Object, create an array of Objects (one per device) that you keep in a Shift Register in your State Machine, and in each State, simply iterate (via a For loop) through the Objects, asking them to do their "Initialize", "Take Sample", or "Close" routine, as appropriate.  The advantage of this technique is that you can easily add a fourth, fifth, or sixth device (just by adding the specific code for these devices), or "mix and match" the devices you are using, potentially even choosing at Run Time which devices you are going to monitor.

Bob Schor

(Still having fun, and learning What I Don't Know about LabVIEW)

[Mark_Yedinak]

I would be more inclined to spawn a task for each device as well as spawn a task for logging the data to a file. Design a simple message protocol to encapsulate your data and have your monitoring tasks post data messages to a queue. The logging task will listen on the queue and process/log the data. The monitoring tasks will be independent of each other and simply post new data to the log queue.

While your collections rates are very slow and it could all be done in a single state machine it will get much more complicated if you need to start collecting data at different or faster rates. By keeping each data collection task separate they will not impact each other and they can all run at their own pace. Also, if one of the devices goes into an error state it will not impact the collection of the other devices. In a single state machine an error on one device can impact the collection on the other devices. For instance, you have a 1 second timeout to read your data. Your collection rate will be delayed 1 second every time through your state machine if one device is down. Over time your collection times will skew due to this timeout every iteration.

[paris1_]

Let me clarify and be even a bit more specific...  Two of these instruments are going to be a four channel (sm125) Optical Sensor Interrogator from MicronOptics.com (lots of stuff about MicronOptics on the NI site) and then a 16 channel (sm225) Optical Sensor Interrogator from the same company.  The only reason for these two is that the customer wants us to monitor 20 total channels of sensors, thus the reason for the 16 and the 4.  And these are NOT standard sensors, othewise, there are ways to multiplex many standard sensors onto a single channel...  So even though I'm still learning about requirements, it sounds like 20 total Interrogator channels are going to be needed...  Both instruments communicate over Ethernet and both are set up to use 10.0.0.x with the same subnet mask of 255.255.255.0. 

The other instrument is a Vishay PG System 7000 that is capable of reading strain, temperature and displacement sensors...  It is a totally different beast that the instruments above although it does communicate over Ethernet but on a different set of IP addresses on a...  It uses 192.168.0.x with a subnet mask of 255.255.255.0. 

I would like a SINGLE computer to run the LabVIEW code that talks to the above two MicronOptics systems (two instances of the same code running on the same machine at the same time but with different IP addresses to capture different amounts of data (4 vs 16 channels)...  Unfortunately it appears the systems from Micron Optics are NOT set up to be daisy chained although I am still asking questions about that...  Otherwise, I would run the code once and talk to both boxes, one right after the other... 

I also have a way of taking the data from the Vishay box that doesn't run under LabVIEW at all but instead runs on a custom software code all StrainSmart and then dumping that data via some activeX drivers written by Vishay for LabVIEW to take the StrainSmart captured data and drop it directly into any LabVIEW code, including I could put a hook in the MicronOptics LabVIEW code to have it receive the StrainSmart data on my command...  I've used the Vishay LabVIEW drivers many times over the years... 

The bigger issue is how to run three different Ethernet coupled DAQs, two of which are running identical LabVIEW code, on the same machine at the same time and output one, neat data file...  The data speed is very slow so we don't care if a data point is captured exactly at the right time as long as it's within say the correct minute... 

All I've done here is add some details...  Does that help or confuse the issue???  Sorry if it's the latter...  bob...

[Mark_Yedinak]

I already gave you the answer. Write a single VI to monitor your MicronOptics deivce. Make this a reentrant VI. Dynamically spawn a task using the "Start Asynchoronos Call" (if using LV 2011) or "Call By Reference" (if using an earlier version of LV). In your code you will call this twice. Pass in a Queue reference (for your logging task), the IP address of the device and any other configuration data. Now you are monitoring your MicroOptics devices. For the other deice I would see if they have documented their protocol. If so I would write that in LabVIEW. This will probably be much easier and faster than trying to get a bunch of other stuff to work. I doubt the command set you need is very large. Once you have this written you can run this in it's own task as well. And yes, this can all run on one PC. I have written applications that communicate with nearly 100 devices on a single PC using this exact approach.

As for the IP addresses you may run into problems trying to get both sets of IP addresses to communicate without some routers. You can't simply throw different subnets on a network and expect it to work. You will need routing to get the packets to their proper destination. For example, let's assume your PC is on the 10.x.x.x subnet. When it tried to communicate with the device on 192.x.x.x it will send the packet to the default gateway. If that router doesn't have a path to the 192 subnet the packet will never reach it. You could define a route on the PC but that is not a very robust method of doing it.

[RavensFan]

Each of those devices should have the ability to define their IP address.  Both 192.x.x.x and 10.x.x.x are considered private networks.  There is no way any of those devices are designed to have hard-coded IP addresses that require them to have specific subnet addresses.  I suggest reading the manuals on all of those devices a bit more and look at the configuration sections to see what instructions they have for redefining the IP address.

I certainly wouldn't go with any suggestion that says throw another PC into the mix to communicate with the device with the different subnet address.  That is a ridiculously expensive proposition.  If it true that there was no way to properly define the addresses on any of these devices, I would just add another network card to your existing PC and allow one to handle the 192.x.x.x network and the other to handle the 10.x.x.x network.  But this should not be necessary.