hooovahh

Yeah the XNode version works with any data type. It can read and write references, and ROI's which I think are clusters. The non XNode version would need to have those types added to the polymorphic VI types.

So sorry it took this long to realize you were talking about at run-time, my bad. Here is an idea exchange for that. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/LabVIEW-Spell-Check-For-String-Control-in-Run-Time/idi-p/1661466 And no, I can't think of any other solution. Is there some kind of external spell check library that can be called? Still sounds like a pain.

I know of no other spell checker like functionality in LabVIEW. There are several ideas on the idea exchange for this, none seem to have much traction but this is the highest one I see. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Spell-Check/idi-p/982762 That being said I doubt NI would work on making a spell checker in LabVIEW, since VIA does works for finding spelling errors in source, which I believe is the most common use case.

I understand your version situation, but the VI Analyzer is now free with LabVIEW Professional 2014 or newer.

We still haven't seen any code, we still haven't seen any example Excel files.

Yes sorta, but you shouldn't need to. Is there some function that only LIFA has that LINX doesn't? LINX is the newer version and I'm sure they are trying to have the same function parity between the two toolkits. That being said one restriction you may find is that you can only use one toolkit on one Arduino at a time. Each toolkit has its own firmware that gets loaded on the Arduino and I wouldn't be surprised if they weren't compatible. Meaning only LIFA can talk to hardware with the LIFA firmware on it.

Yeah sorry, like several others I'm somewhat restricted, and have to choose what I want to attend. Being a big part of the LAVA BBQ means I still need to try to make it to NI Week, and that might mean missing out on other summits for now.

Yeah much of what I learned about .Net picture boxes, image resizing, z-layering, and transparencies in LabVIEW, stems from that one GDI Resize VI that I think started from here. http://forums.ni.com/t5/LabVIEW/Net-image-resize-how-to-convert-to-format-labview-can-use/m-p/2199022#M704093 That spiked my curiosity and I've written several image library tools since then, which have been used in a few tools like my ribbon interface, that I never completed. Say one other thing I didn't think about, is that there is a vi.lib tool for turning a PNG stream of data, into LabVIEW data. I think it is just a DLL call in the background but it might load the PNG in a slightly different way. It is found at this path. <vi.lib>\wsapi\VIs\PNG Data to LV Image.vi"

After you have a package installed, you can navigate to the following directory: C:\ProgramData\JKI\VIPM\cache And you'll find all the packages you have installed. These are the files VIPM uses to install, so you can copy these self contained packages as a backup, and then choose to install them at a later date and not need any network access at all. I've actually done this on reuse libraries. Say I make a whole bunch of reuse code and package it up as a VIPC file. I can then include all the other dependencies (like OpenG or what ever) as a single VIPC file that contains everything needed to install our reuse without needing the internet. As with software libraries they development and support can stop at any moment, but the code in its current state can be backed up.

I think I know this one but I could be wrong. LabVIEW can't handle alpha layer information, so I suspect those pixels are something like 1% opacity which doesn't show up in a viewer as easily. I've seen this where I had a pixel that was black but at a low opacity. When you use the native LabVIEW read it just bumps that up to 100% and then there are black pixels when there wasn't before. I remember seeing some code a while ago that would actually set a threshold and set the pixels to the background color if they were below this level. I just tested this on some PNGs with alpha layers and I didn't quite get the output I expected so maybe this isn't your issue. Still you might want to load up the PNG in an image control that does support alpha layers better. Here is some code I did a while ago to demonstrate alpha layers, and native zooming using the picture box. http://forums.ni.com/t5/LabVIEW/NET-picturebox-convert-to-LabView-image/m-p/3125944#M897890 Is it possible to post the PNG image by the way?

Well NI sorta tried that and it was called External Nodes and it wasn't flexible enough. And to be fair you don't need N templates of subVIs to manage the different permutations, it is just the most straight forward way. I've had an XNode where there are multiple disabled diagram cases, and one case will get enabled based on the options selected. If you code in the smartness then you don't necessarily end up with multiple templates. Heck you don't have to even have one template you can write the VI from scratch, but again that isn't the most straight forward solution, so it seldom is used. I guess one down side I see from accepting multiple data types, then having one template VI read the data type, and then act differently based on it, is that then there is this extra overhead that wouldn't have been needed. I mean the XNode (and VIM) can know the data type it is being used on, and again if the logic is made, you don't need to do things like read the data type and act one way or another, it's just simpler this way.

