hooovahh

It sorta is dynamic. Actors can unregister or register to new events at run-time, but in practice is never really needs to. And the messaging structure is based on user events, and you can't register for an array of user events, unless each of the data types of each event are the same, which is where I used the variant as the data type. Also there are times when I might only want some information from the variant, and I don't pull out all of the payload, something like meta data instead, and I believe this is most efficient with a variant attribute, where you don't have to read everything.

Yeah I have other issues with the CVT, like performance. And when writing a messaging library that is uses a wrapper constantly for variant data, I wanted it to be light weight, and generally I didn't find a wrapper for a look up table that wasn't better when it comes to performance than Variant Attributes.

Well think of running your VI, similar to running a program for the first time, then closing it after the VI is done. So when you open up a new copy of Word, how does it know what your recent documents were? Well it can't just keep it in memory, because it is a new execution, unless it writes some data to a place on disk that will be maintained between runs. But a more simple way to accomplish this, is instead of using the Run button to do a new calculation, which again will run once, then stop, similar to running a program and exiting it, you can instead wrap the whole VI in a while loop, so the program keeps running until you tell it to exit. This is basic application design in LabVIEW, and while there are some work arounds, like reading and writing to local variables between runs, this design is not the appropriate method.

Listen noob... Oh...let me start again... What is your problem? Because reading your post it doesn't seem like you have any question. You state you have an array of numbers, and you are indexing each one, one at at time. Each element goes into a case statement, and then one of N things happen, based on the value of the that indexed value. So what isn't working? Your title doesn't reflect your post. You are asking about holding a value in the title but not in the code. One thing you might be asking is why is your output only one value? What I mean by that, is you give it 8, 5, and 4, but your output only shows a value for 4. The reason for this is because your loop runs 3 times as it should (by the way you don't need the array size and wiring to the N terminal, that is only needed if no arrays are indexed) But even if your loop runs 100 times, the output of the loop is always going to be the values returned from the last run, and that is because your outputs (the booleans) are scalars, not arrays, and the output tunnel is not being indexed. If you want every boolean value returned, right click the output tunnel and enable indexing. But now you have N booleans being returned but you can only display one (since your boolean on the front panel is just a single boolean) so what you might want is to add an Or Array Elements, which takes an array of booleans, and if one or more are true, then it returns a scalar true. There are of course easier ways of producing this same output. Like the attached code which does the same thing, but in a more scaleible way. You probably have seen these links before but here is some free LabVIEW training links if you have some fee time you should check them out, especially the introduction videos. NI Learning Center NI Getting Started -Hardware Basics -MyRIO Project Essentials Guide (lots of good simple circuits with links to youtube demonstrations) -LabVEW Basics -DAQ Application Tutorials -cRIO Developer's Guide Learn NI Training Resource Videos 3 Hour LabVIEW Introduction 6 Hour LabVIEW Introduction Self Paced training for students Self Paced training beginner to advanced, SSP Required LabVIEW Wiki on Training

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.