hooovahh

Yeah that's pretty doable. I'm guessing you saw this already but I made an XNode that takes an array of variant and turns it into a cluster, without using that toolkit. That function is surprisingly inefficent and mine is very simple. https://lavag.org/topic/18520-database-variant-to-data-function/#entry111141 What you'll likely need to do is convert the string into an array of string. Then read in the cluster type that is wired, and then go into a for loop, for each element in the cluster, and for each element in the array of string. You can then deal with data as variants so your output will be a 1D array of variants, in the types you want, then come up with a way of converting that array of variants back into the cluster in a similar way to what I did. Not impossible, but you'll have a lot of playing around until you figure it out. I hope you are good at scripting. Oh and if you do come up with something, the community would appreciate it if you shared it when you are done.

One interesting comment that I wasn't aware of, is that Microsoft gives free copies of Windows to OEMs if it comes with a screen under the size of 9 inches. http://www.theverge.com/2014/4/2/5574146/microsoft-making-windows-free-on-devices-with-screens-under-nine I'm guessing to stay competitive with embedded devices Microsoft might come up with a way to keep the OS free for devices like these. EDIT: So this could be a poor mans myRIO, with HDMI. Very cool.

Not all XNodes are passworded. But I'm guessing all of NI's ones recently are. Here are some from the community that can be picked appart. https://lavag.org/files/category/10-xnodes/ So what defines the data types of the cluster? Will it be another input?

I disagree. The C++ code developed in the Arduino IDE is essentially a single loop operation. When you have full control over a CPU (or Micro) you can get a lot done in a single loop. Sure this isn't the way most Windows based LabVIEW development is done, but that's because we have crazy powerful CPUs with lots of cores to get stuff done with. I'd be content with this toolkit if it only ever supported a single loop.

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?