It's hard to say, I honestly think this functionality just isn't complete, or if it is I'm missing some key component. The Dependency Chain is suppose to be be provided in the same way that a terminal is told to be adaptive or not, using that control on the front panel. Look at the NamesInFullyQualifiedName.vi, it generates the Dependency Chain. If you put in something like "a.b" you get two elements in the output "a", and "b", if you put in something like "[1a.b] you get two items, first has an index of 1, which is specified, and the second is "b]". I think this is some kind of way of specifying specific data types that a terminal can be, not just "Adaptive" changing to anything, or "Fixed" not changing, but instead changing to specific types. Personally if I were to implement something like this (and I've thought about it) I would specify the types that a terminal could be differently. Maybe provide a set of options in a wizard stating which controls can be what, and then that information could be saved as tags on that control, or maybe in a subfolder where control references could be which applied to that control. Having it be another control on the FP named a specific way, with data in it a specific way seems clunky, especially if that control isn't hidden. But even if it is as a developer I'd wonder why this random control is there which doesn't do anything. I think VI Analyzer would probably flag that as unused code that could be deleted. Oh don't get me wrong I think every terminal should have the option to be adaptive. But under some circumstances the developer of the function might want inputs to have a limited number of data types that they support. Like in the example I gave if I have a Delete From Array, and I provide a 1D array of Doubles, and I want to delete and index, but the index I specify is a string data type with the value of "blah" what should my function do? It is clear that an index input should not adapt to any data type, but only a limited number. Even the array input should be limited to only 1D arrays of anything, not scalars or multi dimensional arrays, unless the function can handle those types. Having it be a right click option on a connector pane seems like a perfect fit. Imagine if you right click and choose adaptive, and then are given a dialog where you specify what types it should adapt to. Any data type? Any 1D array? Any cluster? Any Numeric of N dimensions? Then in your code for that VI you could read what the type is, and do specific things if needed. I honestly think we could make something like this today, just given enough time. BTW sorry for hijacking your thread.

Okay a couple more things I learned. The first is something already does happen when you change the type on your VIM, two VIs are ran, <LV Install>\resource\GenericLabVIEW\GenericLabVIEW_AdaptToInputs.vi and optionally <LV Install>\resource\GenericLabVIEW\GenericLabVIEW_GenerateCode.vi If you look at some of the XNodes posted in the code repository they follow the same design. Basically if you re-wire a normal XNode, then the adapt ability is ran. Now if the data type of a terminal you cared about changed, you may need to go regenerate the code. Just like our XNodes, this VIM works in a similar way and these two VIs are ran, with the second one being optional. Next I also discovered something that basically breaks VIMs, but I think they are intended to allow for making some inputs adaptive, and some not. Imagine you have a delete from array, like the OpenG ones. It takes an array of something, and an array of indexes. If you turn this into a VIM both inputs are adaptive, but that isn't what you really want, indexes should always be an array of I32. Well if you put on your front panel of a VI a control named "Generic LabVIEW:Adapt To Type States", have the data type be a 2D array where columns 0 is control labels, and column 1 defines what that control should be. I believe FT means fixed, and unspecified are adaptive (which is why all inputs are adaptive by default). Of course when I go to use this it doesn't do some other things properly, like icon, and terminals aren't right so this isn't very useful yet, but I was just so excited I had to share, even if it doesn't do anything yet. Of course even if you do get some inputs adaptive and some fixed, you still have the issue of limiting some inputs to say scalar, or say 1D array but no other size. That again is where the flexibility of XNodes is needed at the moment.

VIMs in my mind are the express VI of type adaption. If your use cases are completely within the capabilities of a DAQ Assistant function, then you are going to love how simple it is to use. But if your needs don't fit those cases, then you need to write DAQ code using the DAQmx API. Same here. If you want XNode like features like mouse clicking, double clicking, right clicking, running a VI when a new type is wired, etc, then you're going to have to do it in an XNode, not a VIM. What we really need is some scripting code that generates XNodes, with the features of VIMs, then you have the simplicity of VIMs, with the flexibility of XNodes. The fact that VIMs just call the code in <LV Install>\resource\GenericLabVIEW makes it look possible.

