TG

QUOTE(TG @ Oct 14 2007, 08:38 PM) Bumping.. Thx

Ok forgive me as sometimes a nerve gets pinched. I wrote this long winded thesis on why I am unhappy with NI's QC today then I realized things are best left unsaid.

QUOTE(Jim Kring @ Oct 17 2007, 09:54 PM) I wonder how my eventual transition to 8.5 will be. I have a fairly large "in house" project going in 8.2.1 and don't really have it fully sorted out yet in terms of Vi locations, etc. I took a stab at loading it into LV85 and saw a lot of dialogs but did not have time to drill into it so I just closed it out for now. Wondering if there is going to be an 8.5.1 patch coming..

QUOTE(Michael_Aivaliotis @ Oct 13 2007, 11:31 PM) Im not a pure lurker but since I have developed the worst LabVIEW habits over many years (since version 1.0 on the Macintosh) I can tell you I am definately out of my element here and struggling with the right way to do things, not being a software engineer by study and having never made more than one or two executables for remote use I find this forum scary, entertaining, humiliating and mostly educational. You guys are the geek squad *10 :worship:

QUOTE(Aristos Queue @ Oct 15 2007, 05:01 PM) Me too. The worst thing about getting sick is that it is usually at the worst possible time, like immediately after a long vacation or on the day of the big review meeting withthe Big big Boss etc.. Here is to some Hot soup, whatever knocks it outta ya. :beer:

QUOTE(Aristos Queue @ Oct 14 2007, 07:19 PM) I'd give anything to see a (reasonably) simple example of this. PS: This is not a challenge

QUOTE(Aristos Queue @ Aug 1 2007, 03:00 PM) QUOTE(TG @ Oct 14 2007, 10:25 PM) I'm totally confused now but quite entertained Please riddle me Opps I guess I better keep reading first ... QUOTE QUOTE(Aristos Queue @ Aug 2 2007, 01:00 AM) At the risk of confusing everyone, I do have many functional globals that are reentrant. That's how I can create separate databases -- the core VI is reentrant and contains the uninitalized shift registers. QUOTE QUOTE crelf Posted Aug 1 2007, 07:19 PM Right - that's a neat implimentation of an object repository functional global, not a single-layer functional global, which is what I think the original thread (and PaulG.'s post was getting at). Just to let you guys know this is good stuff from where Im sitting.. I'm gonna use that technique for myself. These little tricks are quite impressive. I guess it would be great to somehow catagorize all this stuff in Wiki but how? Thanks anyway Kudos LAVA!

QUOTE(TG @ Oct 12 2007, 03:19 AM) I cant believe I was able to fix this ! It seems to be stable too, hallaluahh! Share in my happiness and if you are really good explain me what I did to fix since I have no clear idea PS: Sorry its in 8.2.1 I do not know if it would work with 8.0 since it uses clones. It definately does not in 7.1

Hi guys, Concerning an excellent events messaging example from Mike awhile ago. Here is a modified version renamed Download File:post-2402-1192158504.llb I fiddled with Mikes original example to launch vi:(clones) from the main VI. This works fine. Anytime a clone is launched from Main the clone can communicate back to change the station ID or the command in Main. No sweat there. Now if Main wants to kill all the clones after creating them it appears as if it is able to do so. (Pressing Kill Clones button) However, If Main creates a second set of clones the Kill event is lost on them (even though they can still fire events back as before.) Another clue is that if two clones are created and Dynamic_VI.vi:1 (clone) is closed by the user (while Main is running) but vi:2 (clone) is kept open the kill event from Main is also lost as in Main cannot close vi:2 (clone) I gotta admit some of this event stuff really breaks my head. How could this example be modified so that Main can kill any clones it creates at any time? Is it (hopefully) a simple matter?

QUOTE(Tomi Maila @ Sep 30 2007, 10:03 PM) Excellent advice. Really appreciated.

