hooovahh

At NI Week I asked about this and they said the only compiler supported is the newest ones. I believe they said Vivado. http://digital.ni.com/public.nsf/allkb/02EBA6105D04A1E686257D4E00144C92 That being said if you have an active SSP you don't need to compile your FPGA yourself anymore. NI now includes the free cloud compile for up to 5 simultaneous compilations. https://users.niwsc.com/compilecloud/#/

They can be created using scripting, but I don't think if you click on an XNode Property node, that it will list the available properties. The purpose of this was to essentially show what all properties and methods are available for the XNode and XNode Library classes.

Here is a demonstration showing how to insert any arbitrary window into another. Of course it has some usability issues as mentioned. http://forums.ni.com/t5/LabVIEW/How-to-run-an-exe-as-a-window-inside-a-VI/m-p/3113729#M893102

This is an apples and oranges comparison. One is a framework intended to be developed and modified, the other is a more or less closed module that the user is never intended to open, just use it. One is feature complete, the other is a shell of an application. In that case I would say using an XNode is something a CLAD developer can do with no instructions. You've probably used a few XNodes without even knowing it (NI slipped a few on the palette over the years). Your comment about standards makes more sense now, and I agree with it.

I honestly don't know what you're talking about, I get that it is a joke but I don't get the joke. You can't easily just open an XNode. If there a template VI (like most of mine have) you can open that but actually opening the code generated requires some INI keys. Yeah that's part of the problem, the only "standard" on making an actor design at the moment is the NI Actor Framework. This standard is not catching on in the advanced developer community. I can speculate why but the point is, if standardization is key to adoption, then all of these different designs might be adding to the noise. Which is hard for me to say because lots of what i see in the DQMH, and JKI Objects I like a lot. And will likely be using one of them over the Actor Framework. The value of the DQMH videos, and scripting code should not be understated. Conceptualizing, and designing actor based software is confusing at first. Being able to say "Here watch this video for a few minutes, and you'll get the basics." is going to be a very valuable tool.

Just tried in 2015 and it still isn't resizable. Could be a feature request, could be a bug. I'd post on the NI forums, or the idea exchange to get NI's attention.

You know what, I need to look at this differently, and Shaun is helping with that. VIMs are getting people excited about an entry level way of doing type adaption, allowing for unrealized ways of making code. This technology has its limitations, and as users use VIMs they might realize the powerful potential of XNodes and how they can bridge the gap between what they can do with VIMs and what they want to do with them. It's a gateway drug VI. Or they may have a VIM that just does exactly what they want and don't need to change a thing...I wonder if I should try to make Variant Repositories with VIMs. Not all of the features would be supported but type adaption is the big selling point. Any function similar to Read/Write Anything could benefit from this for sure.

Such a great analogy. This is less breaking LabVIEW's programming concepts, and more like adding another dimension to them. Is LabVIEW the first 3D programming language? Not quite I guess. Isn't there a principal that a observer in one dimension can observe the next dimension higher, but only at a single frame of reference? Maybe not the right wording but you know. We in 3D space can observe 4D space time. So our 2D monitors can observe a 3D space that is static. Maybe this is LabVIEW's way of representing the 3D space.

