hooovahh

This should either be reported or posted in the site feedback and support section. In any case I just replied to a post and could attach a VI file. If you (or anyone else) is still having problems feel free to report something, or post in that sub-forum.

I feel like you don't fully understand how event structures should be used. So if your VI starts, it will init VISA with the port selected. At no time after starting the VI will you be able to change the com port. This maybe fine for your test but for a real built application your VI will start running before you can interact with the controls. Then your event structure will wait forever, idle doing nothing, until you change the tab control...is this what you want? Wouldn't it be best if you read the value of the tab and then acted on it? But i think the source of your problem is that you only are writing "oo" once then reading over and over, but your device probably only sends it out once for every request. Attached is an updated version that also has some basic error handling (stop on error and display the error). It also allows for changing of the port and baud rate while running, and supports the normal windows close methods to stop. Tab Event Hooovahh Edit.vi

I'd say it depends on how open the OS is. Can you install drivers for serial devices? Can you install VISA and other NI tools? The specs seem to suggest that it would be capable of running LabVIEW built EXEs, just not very system intensive ones.

Just my opinion, I find SCC much more critical to software development, than OO.

I had tried OSX in VMware years ago and it was slow but usable. I looked into Hackintosh PCs at some point but really it was just a curiosity factor. And having more exposure to other OSs to be familiar with them seemed like a good idea. When Vista came out I was excited to try to learn something new since XP had nothing new to teach after so many years of use.

Not a long shot at all, I've seen this plenty of times and I know others that have too. Here are several links: http://forums.ni.com/t5/LabVIEW/Error-while-building-an-executable-from-vi/td-p/1907753/page/2 http://forums.ni.com/t5/LabVIEW/1502-error-previous-solutions-not-working/m-p/1489838/highlight/true#M561789 http://forums.ni.com/t5/LabVIEW/Build-Errors-1502/m-p/1301220/highlight/true#M536545 http://forums.ni.com/t5/LabVIEW/Error-1502-occurred/m-p/1712466/highlight/true#M604492 Looks like it was a bug that was fixed in 2014. When ever I see it I just close LabVIEW completelly, usually resulting in an error on close, with a soft crash of some kind. Then re opening the project and hitting build before running the VI usually results in a normal build. There was also a VI posted by a user somewhere on the NI forums that replaced a VI in the build process that fixed this. I am not a fan of replacing system VIs so I recommend the restart of LabVIEW.

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.