hooovahh

It's hard to say for sure, but based on the performance I'd say some DAQ work shouldn't be a problem. I'd guess you'd see significant performance issues if you tried taking something like N channels N samples at a very high rate, and then try to post process the data. But this might be fine for say a log to TDMS and then display a subset of data. A quad core atom isn't nothing to sneeze at. In the past I actually deployed a test system that ran on a dual core atom, running Windows XP. It had a couple ethernet based cDAQ systems performing a sequence of events for controlling solenoids, and measuring mass flow. Ultimately it was used to measure the efficiency of semi-truck air dryers. We went with this PC because it was pretty small. It had room for one PCI slot and was passively cooled, it was just a big heat sink that we could put in the cabinet with all the equipment. We just attached a monitor on an arm and didn't need the whole second cabinet we were replacing.

Yeah I think the same thing. Really it doesn't matter the language, but if a program was developed with a mouse and keyboard in mind, it probably doesn't work well on a touch screen. If I knew I'd be targeting a touch screen, I would probably need a different set of hack-ish UI tools. The first change that comes to mind is how right clicking would probably never be used. Or if it was a custom popup would be needed. There probably wouldn't be a menu bar, or if there was it would be replaced with custom large icons. And I imagine there would be more drag and drop, as well as larger controls.

Fair enough. I think people worry too much about a proper category. Generally the only time a move is requested is when the category has nothing to do with the subforum. And in those cases it takes like 5 seconds to move a post to another section. I guess speaking of performance, I'd expect any normal USB DAQ, or DMM to work with this hardware. In a pinch I've used a myDAQ for a DMM and basic scope. Having one of these tablets be the front end could be handy. I'd much rather have a Virtual Bench, if say maybe the cost were half what it currently is.

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.