LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Case study: "Large?" labview programs flooded with different VIT's

Case study: "Large?" labview programs flooded with different VIT's

 

Type of application: Computer with loads of individual hardware connected or other software (either onsite (different buses) or offsite (Satelite/GSM/GPRS/radio etc.).

Hardware description: little data "RPM" but communications to all devices are intact. More "RPM" when many VITs are involved.

Size: 1000+ VITS in memory (goal). Total software has been tested and simulated with 400.

 

I'm posting this post after reading this thread (and actually I cant sleep and am bored as hell).

 

Note: I do not use LVOOP (but sure post OOP examples, am starting to learn more and more by the day.) Smiley Happy

 

Things I will discuss are:

 

Case 1: Memory usage using a plugin architecture

CASE 2: memory usage using VITs (!)

CASE 3: updating datastructures:

CASE 4: shutdown of the whole system

CASE 5: stability & heath monitoring

CASE 6: Inifiles

CASE 7: When the hardware is getting crappy

 

Total application overview:

We have a main application. This main application is mainly empty as hell, and only holds a plugin functionality (to register and administer plugins) and holds an architecture that holds the following items:

Queue state machine for main application error handling

Queue state machine for status messages

Queue state machine for updating virtual variables

Event state machine for GUI

Some other stuff

Other global functionality is:

-          User logins, user configurations and unique access levels

-          Different nice tools like the good old BootP and other juicy stuff

-          Supervision of variables (like the NI tag engine, but here we have our own datastructures)

-          Generation of virtual variables (so that the user can configure easy mathematical functions and combining existing tags)

-          Licensing of plugins (hell we free-lance programmers need some money to don't we?)

-          Handles all communication between plugins themselves, or directly to a plugin or vice versus.

And now we don't talk about that (or marketing) the main application Smiley Very Happy.

Message Edited by Corny on 01-20-2010 08:52 AM
0 Kudos
Message 1 of 22
(4,396 Views)

Each plugin holds a different function. It can be to update stuff on the internet, it can be database connectivity etc etc. but is mostly holds the hardware communication. Each plug-in has a GUI and several functions to administer VITs Smiley Tongue , launching them and configuring and communicationg with them correctly. The GUI is mainly used to configure the plugin (if the user has access rights) and seeing statuses, controlling stuff manually etc.

 

Case 1: Memory usage using a plugin architecture

If you load in a plugin (and their subvis) into an application that already has items in memory, these items you load in must not have the same name. So actually, if you have some Vis that also other plugins use you have duplicated these in the memory due to you must use different file names. Why not share the same plugin SUBVIs with each other, if we can put them in the main library of the application that is loaded when the main application starts to run? ‘

Reson: if you have several plugins, and you have updated one of them, including this shared SubVI, you'll get trouble with already existing plugins that use this subVI - but are expecting an older version with other functionality, and the plugin would malfunction.

Possible solution: (please comment J ) Perhaps giving the filenames a version ID at the end? The Pro's would be that memory usage would lessen - lesser items in memory. The con's would be that if an plugin gets updated often, the main library will hold after a while huge amounts of different file versions and load these into memory. Unless there it is possible to do some cleanup by knowing what subvis are currently used or not? Any opinions?

Message Edited by Corny on 01-20-2010 08:57 AM
0 Kudos
Message 2 of 22
(4,394 Views)

The plugins:

A plugin can communicate directly to the main application with non-dynamic content (as the main application is the executable and we must be carefull updating this one unless things are thought through carefully). The main job of the plugin is to do a type of task, or more, and having a GUI. In our case we let this task be to communicate with like 250 hardware units, configure them (if not preconfigured from inifile) and control them manually and automaticly etc. lets just say250 RS-232 hardware to make it more interesting (well, lets just imagine we have 250 serial ports, this computer is a turbowild computer you see)

Well, since we imagine we have configured 250 hardware units for this plugin alone with different configurations, and now we want to run them.

VIT's: For people who have read this stuff so far and are not familiar with VITS:  a VIT is a VI template. When you call it is mainly a VI in memory, and clones it etc. The purpose in this case is to have a SINGLE VI that is cloned to communicate with 1 device. So actually we write only one small code to communicate with all these units, instead of hardcoding 250 subvis (well good luck), or one VI to communicate with 250 units, wich wont work if we want them to function in parallel.

 

The code for running them is similar to this thread, but not in LVOOP, and does not support multiple clients. In this case we don't need multiple clients to control it, otherwise this huge system would get out of control with who's controlling who and where and when etc. etc. Will try and update it sooner or later in a new OOP version that also supports multiple clients. Pretty impressive thought of creating it so dynamic that way J

0 Kudos
Message 3 of 22
(4,392 Views)

VIT & communication

To let the VIT communicate with the rest of the world, it will need some references to queues or whatever. But for other stuff to communicate with the VIT, the VIT needs a queue (or other) reference - that we create when we first load the juicy thing into memory, and we then pass this reference to a control.

How the VIT could look like. Well, that depends on what it is going to do. What we want it for it to communicate to serial device whit a stupid impossible propertaty protocol for example.  Since we use RS232 we need to read data from the bloody thing all the time and create an buffer in case the unit does not send its datastring in one bit but has al little delay in between sometimes. Well one more shiftregister to add somewhere.

But generally we want it to have a type of state machine with states like for example:

-          Init

-          Handle

-          Command

-          Close connection

-          Stop

And we recieve these commands through an queue Smiley Tongue.

 

Init: read the received configuration of the device and puts it in the shiftregister. This configuration can decide how the handle case will work.

Handle: well, in this case communication toward the serial device. Perhaps a timer so that I can poll, and recive messages. Now whatever it must do we want to let this device to be as an individual process as possible, if we want to do all stuff manually, we end up having a huge communication to and from the VIT.

Command: Other stuff can send a command to it.

Close connection: close the RS232 port

Stop: stops the VI from running, and let it be removed from the memory

 

If any error should occure this is sent down to the plugin for errorhandling (an queue state machine) and let that module decide what action to take. If any status information, this is sent to a status queue statemachine in the plugin. The plugin handles all communication toward the main application if needed (and if needed the main application can shuffle this onwards to other plugins)

 

So essentially we now have a structure communicating between different plugins, handling different hardware in large numbers, and well how we program it we can do whatever we can do with hardware limitations ¤%#"&.

 

CASE 2: memory usage (!)

We want the VIT's to have least memory usage as possible. It should be as small as possible and not using memory clone functions ofcourse. Otherwise this is going to be a load full of crap with many VITS.

But here I have an problem: to avoid much communication traffic I want the VIT to be as "selfish" as possible, (and this will add some code and shift registers in it). I don't know if this is the right solution so please come with critics. It will add more memory, but will lessen the communication needed. Also, usage of subvis that are not reentrant is not possible if we have many VITS. This will also add much to the memory.

 

Message Edited by Corny on 01-20-2010 09:03 AM
0 Kudos
Message 4 of 22
(4,391 Views)

CASE 3: updating datastructures:

 As we do NOT use clusters here (that would just be consuming) we only use an 1D array of data that needs to be updated in different functional globals. If the the number of VITS exceeds so that the updating of this datastructures becomes the bottleneck, this would cause delays. And since in this example we use 250 serial interfaces (lol) we do not want to disrupt that by any delays. When this happends, does anyone know a good solution to transfer data?

A thought: perhaps sending it down to the plugin and let the plugin handle it, this should save some time, but then again if more VITs are added again this would become a bottleneck and the queue would fill up after a while unable to process it fast enough. Any opinions?

 

CASE 4: shutdown of the whole system

Lets say we want to close it all down, but the VITs need perhaps to do some shutdown procedure towards the hardware, that can be heavy.

If we ask them to shutdown all together we can use an natofier or userevent to do this job. Well, what happends next is that the CPU will jump to the roof, and well that can only cause dataloss and trouble. The solution here was to let the plugin shut them all down one by one, when one has been shutdown, begin at the next. Pro; CPU will not jump to the moon. Con's: shutdown is going to take a while. Be ready with a cup of coffee.

Also we want the main application not to exit before we exit. The solution above solved this as the plugin knows when all have been shut down, and can then shut itself down. When all plugins are shutdown - the application ends.

Another solution is to use rendovous (arg cant spell it) and only shut the system down when all rendezvous have met.

 

CASE 5: stability & heath monitoring

This IS using a lot of memory. How to get it down. And has anyone experienced any difficulties with labview using A LOT of memory? I want to know if something gets corrupt. The VITs send out error information in case, but what if something weird happens, how can I surveillance all the VIT's in memory to know one is malfunctioning in an effective way/code (as backup solution  so the application knows something is wrong?

 

CASE 6: Inifiles

Well, we all like them. Even if XML is perhaps more fahionally. Now Ive runned some tests on large inifiles. And the labview Inifile functions use ages to parsing all this information. Perhaps an own file structure in binary format or something would be better? (and rather create an configuration program)?

 

CASE 7: When the hardware is getting crappy:

Now what if the system is hitting the limit and gradually exceeds the hardware req. of the software. What to do then (thinking mostly of memory usage)? Needing to install it on more servers or something and splitting configurations? Is that the best way to solve this? Any opinions?

 

Wow.  Time for a coffee cup. Impressive if someone actually read all of this. My goal is to reach the 1000 VIT mark.. someday.. so any opinions, and just ask if something unclear or other stuff, Im open for all stuff, since I see the software will hit a memory barrier someday if I want to reach that 1000 mark hehe 😛

 

0 Kudos
Message 5 of 22
(4,390 Views)

Corny wrote:

...

 

Wow.  Time for a coffee cup. Impressive if someone actually read all of this. My goal is to reach the 1000 VIT mark.. someday.. so any opinions, and just ask if something unclear or other stuff, Im open for all stuff, since I see the software will hit a memory barrier someday if I want to reach that 1000 mark hehe 😛

 


I have not had access to a 64 bit machine with a full compliment of memory but I think what you are asking is possible with modern hardware within limits. AS i mentioned in that other thread I have done more than 100 VIT's and the limit at that time was memory.

 

I'd start with some benchmarks of the most demanding CPU work you anticipate to decide in a single node will be able to keep up. If it looks like you may be pushing hardware, then design to use multiple machines to do the work.

 

Over-all your task as outlined should be very "do-able" (it better be, I'm woking on a LVOOP version in my spare time).

 

I also think that LVOOP would help you do this task easier since if you write a parent class that contains the core functionality found in all of your plug-ins, then you could create child classes that inherit all of those methods and can be customized to what each flavor of plug-in needs.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 22
(4,341 Views)

I just tried the VIT from this Nugget and 200 VIT worked fine.

 

I cranked it up to 1000 and it made it to 780 but now its stuck.

 

Not sure what that means...

 

Ben

Message Edited by Ben on 01-20-2010 08:33 AM
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 7 of 22
(4,331 Views)

That 780 limit may have been Windows related. When trying to kiil the LV stuff, Task manager indicated there 980 Template running...

 

Will stop poking at this for now.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 8 of 22
(4,317 Views)
You can use the property AllVIsInMemory to get the clones. Thus you might (see Ben's observation on a 780 limit) be able to count them.
Using the names in the VI Server should also allow you to access the state to see wether it's still running.

Felix
Message 9 of 22
(4,301 Views)

I would recommend using reentrant VIs instead of VITs if at all possible. This should only help the memory required, because a reentrant VI instance doesn't require a clone of the entire VI, just the dataspace. A VIT, on the other hand, is like a completely separate VI.

 

As of LV8.0, there is only a very small set of limitations of reentrant VIs versus VI templates, such as:

  • Can't change tip strips on a reentrant VIs front panel, because tip strips are not part of the cloned data space and the change tries to affect all clones.
  • Can't debug reentrant VIs on RT.
  • It's a little harder to find your reentrant instances for debugging if they're running as top-level VIs and don't have their front panels open, because the Get All VIs in Memory function only registers the base instance, not all the clones. I have a tool that helps with this, though.

Also, besides saving memory it should improve load time to use reentrant VIs, because you really only pay the load penalty for the first instance. The secondary loads will be much quicker.
Jarrod S.
National Instruments
Message 10 of 22
(4,287 Views)