Yeah again being a bit new to the RT scene I don't know all of the various OSs that were out there or supported. At the moment the only official way to turn an industrial PC into an RT LabVIEW compatible OS is to follow these instructions, which as I said I think loads up some vxWorks Pharlap OS. Basically load up MAX, load the boot image on a USB drive, boot your PC with it and install. There are several restrictions, the greatest one is you need to have a compatible network card, which generally supports Intel based ones, and a couple others. Using instructions for VirtualBox posted on NI.com I was able to do this in a VM. But what I don't see is any instructions or ways to do this with the newer Linux based RT OS. If I had my hands on one I wonder if I could just pull the harddrive, perform an image of it, and then use that in a VM, but I don't. I've been searching but I don't see anything on the idea exchange to add support for the Linux OS on industrial PCs. EDIT: It seems most of the Linux based RT systems have an ARM processor, but some are x86, these are the ones that pulling the hard drive image on might be useful.

It's only been a day since you posted the code, but that being said I opened it... Please don't take this the wrong way but some refactoring looks in order. If you have to scroll in more than one direction, then your code is probably not modular, scaleable, reusable, or extensible enough. It is difficult to follow and understand, and therefor difficult to troubleshoot and recommend a fix.

Yeah I made a post on the the NI forums about this. http://forums.ni.com/t5/LabVIEW/Property-is-supported-in-RT-but-will-always-return-an-error/m-p/3258138 It seems some of these UI nodes might work on the newer RT systems running Linux and have monitor outputs, and on remote front panels (I have yet to get this to work but crossrulz said it was possible). So I'm thinking the only way to get this HTML5 version to work on RT, is to get these properties to work on RT, and at least for my vxWorks VM of RT, I haven't found a way to make them work. If remote front panels causes other RT systems to have these nodes work, then I wonder if it is possible to publish these remote front panels, then have the RT connect to them, there by allowing the methods to work, and then you would be able to use this code to make HTML5 pages of it. For my application, I think I can live with remote front panels and have the LabVIEW Web components installed.

Okay I think I found the issue, of which I'd be curious to hear if NI has anything to say about it. The issue is with getting the references to the controls and indicators. On RT there is no front panel, so getting references to those controls isn't possible. But the normal way you would do this is to use the Front Panel Property on the VI. Reading the help is says it is available in Real-Time OS...but there is no FP in Real-Time...so it returns an error...so is this really available if it will always return an error? Seems like these two things don't agree. The reason this didn't return an error is because of a bug in the following VI. \FPPublisher\WebFrontPanel_class\WebFrontPanel_Create.vi The two for loops return references and errors, but if the loop runs 0 times (empty arrays) then the input error is cleared. This should either be changed to shift registers, or add the incoming error to the merge errors already in the VI.

So what is the likelihood that this type of thing could be used on a real-time system? I have a simulated RT system in a VM and I started testing with it and I made some progress, but things still don't quite work. I copied all the www files to the right location on the RT system, including the config file made setting the image type or not, and I modified the example to run without the event structure but instead poll the button values, then I ran the VI on the RT system. I got an error in the following VI because it tried to read the front panel, when there isn't one on RT. (Errro 1013) FPPublisher\WebFrontPanel_class\CreateHTML.vi This part of the code is relatively minor and just reads the size and color of a panel so I replaced the read with some constants for a test. After this the code ran without error so I thought I may get lucky. I went to the file browser from MAX and navigated to the following URL path in a web browser. http://192.168.56.101/files/ni-rt/startup/www/Example.html The page loaded up and...it was mostly blank. I viewed the page source and it is attached. Any idea why this wouldn't work? I looked into several of the properties you call to make the page and I didn't find one that said it wasn't supported on real-time. Example.htm

