hooovahh

A week ago I saw LAVA was down and contacted Michael, he worked his magic and things for me have been fine ever since. Still I have contacted him again and made him aware of this thread.

First off I think you might get limited responses from people on this, but I might be wrong. Many people who work with LabVIEW daily and are on these forums, know that this is a public place, and anything they say may come back to their employer. That being said I don't mind commenting I have nothing to hide but others may not be so open. In my mind, increased salary and other monetary benefits help you feel satisfied only until a certain point. After an employee is paid enough to not have to worry about money, they can get a decent savings, and pay off debt, and beyond that an increase in pay is nice but I think factors less into satisfaction. For me satisfaction has to do with accomplishing things. I was given a task that I could then do. Maybe it is a task I have had before but now I do it faster or better. Or maybe it is a new challenge and I was able to get it done for the first time. But after I've completed my task, some recognition is nice. I'm not saying I need a pat on the back after every work day, but having those around me appreciate my work, and understand my value, brings satisfaction. Especially when it comes from those I work with often, and those above me, like a boss. I could also mention other things that I like about a job that don't really add to satisfaction, but could detract from it if it were missing. Like having an open an inviting team that helps each other grow is important. Having that doesn't make me feel more satisfied, but not having that could take away from my satisfaction. It sounds like an interesting book and FYI it is $17 on kindle.

So I did a quick test out of curiosity. I created two projects, in the same version of LabVIEW. So this should be two different application instances. In one project I got a reference to a boolean control, then used type cast get the array of bytes that the reference represents. In the other project I typed in the array of bytes then used type cast to convert the data back to reference. Then I registered for the reference on a value change. To my surprise I could actually register for the control, and it worked as expected. I tried the same thing on two different versions of LabVIEW, but that didn't work. It stated the reference was invalid. Not sure if this helps clear up, or muddy the definition of local objects or not.

I don't speak for the original developers, but I thank you. It sounds like the changes you made were for the better, and after the server crash years ago, having a new version uploaded in the original thread will help others who stumble here looking for a good TIFF reader.

I'd be really interested in your opinions on this. I'd encourage you to make a blog post, or post on LAVA.

Okay so my actors are not using AF and they aren't reentrant (so there is a bunch less issues I don't have to worry about). But I also found some times my front panel would be open when inserting it into a subpanel which would cause errors. So in the code that inserts the actor, it will perform a front panel close, then clear the error if it was never opened. Then I know the front panel isn't open so it is free to insert it into a subpanel. I'm pretty sure the close front panel from VI Server doesn't close the block diagram if it is open. So your debug probes and break points should be left untouched.

Okay how about this. Some kind of helper VI that runs in parallel, that monitors the value of the controls, by reference. If the value does not equal what it did before, it sets the Value Sig property node, which should generate the event like always. You'll need some way to kill this VI running in parallel of course on shutdown. And there is a bug that when the control value is changed like normal, the event will be generated twice. You can look at the time to filter out a duplicate event. Attached is a quick example of what I am describing. Event Work Around.zip

Wow that has to be a real bug. I tested it with classic, silver, system, and modern DAQmx Terminal controls, and they all don't fire the value change event, if it is changed using the browse dialog. I also tested this in 2013 with the same result. As for work arounds... You could write your own XControl that looks and behaves like the selection control. This would be a pretty big pain and would probably involve re-creating the browse dialog... Or you could poll the control value periodically, looking to see if the value is not what it was previously... Honestly those are the only two ideas I have. Others come to mind but none I'm sure you could actually do other than those. Contact NI and have a CAR filed.

Does anyone know where the browse property dialog is on disk? If you drop down a property node, the first item in the list is "Browse..." and clicking this will open a new dialog where properties are shown in a tree which can be selected. There is also a search feature, and a sort alphabetically. I can re-create this dialog but if it exists I'd like to just leverage as much of it as I can. I searched for "Property" under the resources folder and didn't find it. I also tried to abort all VIs in all context, when it was open hoping that would abort the dialog so I can find out where it is but that also failed. Any ideas?

That's a very good point. Variants are the first real example of a loosely coupled data type, in LabVIEW, a strictly typed language. I mean sure you can express any data type as an array of bytes, and therefor a string. But still Variants are an interesting thing that I'm guessing had some internal debate at NI on if and how they should be implemented.

