Aristos Queue

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.]

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?

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.

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.

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

A bit of hacking unites two great technologies... http://spazout.com/roomba/

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.

Darn. Well, there goes that brainstorm. 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.

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.

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.

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.

We have publically visible bug reports all over the ni.com DevZone, so why would it bother us if LAVA has similar lists? Yeah, some of them are embarrassing, but as long as there are threads like this one ("things that have improved") to remind everyone that it's not all bad news then the bug lists do more help than harm.

Unflatten From String and Datalog Read use the same underlying funciton.

Since LV6.1, when the queues/notifiers were refactored to not use CIN nodes but become language primitives.

Since you're talking about changing clusters, you may be facing the problem of having data of your cluster flattened on to string and needing to unflatten it into your new cluster. The conversation in this thread may be useful.

Didn't I put the flat string format into the online help for LV8.2? I'm not going to go check at the moment, but I think so. In the section of one of the manuals where we talk about the flat format of every other LV data type. If I didn't, remind me after New Years so I can post the format on DevZone. Eventually I'd like to post a VI toolkit for examining the mutation records themselves and tweaking them, but that'll be a while. If you have a subcluster of three elements, and you drag one of those elements out of the inner cluster and put it in the outer cluster, the data will move accordingly. If you popup and do a replace on a subelement, the data will be preserved if the types are compatible. Basically, the LVClass is fully cognizant of all the changes that you can do and creates a recipe based on the before-you-start-edit and when-you-Apply-Changes-or-save states of the control editor, noting where every control moved. Be aware that doing "popup and use Replace on the last element" is not the same as a "delete last element and then add a new element". The first preserves data from the original element to the next element (assuming type compatibility). The latter resets the last element to whatever default value you set in the added control. It's pretty intuitive, you just need to be aware of what you're doing. And it's another reason to eventually expose the VIs to get better feedback on the mutation records. There are reported bugs in LV8.2 having to do with typedefs -- if you use a typedef inside the private data cluster, then edit the typedef, this constitutes an edit on the LVClass and bumps the version number. When you unflatten data of the old version, the mutation does not preserve as much data as they ought to be able to do, but I'm not sure yet if those are bugs or just the data being preserved to the same degree it gets preserved in any typedef. It's been CAR'd and I'm evaluating.

If you're logging/reading stable data, I'm going to recommend you use TDMS. That's what it was designed for and it is very very good at it. However, your comment was on data that changes definitions -- you change your cluster and suddenly you can't read old data. I'm not sure if TDMS has any functions for automatically handling such changes to the data stored. But there is one feature in LabVIEW 8.2 that does recognize versions of data and automatically provide the ability to unflatten and mutate old data into the current format -- LabVIEW classes. When you edit a LabVIEW class' cluster, the .lvclass file creates a recipe of how to get from the old cluster to the new cluster based on the edits you make in the control editor. When LV class data is flattened, it writes down the version number of the class as part of the flattened string. So when you unflatten, LV knows which recipe to apply. Unflattening LVClass data is pretty fast if it is already in the current version. I can't really give benchmarks for unflattening old version data since it depends heavily upon what edits were made, but it tries to be as efficient as possible.

Ah, but if you had two VIs causing the break, there wasn't any guarantee that both were at the top of the list. The second would be at whatever point it was in the hierarchy. Static VI Refs, LVClasses and XControls have a blend of dependencies such that there is no tree of dependencies. Instead there's a circular graph. Thus the sorting is needed.

Add a method to your C# that is "ShouldUpdateLaserPowerReading". Have that method take zero parameters and output uInt8 for True or False. Add a second method to your C# that is "UpdateLaserPowerReading". Have that method take one paramter -- the data. Have LV call the first method to determine whether or not the C# wants a copy of the data at this moment. If it returns True, then call the second method. The second method should copy the data into whatever structure C# wants. This solution avoids copying the laser power reading data (which I'm assuming is some sort of larger waveform and not just a simple double value) unless the C# is really asking for it. On the C# side of the code, set the flag that says "Yes, please update the value" and then wait (polling loop or sleep) until that flag gets cleared -- then you know that the value has been updated and the C# code can now proceed.

You're welcome. I get to claim credit for this one, but I have to admit that I only did it because my beloved LVClasses desperately needed it -- when you break one VI in a class, the entire hierarchy is bad, which is a lot of VIs. Finding the root cause was nigh on impossible, so I added the red X and sorted the broken VIs to the top. The fact that it could help with the regular subVI hierarchy use case was a nice side effect.

See if you can blend what you have with this: http://community.ni.com/examples/scrolling-led-xcontrol

You can already drop whatever type you want onto the queue/notifier refnums. Drag any control over the type display (the FPTerminal drawings) of the queue/notifier refnum, and it'll accept the control and update the type display. You can also popup on them and choose "Show Control" to get a more "datalog refnum" sort of view. If you create a queue of a typedef, the queue knows that it is connected to that tyepdef, and so when you update the original typedef, the queue is updated. There's no need for a second typedef of the queue itself.

You never did post the .lvproj file. Might be something wrong in the XML. Might be fixable.

That's the only way to generate them. There's a lot of refnum controls that aren't in the palettes and you only get them by creating them from terminals of nodes.