Multiple systems writing to single csv file

[dacad]

I am preparing to have two identical test systems that test a single product go into service side by side.  There has been one or the other of these in service for a number of years but due to volume, both must now operate in parallel.

The sticky point on this is that results are written to a CSV file and the file can only be opened by one caller at a time (whether one of the systems or a user).   My first approach is somewhat klunky but I think it may work.

When system 1 is ready to save, it creates a temp file based on it's stand ID.  It then looks for the comparable temp file from system 2. If it sees it, system 1 goes into a loop for what should be adequate time for system 2 to write and exit and then system 1 writes and at the end deletes it's tmp file.  If system 2 tmp file stays longer than the allowed for time, system 1 returns an error to the user that data was not saved and continues on. (same thing on other system with numbers switched)

As I say, it's klunky.

For this product, the csv format is preferred by production and because both machines will be running a single work order, they want the data to go into a single file.

Any alternative methods I should be considering ?

Thanks for any input.

[RavensFan]

Rather than guessing how long the other system is going to take to save the data, I would have the first system keep checking to see when the temp file disappears.  Then it know it is safe to write.  But of course you'd still need to have some timeout so that the system can continue on in the event somehow the other system gets hung up and never deletes the temp file.

But what I would do is create a single application that does all the writing to the .CSV file.  Then have the other applications open up TCP communications with that applications and send the data to be written to it.  The file saving application centralizes everything and can store the data while it can allow the 2 test systems to go back to what they need to do.

[crossrulz]

I fully agree with RavenFan's idea of making another application just for writing the file.  It greatly simplifies the process.  I would also recommend using the STM library to make the TCP/IP communications easier to understand.

[dacad]

Have never worked with the TCP com tools so will have to experiement with that but sounds like a good idea.  I'm assuming it will work in a dchp environment ?

[Nathan-M]

If both computers are on the same subnet, you can address them using the computer name. If they are not, you will need their IP address, which may become tedious if this keeps changing. Firewalls may also be a problem, so be sure to allow communication through the specified ports as well. 

Check the shipping examples with LabVIEW for some basic TCP client/server models, they work out of the box so it's a great way to check your network configuration.

[dacad]

Installed the STM toolkit and have looked at the examples in the NI example finder.

I feel certaint that I can get there with one connection but while the examples show a single server / multiple client set up, I am expecting I would need a multiple server / single client setup to send results from two systems to one system that would then save the results to the file.

Or am I looking at this all wrong.

This aspect of the application doesn't have to be resolved right away so I want to take my time to learn it using good methodology.

Thanks.....

[RavensFan]

Client vs. Server is just a point of view.

I would consider the data logging application the server.  Let the test stands be the clients that need to save the data "log into" the server.  Communication can go either direction between a client and server (and generally goes both ways.)  Direction of data doesn't define what application is the client and which is the server.

[dacad]

That makes it a bit simpler

[0utlaw]

Isn't the AMC library preferred for many-to-one communication schemes?

Asynchronous Message Communication (AMC) Library

http://zone.ni.com/devzone/cda/epd/p/id/6091

I've had issues with STM applications attempting to use the same port, although some background work on port assigning can overcome that pretty easily.

Regards,

[AMP12]

Not to mention that in the future if your company adds another production line, then you just duplicate your client application for the 3rd line and allow it to connect to the existing server to save the data.  Bam!  Half the work is already done for you at that point.