STM protocol sample code for VB.NET

[abales]

I wrote a VB.NET app that interfaced with 16+ CRIOs via STM Protocol.   I used code similiar to what I will post with this for a  client awhile back.  This is dumbed down, but will work just fine.

• It uses threads
• It is the server - the CRIOs are the clients
• It watches multiple machines and reports the data to a SQL2005 db (removed - you need to add your own)
• It uses differing polling rates for rx and tx
• It does fire off a STM parser class and run some unit testing (Form Load) on it prior to connectioning the thread
• The thread does post strings back to the GUI.  You should consider posting other information that is protected with locks.
• You should consider using a dual network card to keep the CRIOs off your real network.  I did not include the mass of code to find the network addressess of all of the cards.  An exercise left for the student...

I will try to rewrite it in C# soon.  Next week I hope to port those classes to java (Android) but I can only test it with test samples as I have no phone yet.  I think a java app on a phone would be cool for when we get true wifi on Android phones.  That would rock!

[abales]

Before I go post a sample project for network variables that is similiar to this....here is a quickie to help you decide on STM or NetVars.

When to use STM Protocol:

• When you need ack's from the server or client
• When it is point to point and data security is paramount
• Losing data or getting data out of synch is a show stopper
• You need to know that the client or server actually is running
• You could make the CRIO or the PC the server....allowing multiple clients to access the data.
• You need to pass alot of data and want to define alot of data packets
• Highspeed and quick
• More work to get running, but more stable and defined and expandable.

When to use Network Variables

• You want to be trading data by the end of the week, need it done fast and don't care 
• When there are possilbly multiple listeners, writers, and listener/writers.
• When you want the data fifo'd up and ready for the client whenever they show up
• You want the data variables to exist even if the server app stops.  This is a real standalone server that runs on the CRIO or PC.  
• The variables will exist even if your app has not run in months.  It will exist for years after you no longer run your app on your PC.  It is like Apache webserver...its running on your machine in the background.  If you don't understand what this means, find someone who does.  But for quick and dirty, its up and running fast!
• Make sure you have your naming convention done before you start creating them.  Don't litter & burden your machine with tons of variables and apps as you work towards one solution.
• You don't care if the data becomes aysnch
• You don't care if VB.NET apps can ONLY see a data change (you can't re-read any data without getting a try-catch thrown)
• You don't care that LabView CAN'T tell if the data changes without logic (VB and LabView are totally backwards on this - VB can only see changes, LabView has to poll forever and keep local copies to check for changes).
• You don't mind rebooting if the Network Variable server gets fouled up.  In fact you might wind up rebooting all machines accessing the network variables from time to time to re-synch them again. 
• Its the price you pay for super quick development.
• Seconds of delay is just fine if it happens

As you see, you probably want to only use STM Protocol for a professional app.  NetVars are good for quick and dirty applications, and tend to suffer under load and get asynch with the clients from time to time and spin out of control at the worst times.  Having done many projects with both, we don't like Network Variables and consider them to be scary at this time.

[abales]

Here is a small VB.NET project that uses network variables. 

You probably need to reconnect the references.  I deleted the dlls and references in the debug directory.  You need to go to project properties and add references for NI Common dll and NI network Variables DLL.  That is all you should need to do to use this.  In the event that this really messed up the project, create a new VB project and just copy the code over.  Its not rocket science so don't panic.  It's really idiot proof.

• This only uses the form.  You should make a connection thread.  I deleted that for simplicity.
• THis uses the LabView app's network variables.  This doesn't create variables, it only reads and writes to what your LabView app creates.
• Make sure you know the name of both PCs (LabView and yours from control panel).
• Make sure you setup the exact same netvar names and variable types (strings, floats) in LabView this app uses or visa versa (of course).
• The buttons do writes.  Stupid simple.
• The callbacks will handle new data as written by the LabView app [provided you know the netvar names].
• The Labview app is not included.
• Follow NI's example to create a LabView app that starts the netvars.  It is really pretty easy.
• I hacked this down from a much more complicated app that used threads to monitor connection strings.  It would see who sent what to the LabView app before connecting.  It would also watch strings and timers for changes or expirations.
• Remember you can't see the variables unless they change.
• Remeber to make sure your LabView app keeps a local copy of the varibles so it doesn't think they are new every single polling loop.  You need to check for change there.
• You can monitor multiple machines running apps with the same names, using a target string to create different netvars.
• This is really fast to get developed.
• MySQL and SQL2005 are waiting for you to collect data.  VB is the easy way to push/poll data.
• Don't forget to generate printouts using a pdf printer for your reporting!

[jdr_ni]

I would just mention that since LabVIEW 8.6, the read node for a Network Published Shared Variable has a blocking mode that will indicate whether the data returned is new. You should no longer need to keep around a copy of the data and do your own checks.

You can accomplish the same thing in older versions of LabVIEW by using the DataSocket API to read shared variable data, but this does require significantly more coding. 

J.D. Robertson

National Instruments