QUOTE(Tomi Maila @ Sep 30 2007, 06:52 AM) Thats encouraging! QUOTE(Tomi Maila @ Sep 30 2007, 06:52 AM) With events you must register the events so that you have a unique event registration refnum for each event structure. Event registration refnum is like a mailbox that you cannot share with your pal. I think I understand. Let me ask this quick Q : True or false? [ When launching multiple re-entrant *instances* (lets call em Slaves) it is possible to use event registration for signaling a single *instance* in the group as long as the registration refnum sent (from the Master) to each *instance* is unique. ] QUOTE(Tomi Maila @ Sep 30 2007, 06:52 AM) Queues can be used instead of notifiers as well although the logics of queues is a little different. Queues can be easily used for asynchronous messaging, especially for one-to-one messaging. To send a message, enqueue the message to the queue. To catch the message, preview or dequeue it. When the queue is empty i.e. it contains no message the dequeue operation waits until timeout. The things become more complicated when you need to send a message to multiple receivers. You can then create a queue for each receiver separately and enqueue the message to all these queues. You can also create a proxy VI that takes care of multiplying the initial message so that each receiver gets one. Tomi That is the best help answer for my plight. Thanks Tomi! Your answers are always the best ones. PS: My bad for taking a chance with notifiers again. They seem to work so well at first.. and then.. missed notifications out of nowhere - no easy way to track down the cause... I always think it is somehow my own mistake. Now I know better. Your original example is a valid and reasonable use case and it simply does not work reliably with re-entrant vi's . I won't use them anymore for fancy stuff. I don't care what the experts say. TG

Thanks Tomi I'm using 8.2.1 Let me look this link over. I appreciate the quick response. Edit1: So far I only looked at your excellent first example and in 8.21 It has problems if you make more than 5 or 6 iterations. This seems to be almost if not exactly what I am experiencing. Your response has value to me thanks. At the very least least it seems to illustrate a real problem with these creatures since your usage seems to be quite reasonable. Edit2: Oh boy, As I read further and see where the discussion is heading I am appalled at the complexity of this issue. This is going to take a month of Sundays to figure out what you guys are talking about in that thread.

