Aristos Queue

See here.

See here.

Kring has posted a tidal wave of bugs against this VI.

http://forums.lavag.org/index.php?showtopic=5780

http://forums.lavag.org/index.php?showtopic=5807

http://forums.lavag.org/index.php?showtopic=5804

http://forums.lavag.org/index.php?showtopic=5802

I'll ask the original author of the VI to take a long hard look at it and see if the example can be improved. I do own the Notifier primitives, but this particular example was written by someone else -- I asked that it be included in the shipping LV because the functionality gets asked for from time to time.

This was reported to R&D (#45BGR0J1) for further investigation. It will be fixed in the next full release of LV.

Is someone gonna spill the beans?

No, but it seemed like an interesting question to ask. I'm not sure why... call it "basic research" -- something that seems useful to know even if you can't say why at the time the question is asked.

A) Have you posted this to DevZone? You're a lot more likely to get an NI AE to help there than here.

B) What version of LV are you using?

Best feature of LV9: No more constant folding ! More reliable programs without any practical loss of speed and linking VI's in statically becomes more consistent !

Are you being obnoxious on purpose or by accident? Your statement seems like a deliberate flamebait.

[LATER EDIT] Sorry, Joris. My original reply was uncalled-for and has now been edited. But your comment really doesn't make sense. What's the difference between constant folding and any other compiler optimization?

If so, I hope I NEVER hear the term "LVOOP-X"

How about LVXXX for "LabVIEW XObject-XOriented XProgramming"?

