Aristos Queue

QUOTE(Tomi Maila @ Feb 5 2008, 12:11 PM) My advice? Expect nothing. Prepare for anything. If you want something more helpful, I'm just a developer. :-)

QUOTE(Aristos Queue @ Feb 6 2008, 12:51 PM) Curious. Would someone else please test the following for me... I'd like to make sure the following is repeatable... Open the "Test Main.vi". Run it and get the test time for LVClasses. Mine was around 12 msec. Now edit "LV Test Class.lvclass:Write Boolean.vi" to turn of dynamic dispatching. Run the test again. This time I got 35-40 msec. Save everything. Run the test. Still 35-40 msec. Close the project and reopen. Run the test again. This time I got 5-6 msec, which is the same as the time for clusters. I don't have a clue why the delay is in there if you've edited the conpane of the VI. Very strange. If others can replicate then I'll file the CAR.

If you edit "Write Boolean.vi" and turn off dynamic dispatch on the terminals, you'll get times equivalent to the cluster. :ninja:

QUOTE(Aristos Queue @ Feb 4 2008, 06:19 PM) This has already been reported as CAR 4ELES2FN. The CAR is marked as fixed in the next full release of LabVIEW (not the next bug fix release). The workaround, in the meantime, is, as you discovered, to uncheck that option in the build.

Every event structure that is registered to handle an event must have the chance to handle the event before the next event can be processed. In your case, you have two event structures handling "Close Panel?". BOTH of these event structures must have a chance to execute before any further events will be processed. LV's event queue is simply waiting for the other event structure to have a chance to run. This is true even of filter events. You should never ever ever ever except when you really know what you're doing have two event structures handling the same event in the same block diagram, and you should avoid having two event structures on the same block diagram at all. (The following may be wrong, but I think it is correct. Someone should double check documentation and/or test this...) In the case of filter events, the "discard" output of all handlers are or'd together to decide whether or not the event actually gets filtered. If any single handler returns TRUE then the event will be filtered.

QUOTE(billings11 @ Feb 4 2008, 04:26 PM) No clue. Someone else tried building this and I thought had done so successfully, but they may have just turned that option off anyway for some reason. I'll try to remember to check into this in the next couple days. Thanks for the post.

QUOTE(crelf @ Feb 4 2008, 11:55 AM) Here's the link to info about all of the finalists and why they were chosen as finalists: http://www.edn.com/info/CA6522717.html?industryid=48661 Here's the LV8.5 page specifically: http://www.edn.com/info/CA6523262.html?industryid=48661 And here's the cRio page: http://www.edn.com/info/CA6523259.html?industryid=48661

QUOTE(Yen @ Jan 31 2008, 01:56 PM) Notifiers use the same trick when *sending* the data to the Notifier, but the "Wait for Notification" node is not the same as a "Dequeue" node. Wait for Notification behaves the same as Preview Queue -- which means that a copy of the data is made instead of just moving the data onto your output wire. The reason is that the Notiifer has to retain its value for any other Wait For Notification node that exists on other block diagrams. Summary: No copies when sending to notifier or enqueuing into a queue (assuming you haven't forked the wire going into the Enqueue function in such a way that the *fork* makes a copy) No copies when dequeuing from a queue. Copies when previewing a queue or waiting for a notification.

The "autoprobes" are the small items on the wires when you run execution highlighting. They have nothing to do with custom probes. So playing with that Tools>>Options setting won't have any effect. The custom probes that you've used are remembered in your Labview.ini (or whatever the filename is on Mac and Linux) configuration file. Run LV and use a custom probe then exit LV. Then check the timestamp on your LabVIEW.ini file. Make sure it updated. Maybe your .ini file is read only? Perhaps you are overwriting that file somehow?

a) Are you using LV8.2? 8.2.1 fixed a couple items along these lines. b) In both 8.2 and 8.5: Do you have the VI Hierarchy window open while you're working? If your number of VIs in memory is large, close that window. (It's a known issue and is being addressed.) These are the only issues of this type that have been reported to my team.

QUOTE(Phil Duncan @ Jan 31 2008, 12:06 AM) Grrrrr... that shouldn't have been enabled. My apologies for your wild goose chase. Such functionality is forthcoming, but was not ready for the 8.5 release.

QUOTE(crelf @ Jan 29 2008, 12:31 PM) That I don't know. Until you asked the question, I didn't know you could register to listen for events that happened on another machine (or other app instance). My guess is that the other machine sends events to this machine, and those events merge into the regular event queue and are thereafter subject to the same handling rules. But I severely doubt that the other machine is holding waiting for any "I'm done" message to come back. You should test this.

I don't know much about the callbacks, but it seems plausible to me that when you mess with the operating system, it messes with you. You might try having your stop VI post a new User Event that does the 5 second wait. That way the callback can go ahead and return, but you can still have the delay in your LV app before you do whatever it was you wanted to do next. Of course, that won't help if what you want to do after those 5 seconds is something to Medial Player itself.

QUOTE(PeterB @ Jan 28 2008, 04:43 AM) Essentially, yes. Events are *always* fully handled in the order they occur. So if you have two separate event structures registered for separate events, and both events occur, the first to occur will finish its event case before the next one begins being handled, even if these are separate event structures. This is important in case the event structures are accessing common queues, global storage, hardware or other refnum type. If multiple event structures are handling the same event, then all of them must finish handling the event before the next one begins being handled.

