Sharing information from multiple sources over a netwrok

[bmann2000]

I have a factory floor with 10+ manufacturing machines that perform automated processes using an App designed in LabVIEW.

In the offices, I have production planners, production operators and others who want to know when each machine will complete the current job, they also want see plant data, warnings etc, to allow them to keep on top of the manufacturing activities.

I want to provide the users with some type of read-only interface that will display a dashboard summary of the status of all the machines.  This dashboard will show all machines simultaneously, so they can see at a glance which machine will finish next.  Ideally the dashboard could be displayed on a dedicated monitor on the factory floor as well as being available from any desktop PC.

I'm looking for advice on which type of implementation would be the most reliable and provide the best user experience.  I don't have much experience of designing Client-Server type apps.  I've had an attempt at a TCP-IP client-server type setup using the LabVIEW Example, but it does not work well, the connections drop-out and attempts at designing scheme to re-make connections have been unsuccessful.

[ZYOng]

I think SystemLink is what you need. 

Using SystemLink to Manage Systems and Data

[RTSLVU]

Hmmmm.... On a high level I would say you might want to consider using Shared Variables.

Your ATE applications on the floor would write to the shared variables. (status, % complete, warnings, etc.)

The people "upstairs" would use a seperate application that reads, displays, and maybe graphs the shared variables.

[BertMcMahan]

You'll need some kind of server to handle all of the data. A database might be the way to go to stream data to for long-term monitoring, and you could have some independent viewer tools that read from the database.

If you're looking for a simple protocol, I highly recommend MQTT:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kKAcSAM&l=en-US

It's cross platform and lets you read/write data to a central broker. It's VERY easy to use and would be simpler than spinning your own TCP/IP command set. You can also read from the server using any programming language you'd like, so your LabVIEW machines could publish data, and some other viewer tool (internal website, other LabVIEW program, etc) could read the data.

[bmann2000]

Many thanks to everyone for the suggestions.  I think a manufacturing-data-server is essential as it's not practical to have the end data users access all the machines on the factory floor, it is possible but would quickly get messy.
The Windows Machines on each manufacturing unit run a LabVIEW App that coordinates the manufacturing, the data output is currently written by LabVIEW as files on the local PC, so we need a scheme to move that data to the server, or add it directly to a database on the server.
Once the data is on the server, we are then into choosing whatever tools we require to serve the data to the end users, that part is beyond the LabVIEW implementation I will design.

My immediate thoughts are using PowerShell/Robocopy/WindowsTaskScheduler to move the files to the server.  The manufacturing PCs will eventually fill their HDDs, so it means moving the data permanently rather than just mirroring.

I have other considerations too.  Some machines may go off-line during maintenance, so the HDDfiles-to-server task would need to catch up when re-connected.  The end users of the data are at their desks awaiting the results of various measurements that indicate the quality factors, they expect the data to be available within minutes of the manufacturing tasks completing.

MQTT sounds robust being a continuous handshake.  I downloaded Sam Sharp's LabVIEW-WebSockets-API from github for a look, it has a handshake scheme that appears a robust method of transferring data over a network. MQTT appears to offer a similar function.
If we decided to use an SQL Database on the server, I notice there is an add-on LabVIEW Database Connectivity Toolkit.  Our manufacturing rigs must be able to run if the network is down or slow, so any connectivity with the server would need to be a separate App that could start/stop or catch-up at any time, regardless of what manufacturing was taking place.

I think we would need to decide if we move files to the server, or attempt to populate a database on the server.  We would need to be sure the data was successfully on the server or in the database before deleting the files from the manufacturing PC. I figure the problem to be solved is therefore "what is the best way to transfer the manufacturing data to the server".