I wasn't trying to say all OpenG functions are slow. You should perform your own testing to determine if they work fast enough for you. In any case I started making two XNodes to go from 1D to MultiD array and back but I realized it was much easier to just make a VI that works well enough. Attached is a VI that goes from MultiD to 1D and back in a way that I think is pretty efficient. The only thing I'd try to improve is a better way of knowing an array size of the array. Also this method only supports up to a 5 dimension array. Feel free to add more, but a better solution would be to do it programatically with an XNode. Array Dimension Converter.vi

Yup I sure do. The attached VI should allow you to make a new Scale, Virtual Channel, or Task, or edit an existing Scale, Virtual Channel, or Task. I found this stuff while digging around in the DAQ Assistant common files under Program Files\National Instruments\MAX\Assistant. Add - Edit Scale - Task-Channel DAQ Assistant .vi

The Reshape Array can do that, but you'll likely need some extra math to determine the size of each dimension. But what is wrong with the OpenG solution?

It is generally best to have only one event structure in a VI. It isn't required by any means but having multiple event structures can make understanding the code more difficult, and can make bugs if certain behavior isn't avoided. Once you code is posted it should be no problem describing the best approach.

Wow this is a fantastic demo. I can't wait to see more when it is released. I have several Unos, a Mega 2560, and a couple Teensy 3.1 which is an arduino compatible ARM based micro with lots more functionality. While your site doesn't mention Teensys it will probably be one of the things I try once it is released. EDIT: Also what is there a pricing scheme planned for this toolkit?

I know these existed in 7.x, not sure about 6.x or 5.x which is when most of the OpenG stuff was made. Still it is possible it existed, but because it was a relatively new function, maybe the OpenG community didn't know of its full potential.

I'm using non OO based actors and I don't know the issue you are talking about. Are you you talking about when one actor will keep the application from closing? A global shutdown command that is a high priority user event takes care of that for me. One major reason I dislike the official Actor Framework is the reentrant-ness which forces you to other debugging techniques (setting break points in the VI saving, waiting for a clone to be made and stop, then being unable to remove that breakpoint while running) I thought about just Glue but it has taken on a life of its own now, and there's no changing it.

I almost didn't want to say because I was worried it would be stolen before it could be released. Still the likelihood of me being able to release it is small. Still I trademark it "Glued Framework", (Global User Event Driven) It is a user event driven framework, which is publisher subscriber based, where each actor subscribes to the user events that it needs. The publishing of the user events are in a write once read many (WORM) style global.

That was a fun little XNode and didn't take much time at all. More people should know about the neat features of Variant to Data when it comes to arrays and clusters.

I haven't seen this error but I have seen "Not enough memory to complete this operation". This error happened on a corrupted VI. I kept deleting things until the only thing open was this single VI with a blank block diagram but I still got the error. After playing around with it enough the error went away and I was able to compile. Copying the contents of the VI to a new one fixed it as well. Not sure if these are related.

What's in a name? Turns out alot. I have an Messenging like framework (it was made before Messenging was released), and it took me a long time to come up with a good name. I do think Messenging isn't a good fit, for a few reasons, but it does reflect what the software does which is better than some names. I'd say it should be changed, but I have no suggestions.

Are you referring to the Index Array under the VArray palette? I'd recommend using a Variant to Data converting the variant, into an array of variants, then you can use the native array functions to index the values out of the array.

QuickDrop is stored in the LabVIEW.INI but I tend to just blow these away periodically because I'll be developing plugins that then get in a limbo state. If these keys are in the INI it just reads the VI Description of the plugin VIs and sets their shortcut to what is in the description. Also as for synchronizing settings glyphs etc. We have large reuse library, and one package is for glyphs, and another is for "Templates" which has morphed into containing other settings too. During the package install it has a Post-Install VI that sets INI settings to how they should be. It also installs a few quick drop commands, and sets up the shortcuts for right handed developers. Generally we install the reuse library on a fresh machine from a base version, which includes all these packages.

Very neat, I think I may have met you guys at NI Week. Does this require or use the NI C code generator toolkit?

I had a white board that I would write bullet points on before leaving work. Even 18 hours later these would some times not make sense, but most of the time it was just enough of a reminder to jog my memory.