Greg Hupp

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.

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?

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?

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!!

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) 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) 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) 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 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) 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) 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?