Multiple Client, Single Server Configuration

[stefanusandika]

Hello everyone,

I'm really new to LabVIEW and have been working on a machine testing project. I had experience before with C++ programming using Qt Nokia.

The machines are tested using NI hardware, connected via USB to the computer, all connection are in a local connection. There are currently 15 VI, each communicate to a single hardware. The main test program, which call the lower level VI (15 VI) based on a script. I would like to create a windows service, which could monitor these modules continuously (the program start when the computer start, and continuously monitor these 15 VI), and only send the data when the main VI ask for the value (the value suppose to be a real time value). I attached the block diagram.

I've tried to learn how to use STM and TCP/IP multiple connection, but I'm open to any advice and suggestion to build this project.

Thank you,

Stefan

Edited April 27, 2016 by stefanusandika

[ShaunR]

There are a myriad of ways you could realise this. It will depend on your preferred architecture (TCPIP RESTFUL API, Pub/Sub, TCPIP streaming, Websockets, UDP multicast...the list goes on). The 15 VIs are presumably all on localhost so are they just launched from one process (they all have access to each others data or are they separate processes each with TCPIP to be connected to?

I have a (very old) pub sub architecture in the CR. Dispatcher might do what you need with little effort but if not, you can use it to frame and demonstrate why it is not the right solution -  your images are pretty generic and only say "write and read some data through miscellaneous intermediaries"

Also, as a heads up....

You can't make a Windows Service in LabVIEW like you can in C++. Only an executable/DLL. So you either put a shortcut in the Start Up folder/registry or there is a program that can launch any program as a windows service (the name escapes me for the moment)

[Bryan]

I remember seeing an article many moons ago about creating a Windows Service-like LabVIEW application.  It involved using some files like "instsrv.exe" and "srvany.exe" (were these the files you're thinking of ShaunR?) or something of that nature.  The only service-like interaction that an app using the method could do would be for Windows to start and stop it.

[JamesMc86]

My favourite tool for launch as a service now is nssm (non-sucking service manager) - much easier than mucking about with the registry.

[stefanusandika]

Thanks for the reply ShaunR and Bryan,

@ShaunR : These 15 VI are seperated each other and each access the single hardware. Currently there are no connection between, except with the main VI. The main Vi actually only call the 15 VI one by one, and each VI will be excecuted under main program, and the result will be displayed after (using TDMS to display the result in excel file). I presume the name of the program is FireDaemon, is it correct? Most of the site I read before shows that they use FireDaemon for windows service.

In addition, I develop the system (using HAL) because the lower level VI like this 15 VI are always increasing all the time, so it's kinda hard to maintain the system (the system are spread all over the production area for testing purposes). With more and more Hardware, it would be easier if I have some kind of a system between both main.vi and Hardware VI.

@Bryan : Halo, I never actually heard about that one, I will take a look on it. Is it also develop using dll or Labview as well? Thx.

Gruß,

Stefan

[Bryan]

@stefanusandika: If I remember correctly, you have to design the VI that you want to be a "service" in such a way that it can be safely aborted when Windows stops it.  This would prevent proper shutdown of VI execution and cleanup of references, etc.  I haven't created a service using the method, so I don't know if there are techniques that can be used to allow safe shutdown of a VI.

I was able to find an NI Article on it, but it does involve tinkering with the Windows Registry.  @JamesMc86's nssm method does appear to be something worth a look.

[stefanusandika]

@Bryan : At most time the computer is always ON, however, the "safely aborted" would be one of the consideration. It's kinda confusing on how to create a generalized program to monitor different VI, not necessarily the windows service itself. However, a windows service could be a very helpful system to use.

@JamesMc86 : I'm currently reading about this. Do you have any example with you about this NSSM? Thanks

[stefanusandika]

@Bryan : Hi, I just realise that actually the computer is not always ON, after some period of time it has to be restarted. So, I will get your advice as a consideration in building the program. THX

[ShaunR]

1 hour ago, stefanusandika said:

@Bryan : Hi, I just realise that actually the computer is not always ON, after some period of time it has to be restarted. So, I will get your advice as a consideration in building the program. THX

I wouldn't think too hard about how to set it up as a service. It's not an imperative to your design so you can decide later. Think long and hard about how you want the actual software to be constructed then, once it is working, decide how best to start it. Your hands are tied here and very few of us have ever created a LabVIEW service so don't get hung up on it.

 

23 hours ago, Bryan said:

"instsrv.exe" and "srvany.exe" (were these the files you're thinking of ShaunR?)

Yup. That sound familiar.

[stefanusandika]

@ShaunR : Hi again Shaun, thanks for your advice. I was just thinking that it would make it easier with the program as a windows services. Most of the guy in the production areas never work with LabVIEW, so the windows service could be a pretty handy solution. However, you are right that I should be giving more attention on the program, the windows server can be created later.

[stefanusandika]

Hi all,

In the case of localhost communication, with continuous data exchanges from multiple client to server, what method would you use?

Thanks

[ned]

3 hours ago, stefanusandika said:

In the case of localhost communication, with continuous data exchanges from multiple client to server, what method would you use?

My first thought is UDP or VI Server, but there might be a good way to do it with shared variables since if I'm not mistaken (I haven't used shared variables, just read about them) you can have a single shared variable engine storing and sharing data for multiple clients.

[ShaunR]

3 hours ago, stefanusandika said:

Hi all,

In the case of localhost communication, with continuous data exchanges from multiple client to server, what method would you use?

Thanks

For an internal server (since they are all under one process) I would suggest Events or queues depending whether you are pulling or pushing the data. This will be the fastest and most efficient

TCPIP I would suggest Network Streams.

UDP anything but multicast.

[smarlow]

Is there any particular reason why you would use TCP and LocalHost communications, such as having pre-compiled internal process VI's that are in a different scope than the Main VI?  If not, one of the best ways to do this is with Notifiers (or queues, but I prefer Notifiers).  If all you want in the Main VI is the latest data, and you don't care about old data being overwritten, the Notifier is the way to go. Each of the 15 subVI's would poll the hardware continuously and send data to its own notifier.  The Main VI waits on notification from the internal process subVI's notifier and gets the latest update when it arrives.  Set the "ignore previous" input to the "Wait on Notification" function to TRUE to make sure you get the latest update when you call it.  

With this architecture, you don't need to send requests to the internal process VI's; you just wait for the latest update.  As long as your update rate on the "Send Notification" end is faster than your longest tolerable latency period, you'll get the data within the time you need it.  If you want to send requests, you can use a Notifier in the opposite direction.  Call "Wait on Notification" in your internal process VI's and wait forever (-1).  Send Notification from the Main VI to make a request for data, and use a separate return Queue or Notifier to send the data back to the main VI.  This type of architecture is similar to the way the Actor Framework works, at which you also might want to take a look.

[stefanusandika]

Hi everyone,

I hope you guys have a good weekend!!

@smarlow : Thanks for your reply. There is no particular reason actually, I was trying to find the best way for the abstraction layer and TCP was the first article came up to me. I never work with LabVIEW before, therefore I took it as an option. Back to the problem, I will take a look on Notifier, however, in my case, main.vi are suppose to read the real-time (means there will be multiple data) only when the mian.vi is needed. My uderstanding on your writing is that Notifier only able to read single data (the last data from measurement). Am I correct? Do you have any example on your related work with this kind of problem? Thanks!

@ShaunR : Thanks for the reply. I will read your suggestion further.

I also attached the project below. The main.vi (the main program) is located under programm, the analog is analog values which are connected directly to the hardware, and the server is the initial idea for the abstraction layer.

Once again, thanks for your reply. This is very helpful and very good for a begineer like me!!

CTS Project.rar

Edited May 2, 2016 by stefanusandika

[smarlow]

1 minute ago, stefanusandika said:

Hi everyone,

I hope you guys have a good weekend!!

@smarlow : Thanks for your reply. There is no particular reason actually, I was trying to find the best way for the abstraction layer and TCP was the first article came up to me. I never work with LabVIEW before, therefore I took it as an option. Back to the problem, I will take a look on Notifier, however, in my case, main.vi are suppose to read the real-time (means there will be multiple data) only when the mian.vi is needed. My uderstanding on your writing is that Notifier only able to read single data (the last data from measurement). Am I correct? Do you have any example on your related work with this kind of problem? Thanks!

@ShaunR : Thanks for the reply. I will read your suggestion further.

Thanks!

Stefan:  If you can't tolerate the loss of any data that is collected between reads, then a Queue is the way to go.  There are several examples in the LabVIEW Help.  Select Help>>Find Examples from the LabVIEW VI menu.  Use Search from the Find Examples dialog and search for "queue".  The "Simple Queue.vi"  shows how to use a queue to share data between loops; but the same method can be uses to share data between VI's.  Just make sure your Main VI reads the queues fast enough to clear them, or you could get an overflow.  Examine the "Queue Overflow and Underflow.vi" example to learn about overflow.   Good luck!

[smarlow]

@stefanusandika I have attached a simple example of a multiple queue program architecture.  The Main.vi creates three named queues.  There are three copies of a reentrant subvi that generate three sine waves 45 degrees out of phase to simulate your "internal process" subVI's.   The subVI enqueues a value from the sinewave very 100 ms. The Main vi reads these three queues and graphs the values.  Notice I set the wait period to 200 ms on the dequeue function calls.  This is longer than the 100 ms between enqueue operations in the subVI's.  

Queue.llb

[ShaunR]

OK.

So you have a number of processes that handle different IO devices/hardware/things that sit in the "Analog" directory. Most of these (I only looked at a couple) seem to be self contained applications in their own right with things like TDMS logging of data and in-line analysis. By "Applications" I don't mean executables, by the way, just that they can exist standalone.

These applications share their data via some Functional Global Variables (FGV_Sensors, FGV_Can et. al.) which are  used to collate and store the data for reporting and stuff.  These are effectively the" Internal Process" you show in your images that your were talking about creating. Well. You already have them - sort of  There were also some global variables in the "Globals" directory but these seemed to be concerned with UI state and list management so I didn't look too closely..

So the question is. Are you looking to bolt on a TCPIP interface on the existing software; changing as little as possible then walk away to do more interesting stuff. Or are you looking to refactor completely for reasons like  future-proofing, identifying reuse, enlightenment, and other noble sacrifices of your time - and while you are at it, put a TCPIP interface on it?

Or,put another way How bad do you think the current (working) code is and whats wrong with it?  

Edited May 2, 2016 by ShaunR

[stefanusandika]

18 hours ago, smarlow said:

@stefanusandika I have attached a simple example of a multiple queue program architecture.  The Main.vi creates three named queues.  There are three copies of a reentrant subvi that generate three sine waves 45 degrees out of phase to simulate your "internal process" subVI's.   The subVI enqueues a value from the sinewave very 100 ms. The Main vi reads these three queues and graphs the values.  Notice I set the wait period to 200 ms on the dequeue function calls.  This is longer than the 100 ms between enqueue operations in the subVI's.  

Queue.llb

Thanks for the reply @smarlow !!!

Can you probably attached the lower version? My labview is 13.0.1f2 (32 bit) so I can't opened it. Thank you so much!

[stefanusandika]

14 hours ago, ShaunR said:

OK.

So you have a number of processes that handle different IO devices/hardware/things that sit in the "Analog" directory. Most of these (I only looked at a couple) seem to be self contained applications in their own right with things like TDMS logging of data and in-line analysis. By "Applications" I don't mean executables, by the way, just that they can exist standalone.

These applications share their data via some Functional Global Variables (FGV_Sensors, FGV_Can et. al.) which are  used to collate and store the data for reporting and stuff.  These are effectively the" Internal Process" you show in your images that your were talking about creating. Well. You already have them - sort of  There were also some global variables in the "Globals" directory but these seemed to be concerned with UI state and list management so I didn't look too closely..

So the question is. Are you looking to bolt on a TCPIP interface on the existing software; changing as little as possible then walk away to do more interesting stuff. Or are you looking to refactor completely for reasons like  future-proofing, identifying reuse, enlightenment, and other noble sacrifices of your time - and while you are at it, put a TCPIP interface on it?

Or,put another way How bad do you think the current (working) code is and whats wrong with it?  

Hi @ShaunR !!

Thanks for the reply.

My initial tought about creating this was because there are so many hardware which grows so fast in the current time. There are some kind of 30 computers with this program running locally. Once there is a new hardware, I have to maintain 30 computers one by one, and in the future, we are planning to increase the use of this system in a new computer (also locally). So with the abstraction layer, I can easily maintain more, with less effort.

The TCP/IP is one of the option I found out earlier. The other way are still in a try. Since abstraction layer is between the main.vi and the hardware VI, my idea was to implement the connection via localhost from hardware VI to the abstraction layer. This require a transfering program like TCP/IP, notifier, queue, etc. In the future, I hope that the abstraction layer can actually work as a windows service, which continuously monitor the hardware and sending the data, while main.vi receive a continuous real-time Data.

Regards,

Stefan