Ideally the whole project, all source, all libraries, all dependencies, with instructions on how to reproduce the issue. Usually this is done by zipping up all source, then uploading that zip in a post. For most this is not practical so some example code that exhibits the issue would work. Posting pictures is almost useless, some stuff can be understood from it but not things like what is going on in subVIs, how VIs are configured, or how express VIs are configured just to name a few down sides. If you do attach images, it is recommended you post snippets which are PNG files with embedded code in them. They only contain that VI so all external dependencies will still be missing. http://www.ni.com/tutorial/9330/en/

So without posting code it is hard to say where the scroll bars are coming from. Are they in the parent VI's pane? or are they in the VI that is inserted into the sub panel? In either case a property node call can fix it, or change the setting in the VI, for the affected pane. I sometimes have a situation where the user can resize the window, and in these cases the sub panel may or may not fit in the pane, of the parent window. So I have the VI enable or disable scrollbars, based on the window size, and the size of the sub panel, which is then sized to the VI that is inserted into it.

Wow very neat stuff. So I tried various things to get this to work in VMWare, which is my virtual machine of choice, but didn't have any luck. The two sticky points for me was the network adapter options, and the booting the USB drive. VMWare supports EFI booting so I thought that might work for the USB, but it didn't. I also tried converting the USB drive into a ISO with ImgBurn, and other tools but that didn't work either. But even if you had RT LabVIEW booting, if you don't have a compatible network adapter, it won't run anyway. And in the free version of VMWare I don't think there is a way to change the network adapter type that the guest OS sees. But yes your instructions on using VirtualBox worked great. I was able to make the VM with a SATA, and IDE, have the IDE be my USB drive, and have the network device be an Intel Pro/1000 which is supported. After this I was able to install the OS, and connect with MAX and install other various software, very cool stuff. I haven't played around with it much, but the prospect of being able to develop some code without the actual hardware is fantastic. Things like web services, console output, and the whole RT deployment process can be done in simulation. As for performing actual work I'm not so sure yet what it will be capable of. I know that in some enterprise VM software you can dedicate cores of a CPU in the host to a guest, which would make real-time applications a bit closer to the real thing. But not being an expert I can't say for sure, but having a deterministic OS, as a VM inside a non-deterministic OS makes me think that the guest OS wouldn't be 100% deterministic anymore. Then there is also the licensing side of things. I suspect NI would consider a VM installation of their RT software just as real as any other install, and would require a deployment license of RT.

I'm still not quite sure why someone would do this. I mean if I found a golden goose, or if someone gave me a golden goose, the point still remains that I now have a golden goose, why lie about it? If you are trying to impress your boss, they either are a developer and know of OpenG and know you are lying, or they are the management type, and don't really care about those types of details and just wants your work to be done. For other toolkits which aren't free, or don't have as open license as OpenG, I can see a desire to do this. Knee-jerk reaction would be to scold them for taking advantage of an open source consortium, but the sensible thing is to take Shaun's advice and probe into the situation a bit first.

Sorry if my mannerisms seem strange, replace my opening sentence with "What you are trying to do is not clear to me, could you explain it in another way that is clearer, or post simple demo code that exhibits the behavior". Yes I see you are resetting the timer, but couldn't tell from the picture if you have True wired to the Auto Reset, or the Reset, posting code instead of pictures in these cases makes it clearer. Attached is a quick example of what I was talking about. Where there is a loop that runs, and when you click a button two waits are done, one for 2 seconds one for 3 using the elapsed timer, resetting it between each call. This also resets when you first come into the wait so the timer should work as expected where it always counts up to 2, then 3. Notice that the reset only happens when the inner while loop has an iteration of 0, and then isn't reset until the next timer starts. Without this you will get strange behavior because multiple seconds will have gone between pressing the button a second time, so the first wait (the 2 second one) will be completed immediately. I suspect this is what you are seeing. I also don't intend on being rude.

Uh...what? The elapsed timer is intended to count up to a certain value, then it gets reset, and then it counts back up again and again. There is some optional inputs that can change this behavior but normally this is how it works. So if you are using the elapsed timer for a set of things, then stop, and you want to start the timer again, you should give it a True on the Reset input, the first time you are coming back into your loop. I've usually done this by using the Equal to Zero function, and wire it to the iteration counter of a for or while loop. Then it will be True the first time that loop starts which will reset the timer.