(this is pronounced L'vexsssssss, by the way)

I forgot to mention an idea I had and today's post to this thread reminded me...

Everyone talks about keeping the project small. Suppose the challenge was this:

Some LAVA zealot creates a simple app that does XYZ. The challenge is simply to add a feature to the app. Any feature. This way a person can bite off as much or as little as they choose. Competition is judged on best feature added. The general framework already exists, so there's less of the "blank diagram syndrome". Maybe there's a cool bit of UI that another programmer could convert to an XControl. Maybe the program needs a faster core algorithm. The options are wider for what could be worked on and there's less of a "this is the right answer and if you haven't gotten to this point then you aren't done" which tends to make for long hours of programming to hit a specified target.

We could start with any of several items in the Code Repositiory.

This would take us away from algorithmic challenges -- which depend heavily on programming experience and moments of eureka to solve -- and moves us towards expansion of LabVIEW -- which anyone might be able to contribute to from the parts of LV that they happen to know.

I will do so this morning. WB

When you get the bug report number (ask the AE you talk to for the CAR number), please post it here.

Which three VI's would you use the "beans" on?

Ben: please repost your question as a new discussion topic. I think it is worthy of being a top-level post, and it is certainly off topic for this thread. But it's a good question.

I may have seen this somewhere before, but the attached demonstrates a terrible bug. The indicator should update to "Ignore Notification". Remove the outer case structure or enable debugging and the VI suddenly works! I will submit this to NI shortly.

The VI also works correctly if you popup on the 2 that is wired to the Index Array and select "Change to Control".

The bug seems to be something in the constant folding. I'll let JeffK know... did you already file the bug with NI?

When I think "X" anything, I think "Marketing."

I wish XControls behaved more like a control than "fancy transparent subpanels with a single terminal input/output" :thumbdown:

That's what custom probes effectively are. We prototyped the XControls along the same lines -- an enum in to say what to do, a set of values out that were evaluated depending upon what value of the enum was used. Looked a lot like a functional global. Didn't work so well... when it only runs occassionally, as custom probes do when they have data values to update, you lose a lot of the live display potential of the XControl.

I think I understand. Tell me if this is right:

You have, currently, data in PlateMotor.vi that you send to MotCan.vi using a notifier. What you want is to be able to also send data from MotCan.vi to PlateMotor.vi. The data updates on the FP of MotCan.vi (when you write to the indicator's terminal) but you don't know how to get it up to the calling VI without using VI server.

Assuming all of the above is correct, then the answer is straightforward. Have PlateMotor.vi create a second notifier and pass that notifier as a parameter to MotCan.vi. When MotCan writes to the indicator terminal, it should also use Send Notification to update the notifier. In PlateMotor.vi, you already have one loop that is updating the first notifer. Add a second while loop to PlateMotor.vi which does nothing except Wait for Notification from that second notifier and updates its own FP indicator every time a new notification becomes available. When the MotCan.vi is finished running and ready to return a value, use Release Notifier. This will invalidate the notifier refnum, causing the Wait For Notification node to return an error, thus giving you the stop condition for the while loop in PlateMotor.vi.

Does that help?

[And, as other posters have mentioned, if you need to catch every value, then use a queue instead of a notifier in the instructions above.]

Working on a joint application with delbertson, got notifiers working for alot of different user inputed reentrants, is there any 'simple' way to get outputted indicators from each individual reentrant VI. :headbang:

We have AC Motors, Stepper Motors & Sensors all split over multiple reentrant VI's, it would be great to get some feedback onto the Front Panel Main application.

I can get the indicators updating in the actual reentrant VI but not in the Main application, as far as I can see from 'Help' and web site sources this is not possible without initialising VIServer, is this correct :question:

I really don't know what you're asking for here. I think a demo VI would help a lot. Can you post a simple example of the problem?

I am working on updating the DataAct Class Browser so I thought that I would update this as well. This is a modified copy of PJM's code from this Topic.

This version uses a template instead of creating a new VI and objects for every iteration, theoretically it should be faster.

Brian

Download File:post-987-1167763756.zip

A rough transcript of my reactions on seeing this post:

0 seconds (after seeing the post): :thumbup: "Dynamic Generation of Labview 8.2 Class Hierarchy?? SWEET! Someone actually built it! I gotta check this out."

60 seconds: Ok, nice UI... seems limited... but I'll hit the run button. Maybe a config dialog appears...

61 seconds: WHAT THE..?!?!??!

63 seconds: :headbang: NOOOOOOOOOO!

"Dynamic Generation of Labview 8.2 Class Hierarchy" -- I thought you'd built a tool for generating LabVIEW classes. You know, as in XYZ.lvclass.

I'm going to go be depressed now. The adrenaline rush followed by crash is too much.

To prevent this I save the property and close, add it to the XControl, save the XControl, open the property and save the property. This has not solved my issue.

Does anyone know how to do this (Jeffrey?)

A bit of glancing at XControls suggests to me that you may have a problem doing this...

The properties of an XControl are VIs, true, but they are specific kinds of VIs. Adding a VI to the XControl library and adding it as a property are two different things. In fact, I don't think there's any way to add a VI as a property. You can only create new property VIs. A property VI is a special type of VI and I'm not aware of any way to change one type into another.

I think what you'll have to do is create a new property and then copy the block diagram contents from the original VI into the new VI, and then hook up the controls on the front panel.

XControls aren't my area of expertise -- I only play with them because I think they're neat -- so I may be wrong. But that's what it looks like to me.

I decided to go with classes, partly because it was relatively easy, given that I was already using datalogs. Using TDMS would have required me to stop bundling disparate data types into clusters. And I just know I'm gonna love the automatic revision-tracking feature. Thanks Aristos!

You're welcome. Let me know if you have any issues.

A bit of hacking unites two great technologies...

http://spazout.com/roomba/

I'll clarify my question a bit more since your answer is not what I was looking for. If you open up the one and only Xcontrol example which ships with LabVIEW, you will see a custom property called: Fahrenheit Mode? Notice that it does not have any Context Help. How do we add help to this specific property?

I can't help with the nested properties question, but on the Context Help, I think you just set the Description for the VI that implements that property. Whatever is in that description shows up as the help for the XControl's property node.

Dragging the clipboard icon into a static VI reference does nothing - the reference stays with a question mark. Accessing system VI like BObjectCreate1 and BHierarchy seems to be something a little tricky, and I assume that the clipboard VI is in the same league.

Darn. Well, there goes that brainstorm.

Dragging the clipboard icon into a static VI reference does nothing - the reference stays with a question mark.

In any case, even assuming that the internal clipboard implementation hasn't been changed since the days before events were available in LV, is there any way to access internal data to that VI, especially without knowing its internal structure?

The clipboard is just a VI. A VI that never gets saved, true, but just a VI. If we could get a VI reference to it, we could break it down using any of the VI properties/methods. It would take some doing, but I don't think it'd be impossible.

This works fine as long as the user only enters data by typing them. But if the user copy-pasted data that contained illegal characters this might not work.

To make it work, you would have to check the complete string everytime the event fires.

A similar approach would be to monitor key-strokes while the control is in edit-mode, and add an event check when value changed...

/J

Good point. Paste Data should still generate a Value Changed event, but, you're right, at that point you would have to scan the entire string, not just the last character. Hm... I wonder if there's a way to get a VI reference to the Clipboard VI. Brainstorm: The clipboard is visible in the Hierarchy Window whenever you have a subVI copied to the clipboard. I don't have a copy of LV with me right now, but you might try dragging that icon onto a static VI reference -- I have no idea what effect this might have. I know for a fact that LV wasn't built so save references to VIs that are never saved -- there's no path to write down -- so it might work in the dev environment and then crash when you tried to save the VI. Or, heck, there might be an Application property that returns a reference to the Clipboard.

Anyway assuming you can find a way to get a VI reference to the Clipboard VI, you could then intercept the Paste menu event and the Paste Data popup menu event and modify the strings that are about to be pasted on the clipboard VI before allowing the Paste to occur.

This is pretty heavy LV hacking, but it might be a fun backdoor to try to carve.

I think this is the right area,

Anyway, I have a user interface and on it there is a String Control for the user to enter data. This data is used either in a file name or an Access Database Table name, so the illegal characters are fairly close. What is the best approach to not allowing these characters int he String control when the user types them in?

There might be an easy way, but i am stumped..

any thoughts?

Try this...

Popup on the string control and turn on "Update value while typing." This will generate a Value Changed event after every keystroke.

Then have an event structure that watches for value changed on the string. Any time the event fires, check the last character of "new value" of the string. If the character is illegal, then wire "old value" into the string's value property.

There might be other ways involving keyboard events, but I'm not familiar enough with the options.

I am trying to enqueue numeric data into 2D array form. The element data type and each enqueue element is a 1D array of numeric. When I read Elements in Get Queue Status, I see an array of cluster of 1D array! Is there a way to create a queue with elements organized in a 2D numeric array type

Only by building your own when you dequeue. LV does not support a 2D array where each row is a different length. There's no guarantee that the arrays that you have enqueued are all the same length, so there's a cluster level added when you do the Status so that you can have an array of arrays instead of a 2D array.