Greg Hupp

I say this from a standpoint of that I have never heard of anything that ensures that they will be ordered properly.

There is most likely a high likelihood that they will, but this only highlights that people write programs that assume this.

If AQ or someone in R&D pipes up and says that it is ensured, then I'll fully retract that. But I will never recommend that anyone write a program that depends on having multiple Val(signl) strung together to execute the events in that order for all those reasons above.

So I can second Norm's statement and say value signaling is definitely something to try and steer clear of. From code I inherited, my experience is that value signaling can cause all kinds of problems in that you don't always know the order of the firings. Using events, queue, etc are much better...and would try and guide newbies to this method rather than the value signaling.

See if this helps (LV 8.6.1)

Mark

ErrorLogger.zip

Yeah...this is similar to what I had...but wrapped up a little better! Thanks.

Working with a large app that spans several parallel running VIs (a master VI and a couple dynamically called VIs) and trying to implement a quality error handling/logging functionality (the previous version didn't have one and I hacked something into it as an intermediate update!)

Currently, I have a produce consumer, that has a small error VI that triggers and event that is handled in the producer loop...the action can be handling/logging etc.

Anyone have any clever error handling architectures or ideas that might be of use?

Does your installation package the various plugins? This may help if the installation were to update all the components. This does bring up an interesting issue though of how you can manage updates to the plugins. Have you considered using JKI's Package Manager?

The installation used is a separate scriptable installer used due to the scope of the end application. I can update the components, but LV apparently doesn't always respond favorable to change one of the components. And yes...this is my current dilemma in trying to update the plugin VIs/controls etc. Am not very familiar with the JKI Package Manager and unsure at this point if I want to try and introduce another level of complexity to this system and deliverable. Do you have any experience with the Package Manager?

How are your applications deployed? Are they built as stand-alone applications or are they actual VIs? If they are stand-alone applications you shouldn't have issues with new applications using updated versions of VIs. If you are distributing raw VIs and hoping to keep everything up to date the only option you have would be to recompile the VIs. You could potentially write an application that would go through your code and load, recompile and save the affected applications but this isn't an ideal solution. This application would need to have a list of the applications it needed to update and somehow report any failures it encountered. This would make the maintenance process fairly complex and subject to problems. The best solution is to build your applications are stand-alone executeables.

Also, are you using projects for your applications? If not you should really consider using them. They help to manage this process.

Thanks....this is a very complex large app that is a plug-in based architecture. The main app is an executable and the plug-ins are just distributed VIs...this is kind of the answer that I expected, I just wanted to see if anyone had come across a better way to do this. And yes...I use projects...much easier to view all the pieces that are used!!

You can run a mass compile on the directories that contain the affected code. The mass compiler is available at "Tools->Advanced->Mass Compile". You will need to select the directories containing the top level VIs that you want to fix. If everything is under a single directory you will only need to select that one directory.

Thanks...yeah this is an option although I am trying to figure out a way to do it at install time (say update to existing installation...patch type thing). I really have no way of actually opening up LabView to recompile any VIs.

I have an application in which I need to update several subVIs that are being used. Is there a way that I can update any VIs that use the subVIs can be recompiled at the command line (or other) so that the main VI is not broken? These VIs are not part of a main executable, so they are just substituted in place of the old ones. Care was taken to not change the position of the existing pins on the connector pane (although some were added on the new one) to prevent breaking anything using the subVI.

It is as simple as opening the main VI and resaving it...no modification required -> so it seems like this should be able to be done relatively easily.

QUOTE (jmax007 @ May 26 2009, 06:45 PM)

I am new here to LabVIEW and was hoping for some recommendations.

I need to read the data from a file/spreadsheet, into an array of clusters. This sounds like something that must be common, but I can't seem to find a good example

Basically I have an excel sheet that contains setup information that I want to load into an array of clusters.

row1 is a cluster, row two is a cluster etc...

Since I am new to LabVIEW, I can imagine that I could use the "read from spreadsheet.vi" , but it only allow me to read the whole file as one data type. I could do this several times reading from the same file, but using a different data type each time, then using indexing to parse the data and create my cluster of arrays.

This sounds ugly and I am guessing there might be an easier way to actually read a file into an array of clusters. If not, then I will do it the "long route"

I am using LV8.6 and the file format is not important because I will be writing and maintaining the setup information.

This forum has been a great help so far and I thank everyone who uses it.

http://lavag.org/old_files/monthly_06_2009/post-12023-1243878714.jpg' target="_blank">

You can always read it in as an array of strings using test file read...the parse using the scan from string function (if you know the format of the data AND it is always constant). Otherwise you can using other scan functions to break up the string by delimiter (tab if it is a spreadsheet) and parse it that way.

QUOTE (Imagineer @ Dec 11 2008, 05:25 PM)

Greg Hupp - Thanks for the suggestion, it would be nice if you could give an illustration ?

The "Event" VI shown is a dynamic dispatch VI and the object (cube) determines which of the children "Event" VI to run. There should also be an example in the examples installed with LV.

http://lavag.org/old_files/monthly_12_2008/post-12023-1229380716.jpg' target="_blank">

QUOTE (Norm Kirchner @ Dec 11 2008, 04:25 PM)

Well in your system (if memory serves correct)you only have 3 primary portions of the program going (the main host, the device control and the data analysis) so it's rather fixed if you think about it like that.

Yeah and it is although I am think of future potential to allow more than more analysis tool at a time...we still have that now, you just have to switch back and forth. So I don't know if this is a tradeoff for the better or just more work!!

As a side:

If you want to get creative...you could setup some dynamic dispatching type architecture and define your different clusters/types as object and then create the associated function. It helps clean things up in your program and allows for easy modification and addition of other/existing types and functions.

QUOTE (Norm Kirchner @ Dec 9 2008, 02:37 PM)

This would be a LV2 Style Global from which you could pass in an enum which would dictate which ref you passed out.

Inside of this you would register the slave and master Q and as the slaves go dead and are replaced w/ another one you just register the new ref.

This sounds reasonable but I am unsure of the enum to the LV2 style global. Unless you are referring to it to use as a command enum (add, find, etc)....how can I create an enum when I don't know all the queue references? I suppose you could have standard values: enum{queue1, queue2, queue3...) but you would need to fix it at a certain number. Whle currently, there probably would be a fixed number of queue references floating around, I would like to try and leave it open so other functionality could be introduced if and when needed. Am I just missing the point here!?

QUOTE (mesmith @ Dec 9 2008, 01:49 PM)

Here's what I'm talking about (if you don't use reentrant VI's) - it's not specific to any target, it just shows how you might use a named queue to communicate with a dynamically launched VI. It has some advantages over using the Set Control Value methods since it's not sensitive to the control names on the dynamically launched VI. It does, however, have one drawback in that if the caller actually leaves memory before the callee gets the queue ref, the queue ref might get garbage collected before the callee can get a ref. If the dynamic launcher is, for instance, in a UI that stays in memory, that won't be a problem. Also, you could just leave the Create if not found True and avoid this problem. This also presumes that you're going to pass data to the slave from some VI other than launcher, but you could easily pass initial data from the launcher.

Mark

http://lavag.org/old_files/monthly_12_2008/post-1322-1228852101.png' target="_blank">

Yeah...think this will work...may put some hooks in to handle re-entrant VIs, but I can prototype the base architecture using this concept I think...queue is already typdef'd....typdefs are "our friends"! :laugh:

QUOTE (mesmith @ Dec 9 2008, 12:40 PM)

This is a good point - if you launch multiple copies of a reentrant clone, you have to make sure you communicate with the correct one. But one way to do this is when you launch the reentrant VI, get the VI Clone name - this is available thru the VI properties using the ref you just opened. Use this to build the Queue Name string (like InputQueue_%s formatted into string, which becomes something like InputQueue_My_VI:1). Then have the spawned VI get its own Clone name thru VI Properties and open the same queue. Then you have a unique one-to-one association without ever actually passing anything on a wire to the spawned VI.

Mark

Hmm...this is interesting. They slave VIs will indeed probably be different VIs not reentrant. Although, I still would like to be able to create the queue of the form Queue_%d (as you mentioned) in the master and then have the slave pick it up! To do this, I still need to pass the information. I like the named queue approach, but I am a little wary of having defined values in the program. This is kind of an open development system, so it needs to be able to function without knowing the specific target it is talking to...only that certain generic commands will be recognized.

I have an application in development that I need to have a main controlling application and several other dynamically loaded VIs ("slaves"). The main application acts as the master controller for communication and control over processes dealt to the respective dynamic VIs. Therefore, all these need to be parallel processes.

I think this application is perfect for using queues: 1 for the master VI and 1 created by the master for each of the dynamic VIs. I can then pass each dynamic VI the queue references for the master and the one created by the master for the slave VI for bidirection communication between the master and slaves. However, how is the best way to pass the queue references?

If I use a call by reference that allows inputs that can be the queues, the execution is halted for the master VI until the slave finishes. This defeats the parallel operation requirement. If I use the Run VI method and set the Wait for Finish to False, this works but I cannot pass the queue references into the slave VI.

Any thoughts/ideas?

I have an application in development that I need to have a main controlling application and several other dynamically loaded VIs ("slaves"). The main application acts as the master controller for communication and control over processes dealt to the respective dynamic VIs. Therefore, all these need to be parallel processes.

I think this application is perfect for using queues: 1 for the master VI and 1 created by the master for each of the dynamic VIs. I can then pass each dynamic VI the queue references for the master and the one created by the master for the slave VI for bidirection communication between the master and slaves. However, how is the best way to pass the queue references?

If I use a call by reference that allows inputs that can be the queues, the execution is halted for the master VI until the slave finishes. This defeats the parallel operation requirement. If I use the Run VI method and set the Wait for Finish to False, this works but I cannot pass the queue references into the slave VI.

Any thoughts/ideas?

OK...so I can get a list of the bad VIs by recursive searching and looking for the bad VIs in the tree using the Callees property node. I created a subVI to do this and it works real slick.

Unfortunately, the Callees property does not report any VIs that are missing in the subVI...so I can get the bad parent VI, but that is as far as I can go. It is better than I had, so thanks for all the suggestions.

Anyone got any further/other ideas on how to report a missing VI?

I have an compiled application (.exe) that dynamically calls VIs to load into a subpanel. If any of the subVIs in the dynamically called VI are broken or missing (in the distribution), an error is thrown, albeit a general error saying can't load the dynamically called VI. Is there any way to report which of the subVIs are broken? These dynamically called VIs use many subVIs so figuring out which one is broken or missing can be a guessing game.