hooovahh

Pretty neat, thanks. As for your forum comment. How are the applications running on these targets different than the majority of LabVIEW applications running on Windows? If there is a need for a separate discussion subforum for targets like these, I can talk to the powers that be, about making a separate subforum. But the way I see it these are just normal Windows targets running normal EXEs. The only discussion about them I could see is about the hardware selection which can really take place anywhere, even the LAVA Lounge would be appropriate.

Okay now that I thought about it a bit more I'm not certain this is possible. The issue comes from the fact that we need to get the connector pane, of a VI but not using the VI reference, only using the data type of the wired type. XNodes are edit time scripting, and so it can't tell you what the VI name or path to the VI that is wired to an input, it can only tell you the type of data that is wired. So given a VI Reference Control, that is strictly typed, can you determine the connector pane using only the type of the reference, and not the data itself? And I'm not certain that you can. EDIT: Okay maybe vi.lib\Utility\VariantDataType\GetRefnumInfo.vi is what I'm looking for.

I think so...it could even have the right click option to wait on the response or not. I started going through the idea exchange and I probably found 10 or more ideas that could be done today using XNodes, this one is just another to add to my list. I think the most complicated part (not that it's impossible) would be the terminal generation, based on the VI reference wired. You'd probably have to get the connector pane options as an image (which exists) for the node image, shifting it slightly just like the call by reference does today. Then the GetTerms is going to have to determine the connector pane and make the rest of the terminals...I think that could be it. Maybe have an option to close the reference or not with a right click. Doubt I'll get time for this one but it is possible.

Honestly I think I'd prefer the function work in this manner rather than opening a new reference to the VI that I then need to close each time. I wouldn't expect a function like this to open a new reference, but rather just return the reference it already has, similar to other property nodes that return a reference to something already open.

Yup, wire a string or a path to the VI Path terminal and it accepts either. The VI name needs to be the full qualified name including libraries, but the VI Name property node returns it in this form.

It sounds simple enough, but you should post your code so we are sure what you mean.

The only improvement I can suggest is to use the VI Name instead of VI Path. If you're attempting to use this on a VI that hasn't been saved yet, obviously the path will return not a path. The VI Name works because the VI is already in memory, it has to be because it is a dependency of the calling VI when you put down the static VI reference.

Time to upgrade? 2015 is pretty awesome. Heck 2012 is pretty good (conditional, concatenating tunnels)

It's intended to work the opposite way. You can have many Scales and they are all independent of each other. But a Plot can use only a single Scale. But a Scale can be applied to multiple plots, so updating that one Scale changes the look of all the Plots that use it.

Starting I think in 2012 there is a property called Inserted VI which returns the reference of the VI in the subpanel. Otherwise you need to keep track of it your self some how.

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.