Hi guys, Im trying to get to the bottom of this notifier mystery I am encountering to learn the tricks of the trade with them and (also) event structures which I view as being earily similar to notifiers. Ive made an investment in using them for a messaging mechanism in my project It involves re-entrant clone VIs launched with Vi server invoke nodes. It is not too easy to make an example. A few Questions come to mind, most of them may be not specific enough because Im not really super keen on notifiers yet. How they relate to re-entrant vis launched with Vi server is new to me so here goes.. Is it a sensible 'use case' to send messages with notifiers using a one way downstream channel 'cmd' and then using another notifier for the upstream channel 'ack' for replies. WHen creating a notifier reference and carting it around various VIs does the notifier reference sometimes go invalid? What would be the condition for that happening (if any)? If the VI that initialized the notifier (originally) was not idlie but sitting in an event structure timing out in a polling loop and a notifier reference was 'obtained by name' in another re-entrant vi for messaging could the Notifier reference (on a wire) in the original vi possible go idle? Is there any condition that could kill that notifier on the wire in the original Vi? Can notifiers and event polling run in parallel ok? Example In a section of code A notifier 'A' awaits a message while a lower loop polls in parallel. The lower loop will (before exiting) send a nofification to "A" letting it continue. Notifier "A" can recieve a message from the lower loop or from an external section of code (another re-entrant Vi ) WHen notifier "A" triggers (gets msg) it enables code to shut down the lower loop should it still be executing (then other things) Is it ok to do this when both vis are re-entrant? (I'll try to make an example if it is not clear.) I've noticed notifiers and event structures can sometimes give unpredictabe results even when the rules of use are (apparently) being followed. For example, when connecting to a notifier input terminal on a subVI (a typedef'd notifier ref) in some cases there is a coercion. I can create a typedef constant from the vi terminal then convert it to a control then conect it to the (same) terminal and a coersion dot appears. I cannot explain this. Another way to explain strange behavior is a usage where two re-entrant Vis are messaging in a master slave setup where Vi 'A' is sending cmds and the vi 'B' is setup to acknowledge the commands. vi 'A' sends a notification on 'msg' channel to vi 'B' vi 'B' replies with its own notification on 'ack' channel back to vi "A". Each Vi obtains the proper notification "by name" 'msg' and 'ack' before then exchange messages. Normally one would expect this to work flawlessly, however sometimes it doesn't and it drives me nuts why it isn't more stable. (no significant change in code just stops working for unknown reasons) it is almosyt as if LabVIEW is losing track of things which i know is not the case because it is far more likely to be me! I wish I could be more specific but it is troubling me that I cannot even pin down what is happening. :headbang: How often must LabVIEW be restarted when developing and testing notification messaging with re-entrant vi's. During development is it possible that one or two (non graceful) aborts could trigger such odd behaviour with notifiers especially? I do not see unstable behavior with queues, semaphores or any of the other functions and I assume we all hit the abort button during development phase of untested code. I only see weird behavior with notifiers and event structures. Anyway I was running into strange timeouts that i dont understand today and would appreciate any second opinions. Thank You

QUOTE(NormKirchner @ Aug 22 2007, 03:12 PM) Eugen Thats a nice simple example thx for posting it. Hi Norm I am just trying to get the mechanism for (hardware or visa) events ironed out a little more. Could I ask you for a little more detail about what is happening in the example (pic) you posted using the event registration example? PS: I guess serial interrupts would be supported in the same way or no? Could this technique be used to catch incoming characters without constant polling of a serial device? Thank You

QUOTE(Eugen Graf @ Sep 13 2007, 07:10 PM) I feel your pain Eugen. No one here (where I work) really appreciates the skill it takes to use LabVIEW effectively.

QUOTE(ooth @ Sep 14 2007, 03:54 PM) I guess the main thing is to close it before your APP exits. Where it is done is up to you and depends on how you are using the resource. Closing a ref releases resources(memory) so if memory usage is critical to your app then close it as soon as it is not needed. I would not assume LabVIEW handles the closing for you although it does in some instances such as when the VI that opened the reference goes idle.

QUOTE(Michael_Aivaliotis @ Sep 8 2007, 03:14 AM) Great work Mike. I can wait for the "View New Posts" to come back, No worries

QUOTE(Tomi Maila @ Sep 10 2007, 03:11 PM) Im also missing the view new posts feature Feel kind of lost without it.

QUOTE(Tomi Maila @ Sep 4 2007, 10:25 AM) I agree with you Tomi. I wouldnt agree to this being a feature, quite the contrary, since a thing like this can waste much time when trying to figure out "what the heck just happened!"

Here is one I just recently designed for myself and am using a lot. It's an extremely powerful yet relatively simple state machine design. I'll put it into the code repository someday. http://forums.lavag.org/index.php?act=attach&type=post&id=6897 LV Version 8.2.1 It is based on techniques described in the reference below. It has a lot of useful features. 1) It uses an elegant technique for dealing with automated systems, where all attempts must be made to continue execution (if possible) before shutting down an application. 2) It is a LIFO (Last In First Out) Queued type state machine. Instead of an array of enumerated types or a Queue the machine uses a multi line string of text states. the new line char "\n" separates states. This really helps with read-ability, and portability at the possible expense of execution speed and more attention to mispellings, etc. However, most state machines do not need light speed execution over read-ability so this is in my opinion not a real problem for a queue size of 50 states or less. With this framework it is possible to handle errors within the VI or escalate the error upwards to the caller. The framework provides an elegant mechanism to check if the error was handled correctly. If the error is corrected the SM will retry the offending state and continue execution normally (without ever telling you In automation this means an error can be logged and handled privately to the SM while continuing execution of critical tasks. ref:LabVIEW Advanced Programming Techniques Second Edition by Rick Bitter, Taqi Mohiuddin and Matt Nawrocki

QUOTE(Mindstormer @ Aug 31 2007, 09:06 AM) I too am unqualified to chime in but your problem got me thinking. Is the server launchin the re-entrant Vi's? Reason I ask is there may be a way to get at the name of the instance if it is set up as a clone. Maybe that could be used to get at the status of the button. (With Vi server)

QUOTE(Michael_Aivaliotis @ Aug 25 2007, 09:02 PM) Very enjoyable Reminds me of those "good old days" when the Soviets were the enemy and LabVIEW was bigger on the Macintosh than on the PC.

QUOTE(Aristos Queue @ Aug 22 2007, 11:16 PM) Im sorry to say I tried going head first into LVOOP (while training in OOP ) at its release 8.2 stage which was (in hindsight) bad combination luck timing whatever.. I spent good part of 3 months trying to sort it out (at my own risk) and concluded finally that I could only use LVOOP for protecting data in an elegant way. That is currently all the functionality I can manage (with any trust) and probably all I will attempt for the time being. I do have one data structure I am very proud of designing. I wanted to do much more with that one but it is done now. I am back to using Evdevo by ref objects and building many functioning classes in that toolkit. Main reason for switching. 1) It was stable as a rock and 2) all the crashing class breaking and VI breaking episodes ceased and 3)My work (value) began to increase linearly. 4) It can be converted to executable with no worries. Like a lot of us here I cannot do much experimenting in LabVIEW. That is why this forum is so valuable to me. Nevertheless I really do think native Classes are the way to go in LV. I too look forward to using LVCLasses when they are ready.

QUOTE(Gary Rubin @ Aug 20 2007, 06:40 PM) I think the right side of my brain might be dead or at the very least incapable.

QUOTE(Harish @ Aug 20 2007, 06:27 AM) You found good forum Look at GOOP subforum for object oriented discussions. Many interesting topics and good examples for learning.