ATE Station monitoring

[Phillip Brooks]

I'm looking at adding some functionality to a station monitoring application. The app is a simple .EXE that montitors a LabVIEW global; more info is available here (dark side). The app provides an audible notification if the station needs attention. I would like to extend this app to allow remote monitoring (beyond earshot of the ATE). This app would run as an .EXE in locations outside the mfg floor.

We have other apps that currently use a database to store the status of stations and resources running extended tests that don't require interaction, but they use polling of the DB. This has served us well, but most of the code was based on features and services available in LV 5.1 and LV 7.0. Polling leads to problems when the source responsible for the alarm is terminated abnormally (station reboot or process killed).

Our extended automated tests that use the database have additional code to detect 'stalled' tests, but my monitoring app has no dependancies (such as releasing resources or updating results status). Basically, this app tells anyone listening "Hey, you need to connect the cable; I'm still waiting!" ( One engineer is fond of playing 'Lets go, while we're young!' using the local app)

This is a monitor only function. Minimal configuration would be preferable, so I've thought about using UDP broadcasts or DataSocket. A custom UDP port may be filtered or discouraged in certain network environments. DataSocket server seems to be a bit old now. Shared Variables seem nice, but a bit of overkill for a simple monitoring app.

What method is considered de rigueur for this sort of application?

As for your answers; like Mr Dangerfield said, "Lets go, while we're young!"

[ShaunR]

Just for simplicity, I would suggest a TCPIP packet thats sent when your global changes. 2 seconds to add and has the advantage that you don't necessarily need labview on the remote machine (a C++, Delphi, VB app for instance). I prefer TCPIP over UDP since it is far more reliable, although it is not connectionless (i.e you need a target IP unlike UDP broadcast). Once you start down this route, you will quickly find that you want more and more information and it is very scalable and easy to implement

[Grampa_of_Oliva_n_Eden]

... DataSocket server seems to be a bit old now. Shared Variables seem nice, but a bit of overkill for a simple monitoring app.

What method is considered de rigueur for this sort of application?

As for your answers; like Mr Dangerfield said, "Lets go, while we're young!"

As far as I can tell Shared Variables have datasockets hiding behind them somewhere. Most of my DSC apps used Tag names to define which varible to read from/write too and when they got updated (LV's mutation code) the old tag reads got relaced with "Leagacy Tag Reads" and inside of them are datasocket read/writes. The only thing I ever got from a shared variable I could not get out of a datasocket is shared variables can be used as the source of dynamic events. Never did figure out how to get a datasocket to trigger an event.

Ben

[Black Pearl]

I would go for TCP as well. Did a good job for me in the past. All you miss is a good determinism (but what's 2 ms for a human?). You can catch a lot of errors generated by the OS (?) and even get a great stack for free (handled by the OS as well). And that's tested every time you go over and visit LAVA, that TCP is doing a good job. Seems like waterproof.

Felix