LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Dr. Damien's Development - Running Top Level VIs IV - A Tale of Two Servers


DFGray wrote:
Ben, are you using DCC yet?  It does simplify things quite a bit.  Implementing DCC in LabVIEW is a challenge, though.  The timing is tight enough that you will need a modern DAQ board or, much easier, an FPGA card to pull it off.  I did a demo system in LabVIEW 7.1 using cRIO a long time ago, but it worked very nicely.  Unfortunately, it is much cheaper to just buy the controlling system that to make it in LabVIEW 😞 .

 

We have the ablitiy to support up to 8 Cabs. Three are allocated for the traditional control, cab 4 will be used for DCC (Digital Cab Control). WE currently have very few engines equiped with DCC but we have planned for it.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 31 of 37
(1,397 Views)

Daklu wrote: 

I still don't like user events as a solution because:

  1. By using a single user event the client doesn't have the resolution to shutdown a single server.  It's either all or nothing.  What happens when one of the servers gets into an error state and I need to restart it?  The workaround for this is to create unique user events for each server, but then you've lost the advantage of the "single click" shutdown.
  2. To use a single user event requires all your server objects have the same data type for their StopEvent.  If the server objects are developed independently this can be very hard to ensure.  Furthermore, enforcing this policy puts unnecessary constraints on developing new server objects.  What if while writing a new server object I wanted to allow the client an option to include a comment for the log when shutting down the server?  I can't do without resorting to a clunky workaround, such as exposing a SetExitMessage method.
  3. By exposing the StopServer functionality as a user event instead of a method, you've forever locked in that data type.  Even if I wanted to change all my servers to include an optional comment I cannot go back and change that event's data type without breaking all the client code that has been built.  Had I used a sub vi, it is trivial to add an optional ExitMessage input.
  4. Looking at the server object's API, issuing some commands via sub vis and other commands via user events makes things more complicated for the client.  If I'm developing a client that uses your server and I see a LaunchServer method on the palette, it is reasonable to expect there would also be a StopServer method there.  There's no symmetry.  Exposing a RegisterStopEvent is a little better, but still not a great solution IMO.
  5. I mentioned it earlier but it bears repeating, issuing server commands via user events requires the client code to create and manage those user events.

