Aristos Queue

They probaly don't like that we are able to see all bugs on a forum in the internet

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.

I opened up the Read Write Class Data To File.lvproj Example and did some experimenting. It appears to work well. I assume the magic is in the datalog read function.

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

I just checked and it is possible since at least version 7.1.

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.

Is there any way to inspect the object version the flattened data (either on disk or after reading it into memory)? This would be nice, since it would allow us to implement our own upgrade logic, on top of what LabVIEW gives us for free.

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.

Also, how does this feature handle modifications to type definition elements of the object data? For example, if my object data contains a sub-cluster which is also a type definition. Editing the cluster will effectively edit the object data.

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.

Actually, this feature was always there even in older LV versions. The lowest VI in the hierarchy causing the break went to the top of the list. NI broke it in 8.0 and then fixed it in 8.2. I think they added listbox icons in 8.2 as well.

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.

...until my client, after observing the system in action, said, "That's great. Could you add one more feature, namely, every so often the C# should log the value of the laser power meter?" The problem I'm facing is the laser power reading is being acquired by the 'parent' LV program, inside a while loop, so it's continuously available, but I don't know how to 'ask' LV for the value from my C# DLL. Could the forum suggest a mechanism to accomplish this?

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.

I like it!

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.

Nifty tool for static messages. I suppose you could create several of these and dynamically load them. What would really be great is if you could script this (the creation) using .NET automation nodes from LabVIEW.

Still, if you are willing to go to that much work, I wonder if you could do the same thing with Picture Control tools.

See if you can blend what you have with this:

http://community.ni.com/examples/scrolling-led-xcontrol

What would be nice to have is if NI gave us 'empty' refnum controls for queues, notifiers, etc. in which we then could drop whatever control we want to be the datatype (analogous to what now is possible with the datalog refnum) for that specific object.

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.

This would certainly make life easier since now I have to keep two seperate typedefs (one for the data type and one for the refnum type) for every queue or user event I use in my apps. I'd like to see these two connected somehow.

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.

Well, for now I am going to try to re-install when I get time...I have been pretty busy today! I'll let you guys know if it fixes the problem. Thanks for the help!

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

I usually create notifier controls or indicators by right-clicking on the "Notifier" terminal of any notifier function and choosing "Create -> Control". I then copy and paste the control wherever it's needed.

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.

Are you passing warning meesages? If not you could just use the error code case, and an error code of 0 is no error.

Actually, GPIB uses error code zero, so be careful with that idea.

Error 0: Error connecting to driver or device.

I have no idea what conditions make this error code be returned, but there you have it.

One of those legacy things from years ago.

I didn't quite grasp the reasoning for LabVIEW Value Class.

Why can't the LabVIEW Reference Class inherit from the existing LabVIEW Object?

Is everything pretty much the same (as far as functions) or have things changed enough that I'll have to rework sections of my VIs? All my work has been in 6.1 (have been using 6.1 about 4 years now) and this 'instant upgrade' was so unexpected that I haven't even had a chance to demo 8.2 (8.2 will be totally new to me) - am I in for as big a job as I fear I'll have?

The autotool works much better in 8.2. That nervous twitch in your mouse hand that you've developed over the last 4 years to hit *exactly* the right spot to get the right tool may now be a liability instead of an asset.

Kidding aside, I don't think you should have much problem moving your VIs forward. Your biggest barrier will probably be what most folks have complained about -- the palettes got a serious reorg in 8.0.

First option might be applicable, especially if the subVI would be put inside disable structure so that it doesn't affect runtime performance. Second alternative is not an option due to many reasons.

A code disable structure would not achieve the effect -- if it isn't compiled into the code then when the subVI is missing the VI isn't broken. You could put the subVI into a case structure that is wired with a control (not a constant!) whose value is FALSE. Then it would be compiled in but never executed.

But as Kring points out, all they'd have to do is load a VI to fill in the missing subVI.

I'm not sure why this is a problem... in previous versions of LV, you could load the VIs even if they were inside the EXE using various magic tricks. It's only recently that you couldn't -- and more people have complained about not being able to access the VIs inside the EXE than have complained about not being able to access them.

Now, there is a game that I can play on the C side of the code that I've used a couple of times for hiding VIs... I have the equivalent of a string control whose value is the save image of the VI and then I load the VI from the string instead of loading from disk. Thus there is no VI anywhere on disk that is the VI that I'm loading. I have no idea if any such mechanism exists on the G side of the code. Has anyone ever done something like this? And, now that I think about it, Express VIs generate VIs that are saved inside the caller VI. I wonder if there'd be a way to hide other VIs in there with a custom built Express VI? I've never used the Block Builder Toolkit, so I don't know if this is doable or not.