At some point I need to stop talking and we are pretty much there. What I do feel comfortable saying (because it doesn't relate to LabVIEW in particular) is you have an equation similar to this (but not this exactly): MD5(SomeData + Salt + MoreData) = Hash In this equation you can read the SomeData, MoreData, and the Hash from the contents of the file. So plug those into your equation and all you are missing is the salt. Put in a value of 0 for the Salt and see if the two sides of the equation are equal. If they are you have your salt, if they aren't try another number. Eventually you'll get it. And knowing your salt is made up of three numbers, of which each is relatively low number, makes this test a pretty quick when it works. When it doesn't work then usually what you thought was the value for one of your variables like SomeData was the wrong data, so the two sides will never be equal.

Yes but in this case the queue reference can be accessed without needing the value on the wire. A LabVIEW paradigm is a function doesn't execute until all of its inputs are available, and once it is done executing all of the outputs are generated. In this case a while loop can execute with a Channel Wire connected to it, that doesn't come from a data flow from a source. Most of how a Channel Wire works is normal G, but the wire behavior not enforcing data flow is something NI had to do for this one wire type (or types). I think it's been mentioned before but all this is, is syntactical sugar. Anything a Channel Wire can do, I can do without Channel Wires. But if I can make my code faster, cleaner, and be better documented, then I can see the value in this feature.

Wait...you mean...we agree...again? This is like two times in a month. Is it you that is changing, or me? Lets christen our new found friendship over beers

So not TCP but I have had a case where I needed to monitor N CAN buses, from 1 to 6, across 1 to 3 PCI/PXI CAN cards. I just had a single actor for CAN, which had an array of CAN port references. I then had one UI that could show me the messages coming in from one port, or all of them with time synchronization. Similar situations with N DAQ devices. One actor did AIO signals one for DIO but I could have gotten away with one DAQ actor I guess. It got a message to read signals, then it would figure out based on what cards it was on, which tasks could be started in parallel, and it would do so creating an array of references that it kept track of. Then the reply would send back the array of values that were requested. The requester didn't care if it came from N actors, or were taken sequentially, or in parallel (unless specified), it just wanted data, and the AIO actor took care of it. The benefit in my mind was simple code. Any LabVIEW developer with CLAD experience could open the code, find where actors were started in parallel (because they were just subVI calls) and find what was going on. No nebulous cloud business, starting and stopping not knowing what is running or doing what. Just open the VI and see. I'm not saying it has to be this way but it was powerful and simple. The next actor type framework I adopt is going to have those same requirements.

So I made a few improvements, first I found that there were relinking issues from trying to load resources normally in the user.lib. The updated one should load from normal locations like the downloads folder (which is where most people are going to try this out from) It looks like you might just not know the right way to make UI's with the event structure. Generally you move the control into the case that is handling it, so that its value is read when you enter. Buttons being latch when released causes them to bounce back, so they are only true for that first time, then go back to false. This means when you enter the event structure it will always have a value of true and you don't need to check it. Polling the timeout case with 0ms isn't necessary. The code does nothing until you press a button or interact with the UI so remove it. I added a case for panel close, so to stop you close the window instead of hitting a button. Prompting for the number of numerics, strings, and paths, had a while loop with 0ms wait which is bad for CPU usage. I replaced it with an event structure. I removed several backwards wires. I added Update While Typing to the string control, so that value changes are registered if you click on the save right after making a change. After a load it picks the first resource to display. Functionally I think it is the same as what you had. Now lets talk about this fix MD5 business you have going on. You prompt to ask how many Numerics, Strings, and Paths are on your connector pane, but you never use this data to calculate your salt. But even if you did you need to be aware that this includes going into other controls. If you have a single cluster with two numerics in it on the connector pane, and a scalar numerc also on the connector pane then you have 3. So this needs to include things like numerics and strings in error controls. A more robust method is to calculate the salt by reversing the equation and guessing what the salt is. I've done this in the past by assuming something like, there will be no more than 20 numerics, strings, or path controls on the connector pane. This could be increased of course. But with a known good VI you have the MD5 output, and the data going into the MD5 you just are missing the salt. An equation with just one missing variable. So if you keep guessing the salt, making the assumption that there will be no more than 20, then it doesn't take too long to go through each possible combination finding the one that makes the equation MD5 = Data + Salt. If you want you can remove the limit of 20 setting it to 255, but it would take a decent amount of time to go through all 255*255*255 possible combinations, where 20*20*20 is more realistic. You also aren't fixing some issues when VIs are part of a library, I believe there are other checksums that need to be updated but don't remember what they were exactly. Oh and was the XNode necessary? Could you just perform the search on the string name "LIBN" instead of taking LIBN then looking up the type as a number? And I know this won't work for all versions of LabVIEW. You know how Ned lets you save in multiple binary modes? That's because older LabVIEW versions used the older binary methods, which might have different named blocks, so BDHX I think is some times BDHA or BDHB. And 2015 is really new, most people aren't going to have it, an older version might have been a better choice. Low-Level VI Manipulation Hooovahh Edit.zip

With NI Week this fell off my radar sorry. I never had a need for N floating windows. But if I did I would handle it by having a single actor be the "Dialog Actor" or whatever, which would spawn new VIs asynchronously. It would then keep track of all asynchronously running dialogs with an array of references. Closing a window would send an event down to the Dialog Actor which would do whatever it is that it needed. If the Dialog Actor got a message to close a particular window, or save or load control values it would be the one responsible for that. I've also handled similar tasks by using a listbox of windows, which would insert them one at a time into a subpanel. This handled the N instances of something in a single window. The benefits of this type of design is the only thing that is asynchronous (and more difficult to debug) is the actual UI, not the actor it self handling all the messages. Probing and opening that actor was easy because it was on the block diagram of my main running VI and I could hold CTRL and double click to open the BD.

Great suggestion, topic split. Next time suggest that sooner, 2 1/2 pages of that 3 page discussion was on this one feature.

Thread split with discussions on Channel Wires moved to here.

I believe this is exactly what it is. Thanks for the link to the encryption compendium, I'll check it out. The corporate world I live in does not consider Linux a viable option for anything. I will be sticking with Windows.

But in NI's defense they did use visual queues to help show that it isn't just a normal wire, going into and out of structures don't use tunnels. This for me was enough to know they were special, but probably not enough for new developers.

So at an NI Week presentation this year, NI talked about how their new cRIOs with RT linux can have some kind of seed key encryption on them for some level of protection. What this basically means is you have a public key, that can be used to encrypt data, then you can send that data, and using a private key, decrypt the data into the original payload. I thought that was a neat idea and something that I haven't personally needed but got curious to see if a toolkit existed that uses this technology. Especially if the payload can really just be a stream of bytes, which can represent any data type. I believe the RT Linux systems are using GnuPG, and I found a Windows install, and command line documentation. Has anyone done this before? Anyone done it in LabVIEW?

There was never a LabVIEW 2008, not sure what version this worked in but I'm sure it is not a supported feature of LabVIEW. The right answer is to make a new application. Editing an EXE is not supported, and by doing so you might be causing unpredictable changes to the software. If you get nothing else out of this, I hope this is a lesson for you to implement a source code control system so you can easily roll back and forward to releases. You could then get the source which was used for your last EXE, make a branch, make changes, then make a new EXE. But one thing that just occurred to me, does your EXEs have their block diagrams and front panels removed? If they don't then I suspect you can get tricky and extract the VIs from it, make changes, then build with that source.

The Load and Save resources is a relatively well known function, and was recently discussed in a thread where a user was looking for a way to detect if a block diagram existed, when looking at the VI contents within an EXE. https://lavag.org/topic/19068-does-vi-have-block-diagram-at-runtime/#entry114822 In that case the detection method was to look for the BDHb, BDHx, BDHc, or BDHP blocks. My method in that VI was to parse the binary file itself pulling out the block. I posted that code, or similar code in a thread, with you some time last year. The Ned window and XML is a little less known, for several reasons. I discovered it myself by going through the list of keyboard shortcuts. I read up about the heap peak window (CTRL+SHIFT+D, CTRL+SHIFT+H), then I saw there was a window command (CTRL+SHIFT+D, CTRL+SHIFT+W). I figured this meant Debug, and Window and Debug and Heap Peak, so I went through the whole keyboard looking for new shortcuts, low and behold D, N was the ned window. As you can imagine saving in XML is an incomplete function. It might work for simple VIs, but I'm guessing not all VI types are supported. Things like VIs in libraries, ability VIs, and other things might not be supported. When I talk to other LabVIEW guru's and I want to blow their mind with features that they didn't know existed in LabVIEW, talking about VI password protection, and saving in XML are the topics I usually go to. Now that more people know about these things I need to continue to research other topics. That being said you did teach me something new today, and that is the ability to set and get Ned settings using VI Server, that is some very cool stuff and could come in handy.

Did you mean to post the code as a .vlibp? Do you realize this removes the BD and makes the code only executable in that version of LabVIEW and no other? At the moment this means only those with LabVIEW 2014 can run this VI. On top of that the community might be curious about the implementation, and fixing any limitations or bugs but can't without the source. VIs seem to be lacking documentation. Which also makes me not sure what the difference is between the new and "Old" versions. Do you intend on supporting tabbing into the element of an array control? I also saw a strange bug where if you skip tabbing into a tab control, it sometimes won't let me tab out of it. A VI is attached which shows this issue. Still it is a very neat feature, and hope it can be improved so others can use it. Tab Out of Tab Bug.vi

@ShaunR I disagree. But if my options are to make an awesome XNode, that is built on unreleased technology, or make a decent but not perfect polymorphic VI but is supported, I will go with the polymorphic VI most of the time. Uh...aren't you NI? Where would you like us to report known issues for this feature? I think the real answer is, we do like we always have, and NI doesn't officially support unreleased features outside of NI. I have lots of private functions that when they don't work I don't call up NI, because I know I won't get support. But I know a few at R&D will troll these (and NI) forums and help us out, telling us a general feeling of "This is mostly stable and lacks documentation" or "This will crash LabVIEW, do not use it." If you are one of those with inside information, we'd greatly appreciate any details you can give about stability, or instability of unofficial features.

That's not true, it's more like you have a nail, and we both have hammers, but my hammer can hit more than just the one nail that your hammer is limited to. Polymorphic VIs have a subset of feature that an XNode can. Of course they could be seen as overly complicated method of doing the same thing. Also can we agree that the polymorphic VI editor is a major pain to work with. Of course having a difficult feature of LabVIEW shouldn't mean to throw that feature away, it might be to suggest improvements, or make alternate editors. I'm just trying to make a point that there are several features of LabVIEW that have subset features of this one unreleased technology. I think the thing about XNodes that has me coming back, is that given enough effort they can meet so many needs. Where things like XControls usually fall short of some edge case, unless the uses are very limited, at which point all that extra effort feel wasted. If I wanted to make a competitor to a polymorphic VI using XNodes I could and it would probably work better than the native polymorphic VIs, supporting more features too.

I've always done this with the command line version of VLC. Here is the example command for converting a WAV to an MP3 I bet there is a way to reverse this.