It is possible to devise workaround to most or all of these issues, but why bother?  Exposing the StopServer functionality via a sub vi rather than a user event solves all of those problems and is so much easier in server code and in client code.  If the main advantage of using the user event is that the client code can close everything in a single action, write a StopAllServers sub vi that calls each server's StopServer method.  I'm open to the idea of injecting user events into code.  I think there might be valid reasons to do it (though I haven't thought of any yet), but I don't think this is one of them.  Is there some advantage that I've missed?

 


Nice thread. Makes me want to learn OOP even more, if I can find good advantages and disadvantages for using it and in what cases. At least learning it. Smiley Happy

 

I agree with Daklu's comments. Ive a multiple server architecture. It is very good for me to in addition starting them individually, also having the opportunity to shut them down individually. I tested it once with a huge setup with around starting 400 servers. On shutdown I had a more difficult hardware shutdown procedure. I shutted themdown in the timing order and sequence that I wanted. Technically with a single user event when I try to shut them all down simulatniously I think the computer gets a bit angry. Also, a sequential shutdown is better here for me due to better control..

 

Now, I only have only client but am in the process of pehaps making the structures around the server more dynamically so multiple are supported. Due to that each client is dynamcally loaded into a top layer application (due to that each clients form is a plugin in a larger program) any top layer network communication must go through the top layer program in my case so it has the overall control. dont really see a mega point for doing this, but just liked the thought Smiley Tongue . Having the VIT to acceppt queue calls from another application reference or comp directly is still a bit mystery right now but havent looked into or tryd.

 

Now but what I really wanted to ask if any of you know when your application should be able (not a must, but nice) to handle large amounts of VIT's and checking everything is OK. Now mostltly in my case the servers live mostly their own life, with little communication non-stop, but how will large communication over a large number of dynamic queues affect the software? some kind of watchdog/heartbeat/"ping" to know if the server is alive and not something really weird and unexplanable has happend? Ofcourse, the server has errorhandling and reports it to an errorhandle module that will choose what it should do, but Im just curious of the stability of many VITs in memory, and if some should "unexplainally dissapear without reporting error" and the best approuch to finding out of this? eather checking for error when your sending a command, or is it better to sometimes check the VIs in memory? (what I guess is a more consuming task). Dont know if anyone can understand me, am perhaps thinking loud, was thinking of some kind of health monitor module or something, in case something gets corrupt in memory or whathever, and doesnt report out an error as it should (so that the errorhandle module wont do its job, and then I want to have the "health" monitor to actually see that something is wrong, as backup. (and you have the criteria that this must be mega stable for like 20 yrs w/o error or any corruptness or anything..)  Smiley Wink any tips among you LV guru's?

0 Kudos
Message 32 of 37
(1,371 Views)

What order of magnitude are you thinking when you say "large amounts of VITs"?  Tens?  Hundreds? Thousands?  I could envision systems anywhere along this line, but health monitoring code would probable be different depending on the number.  For example, a simple health monitor would have each VIT update a globally accessible variable (action engine, single-element queue, data value reference, global, etc.) containing an array of timestamps.  A monitor could check occassionally to ensure that all the timestamps fall into a certain band.  If not, the index of the incorrect timestamp could be used to locate more information about the VIT (VI reference, communication references, etc) which could be used to query and/or shut down the VIT.  This sort of thing fails when you have thousands of VITs, since the access to the global data storage ends up being a bottleneck.  You need a new paradigm.

 

As to what you will run into?  I don't know.  I have never done anything quite like this.  Experience shows that when you push the boundaries, the boundaries push back, often in unexpected ways.  That is what makes pushing the boundaries so fun!  However, it is highly destructive of deadlines.  Good luck.  Start a new thread with your experiences if you do this so we can all learn.

This account is no longer active. Contact ShadesOfGray for current posts and information.
0 Kudos
Message 33 of 37
(1,350 Views)

Corny wrote:
...

 

Now but what I really wanted to ask if any of you know when your application should be able (not a must, but nice) to handle large amounts of VIT's and checking everything is OK. Now mostltly in my case the servers live mostly their own life, with little communication non-stop, but how will large communication over a large number of dynamic queues affect the software? some kind of watchdog/heartbeat/"ping" to know if the server is alive and not something really weird and unexplanable has happend? Ofcourse, the server has errorhandling and reports it to an errorhandle module that will choose what it should do, but Im just curious of the stability of many VITs in memory, and if some should "unexplainally dissapear without reporting error" and the best approuch to finding out of this? eather checking for error when your sending a command, or is it better to sometimes check the VIs in memory? (what I guess is a more consuming task). Dont know if anyone can understand me, am perhaps thinking loud, was thinking of some kind of health monitor module or something, in case something gets corrupt in memory or whathever, and doesnt report out an error as it should (so that the errorhandle module wont do its job, and then I want to have the "health" monitor to actually see that something is wrong, as backup. (and you have the criteria that this must be mega stable for like 20 yrs w/o error or any corruptness or anything..)  Smiley Wink any tips among you LV guru's?


Memory was my limiting factor.

 

I was able to run over 100 templates with multiple queues talking to and from same without any problem or excesive CPU load. I have a in-house Event Logging utility I integrate into these types of apps so if something goes wrong and I can can detect it, it get logged. The Event Loger is yet anoteh background process that uses a thread to pass the contents of Error Cluster from where they are detected to a log file.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 34 of 37
(1,348 Views)

DFGray wrote:

I think we will have to agree to disagree on this one.  I see your points, and they are valid.  However, I like to use events to shut down multiple servers (I usually use response queues to ensure they have shut down).

 

In addition, the use case you quote for parallel processing does not appear to be a server, but one-shot processing which returns a set of strings.  For a server, the strings would remain in the server until fetched by accessor functions.  To me, writing a server allows you to avoid the type of client side code you have presented, making the users job much easier.  As you point out, it does require more of the server.  But I have found that this make maintenance and future expansion much easier.  However, this is my opinion.

 

Thanks for posting!


To be clear, I wasn't trying to say you're wrong--I was simply trying to understand why you prefer injecting a user event over calling a method.

 

I also think I didn't fully understand what you meant by "server."  I took it to mean any remote process that operates somewhat independently, such as an active object.  It looks like you are referring to something more akin to a separate application or service.  Is that correct?

0 Kudos
Message 35 of 37
(1,252 Views)

Yes, I think of a server as a providing a service, not just a simple, top-level VI.  "Server" is an overloaded word.  The *nix folks tend to use "daemon."

This account is no longer active. Contact ShadesOfGray for current posts and information.
0 Kudos
Message 36 of 37
(1,227 Views)

Dear all;

 

Has anyone successfully created the active object using LVOOP 2010?

DAKBIAS
0 Kudos
Message 37 of 37
(651 Views)