All of these suggestions are a bit of a longshot, and probably not easy even if they would work. Sorry, Jimi, but with AppBuilder I'm pretty much in the dark. It isn't an area of LV that I've paid attention to much, though it appears that with LVClasses I'm going to have to go learn about it more than I had expected. :ninja:

2. Variation on above: have each of your dynamic VIs look to see who called them and if it is not your *.exe, ie and authorized app, then either don't work (recommended) or send back incorrect data or behavior. (not recommended due to debug and liability issues).

What if you just created an LVLibrary that owned your entire application and made all the VIs private to the LVLibrary? Then even if others managed to load them they couldn't run/call them.

I Think you can also use the Global Variable to solve you problem!

Or, you can not use a Global Variable and thereby not pick up an extremely nasty habit. Global Variables are easy to write and painful to debug, especially if anything starts happening in parallel. Stretching just a bit for a slightly harder solution (functional globals, events, queues) will help you a lot when it is time to debug the problem.

Why not I have the property node?

Thanks for your help me!

Because you don't have scripting. The VI can only be edited on an installation with scripting. The VI can be executed on any LV.

If you want a fairly quick read that really makes you think about such things, try Einstein's Dreams. :thumbup:

Good book. I have it on my shelf.

Another in similar vein, is Timelike Diplomacy. A marvelous book about a hardware engineer who created a temporal feedback loop in a D-flipflop and a moment later a monolith appeared bearing the inscription "Thou shall not violate causality within my historic light cone. Or else." That initial feedback had formed an AI that propagated itself back in time. Quite a fun novel, with the premise that causality is not absolute, merely a good idea (particularly when there's a near omnicient AI enforcing it).

Only complaint is it' a (huge!) hard cover animal.

Perhaps it should be retitled "LabVIEW for Everyone-With-Arm-Strength"

But perhaps we shouldn't give it a hard time ... I look at my desk and notice that Kring's book is almost exactly the same size as my "The Complete Reference: C++ Third Edition", and Kring's text is WAY more comprehensive and comprehensible than the C++ text.

If these universes are truly parallel, then by definition they are NOT connected...

Parallel lines don't connect, but lines ("wormholes") perpendicular to them provide the links.

I have this vision of a very plaid universe.

In all seriousness, though, did anyone catch Jeff K's presentation at NI Week 2006 about his proposed asynchronous wire (aka "Jeff's Wire") and the transtemporal three-dimensional stack of block diagrams that would accompany it? That's a vision of LV that will really mess with your head for a bit.

Damn, who here doesn't work indirectly or directly with crelf... besides me?

Well, he's not my boss, but he is a customer of mine. That's sorta like a boss with some layers of indirection. I think you'd use a dotted line on a formal organization chart.

Would definitely seriously consider it if it wasn't so derned cold up there. I don't think I could convince my wife to move to MI. We've lived in upstate PA, but since she's been spoiled by southern Cali and Virginia weather.

Plus, your link says your positions are filled and I'm not quite sure if I have what one might consider a "superstar resum

When I showed the new site to my boss he clicked on the terms of use and it still looks like there is legal verbage included for the new site that fails to maintain our IP.

Could you please fix that?

In a bit of role reversal, when I joined LAVA, I was advised by several folks not to post anything more than small demo VIs to LAVA because of language that didn't clearly maintain NI's intellectual property. MichaelA and I had a bit of a talk about it, and finally decided to avoid any question by posting anything that might have IP value on my personal website and link to it from here. I don't think that any group is happy with anyone else's legal verbage, and everyone is terrified of being sued or having their code claimed by someone else, etc. etc. etc. So if you're bothered by the IP language over on ni.com, you might try my trick... post the VIs themselves to a site whose IP language you trust and then post to ni.com with only links to the VIs instead of the VIs themselves. Seems to me like a way to leave the lawyers out of it and let us all get back to code development.

Fixed, no polling no more, still the same event based architecture.

Interesting, I thought notifiers and event cases internally use polling to "check for mail" but they're based on something else then, most probably CPU interrupts.

I can see that events are hard to use if you are not familiar with handling dynamic events. So I fixed my example by adding some documentation into it so that it can function as an example of general manager design. Here it goes, only for LV 8.0 and later as LV 7.1.1 cannot handle multiple event cases very well.

Well done.