QUOTE(crelf @ Jan 29 2008, 11:07 AM) The correct syntax is simple (as can be shown in this example :-) ).You must include a space between the parens or the mental parser will assume that you're claiming "I have a double chin", and, in addition to being confused about why your double chin is relevant to the discussion, the mental parser will still be bitter about the lack of a closing parentheses. It is an article of emoticon law that emoticons cannot include whitespace as a legal character in their construction, thus the space is sufficient to delimit end of emoticon from closing parentheses. You may also use tab or carriage return, and, in printed material only, it is acceptable to use any printable character with the font color set to be the same as the background color. Or you could restrict your posts to places such as LAVA which support the "rich emoticon iconography set." :ninja:QUOTE(David Boyd @ Jan 29 2008, 10:07 AM) Does anyone else besides me notice things like this? My brain throws syntax errors when I read peoples' posts containing improperly closed parenthetical notes. For the record, an emoticon at the end of a sentence should always have a space between the period and the start of the emoticon, as shown here. ;-) Without the space, I wonder why your emoticon has zits, and I keep scanning, desperately seeking the end of the sentence.

CAR 4C1A37J1 has been split to cover the two separate issues. CAR 4C1A37J1 covers "Bug when dragging .lvclass from project tree to path control". CAR 4DCCLJ00 covers the second issue: This was reported to R&D (CAR 4DCCLJ00) for further investigation. "Bug when dragging non-LV file from project tree onto front panel path control" Both of these issues are tagged as fixed in the next release version (not bug fix version) of LabVIEW.

If the VI you want to reference is a part of the executable and is loaded as part of the executable (by having it used as a subVI somewhere in your code or having a static VI ref to that VI) then you can easily open a reference using Open VI Reference primitive. Instead of wiring a path, just wire a string that is the VI's name (doesn't work for VIs that are inside libraries because you'd have to wire the fully qualified name and I don't think the primitive is updated to accept those (though I might be wrong; someone could've fixed that in 8.2 or 8.5 and I might not have heard about it)).

QUOTE(tcplomp @ Jan 26 2008, 02:26 AM) I'm a bit surprised to see any discussion of "multiple event structures on the same diagram." Why am I a bit surprised to see this? Well... Anyone using the Event Structure should at some point search the LabVIEW Online Help for this topic: Caveats and Recommendations when Using Events in LabVIEW This page has some important advice, among them: Avoid placing two Event structures in one loop. You can find the topic and read details about why. Just something I thought should be part of this thread...

Make the functional global itself be a template VI. Then drop the *template* on the block diagram of your other template. The subVI node will be decorated with a large black capital T, indicating that when the top level template is instantiated, this subVI will also be independently instantiated. Now you'll have a separate functional global instance for each of your top level template instances.

QUOTE(Aitor Solar @ Jan 19 2008, 01:44 PM) Apologies. I should've put a on that. No one but the most lawyeristic among us reads shrinkwrap licenses, even though we all probably should so we'd know what we could and could not do with our softare. It's something I've complained about more than once on LAVA, the complexity of knowing what rights we have with VIs or any other IP generated from any piece of software.

QUOTE(Aitor Solar @ Jan 18 2008, 02:12 AM) I don't know the answer to that question but you should ... don't you read your shrinkwrap license agreements?

QUOTE(ibbuntu @ Jan 18 2008, 04:29 AM) Because we don't know which subVI will be invoked at the dynamic dispatch call. There's no guarantee that every subVI in the method preserves runtime type across its diagram, and even if every subVI in the method happens to do so, there's nothing that says you won't dynamically load a class into memory that adds a new override of the method that doesn't preserve runtime type. Because dynamic input must be wired to dynamic output, we can guarantee the type is preserved at runtime for those terminals. We've talked about adding arbitrary terminal mappings to dynamic dispatch VIs -- you'd configure output terminals to be tied to particular input terminals and then your diagram would be broken if it didn't actually fulfill that contract. The problem is that the UI configuration for such a system turns out to be pretty difficult and it's a fairly rare use case as compared to a lot of other features that are being demanded from my team.

You have an event structure that is registered to handle the value change of the OK button. Any time that button changes values, you must give the event structure a chance to run. Until the event structure gets a chance to handle the event, no further UI events can be processed. The way you have your code set up, when the Start button changes to True and then you hit No in the dialog, the event structure never gets a chance to execute. Here's a revised version of your VI: Download File:post-5877-1200633606.vi It is not completely what you want -- the inner loop won't stop if you click the small stop button.

QUOTE(ibbuntu @ Jan 17 2008, 12:08 PM) The grey background only shows up when you have dynamic outputs... if you only have dynamic inputs, there's no reason for you to have to know where the dynamic input is running to. That's a UI decision I've thought about changing a few times, but generally it doesn't seem to bother anyone, and I kind of like the knowledge that I don't have any dynamic outputs because the grey background is gone. And now, let's talk about your problem: The grey background can be followed all the way to the "handle.vi" subVI call. That call is, I assume, dynamically dispatching on the top input (the message object). In a dynamic dispatch subVI call, the only terminals that can preserve runtime type are the dynamic dispatch outputs. All the other terminals cannot be guaranteed to preserve runtime type. Therefore the grey background is not preserved on those outputs. Is the Network Controler object actually modified inside "handle.vi"? If it is NOT modified, then you really don't care about the output, and you could just fork the wire that is the input into handle.vi and wire it to handle.vi and directly to the output FPTerminal. Like this: However, if you do modify the value, then you have no choice but to make the output FPTerminal not be dynamic dispatch output. There's no way to preserve the runtime type safety across the subVI call.

QUOTE(crelf @ Jan 17 2008, 07:40 AM) Nope.