hooovahh

I had a function a while ago and I'm not sure if it was included in this post but it would give relative position from a parent to a child, or absolute position from the desktop to the child. Saving this information, then using the Windows Move function on load could be done relatively easily. Now if you have custom connections for a child window you'll need some custom way of re-making those connections on load. This demo just shows a random number generator for a window, but one could see that a publisher subscriber architecture could be used where a child window subscribes to data to display. And these are the connections I am talking about that would need to be saved and loaded as well.

You should it is awesome and I'm not biased at all...okay well I just wanted to explore more XNode stuff, and I think it could be useful. Right now the read returns the whole buffer, I can see that reading a subset could be useful especially if a rotate is not always needed. Also I'm getting the idea that if a rotate was required, that we could then write the newly rotated data back and set the pointer back to 0. I think this would mean that you can no longer have a write and read happening in parallel, but right now I think you could, not that I would want to. The benefit of this is that if you did two reads in a row before a write, the second read would never need a rotate. All sound improvements team, I'll implement these changes soon.

Okay I typed up a big long explanation on how it worked and half way through I figured out it wouldn't work the way I was thinking. Never mind I need to see an example first.

Oh that is clever. So the trade off would be that your data in memory will be twice the size it needs to be, but no shifting operation is needed, and the other down side is each write is two writes. I'm not convinced it would be worth it, but it could be done. Again I guess it comes down to the fact, will you expect to be reading more than you are writing? Or writing more than you are reading?

That's neat, never seen this functionality before. I have a bunch of other possible choices for XNet things too. XNet Database / Device / Frame / Signal / Cluster / Session etc. So I'm guessing it queries your system somehow to show what types of I/O references it can be. I really expected DAQmx to be in the list but it isn't.

The first place I thought about using this was in a graph situation, where you have a circular buffer of XY pair data for N channels and each channel maybe updated at different rates. In this case it made sense to read the whole buffer. I can see a use where you may want a subset and you can do that now of course reading the whole thing then get a subset, but it could be more efficient.

Good questions and I'm up for changing. At the moment the way this works is a pointer does exist which keeps track of the next write location. This means that after a write is performed, the value at index 0 may not be the oldest value in the buffer. Lets say your buffer has 100 elements. If you write 90 elements, then index 0 is the oldest, and index 89 is the newest. Index 90 through 99 will be the default of that data type. If you then write another 20 elements then the oldest data will be at index 10, the newest will be at index 9. This makes the write relatively fast because it doesn't need to shift the array around. I could do shifting after each write so index 0 is the oldest, and that would make reading easier because no shifting around would be needed. I designed it thinking that writes take place more often then reads. Without knowing the application this may or may not be true. So because the write doesn't shift the array around, the read needs to. I suppose one improvement is after the read does the shift around, it could write the array back, so that if you read again you won't need to shift it around again.

Name: Circular Buffer Submitter: hooovahh Submitted: 24 Sep 2014 Category: XNodes LabVIEW Version: 2011License Type: BSD (Most common) Description This package contains functions for maintaining a circular buffer. Create the Circular Buffer using the Initialize Circular Buffer function. This makes a DVR, and the data type of the DVR changes based on the data type specified for the circular buffer. The data type can be any type as long as it is not an array. It must be a scalar. The size of the buffer is specified on initialization but can be changed using the Change Circular Buffer Size function. Add data to the circular buffer using the Write Circular Buffer function. Scalar values can be added, or a 1D array of data can be added. The data type of the values to be written is the data type defined in the initialize function. Read the data back out of the circular buffer using the Read Circular Buffer function. The data type of the read values will be the data type defined in the initialize function. Cleanup the program by destroying the DVR on exit. An example VI Circular Buffer Demo shows how a Circular Buffer can be used. XNode Disclaimer The Initialize, Read, Write, Get Status, and Change Size functions are implemented as XNodes. NI does not provide support XNode development. For an introduction to XNodes read Adam Rofer's "XNodes - A Crash Course" presentation (http://lavag.org/files/file/56-xnodes-a-crash-course-powerpoint). Dependencies LAVA Palette-1.0.0.1 How It Works The source is all open and the template VIs for each XNode is what is executed when the XNode is generated. This means you are welcome to try to further optimize these XNodes by editing the templates. A new instance of the XNode will need to be placed which will force the new code to be used. If anyone finds performance improvements for these functions please feel free to post in the support topic. Because the size of the buffer is practically unbounded, I wanted to avoid unnecessary data copies, which is why it is designed around DVRs. There exists 3 things in the DVR, the buffer size, a pointer to the current write location in that buffer, and the array of scalar values, whos data type is defined during the initialization. Click here to download this file

Welcome to the future. You probably don't need me saying this but 8.6 was released over 6 years ago. Not that that means you need to upgrade but there's a bunch of good stuff since then. Oh and I think things like Call and Forget and the Static VI reference were added in LabVIEW 2011, someone correct me if I'm wrong.

Very interesting. So let me see if I get this straight because I've actually never used the ModifyCode Ability. So GenerateCode is for making the code that the XNode executes. What is common is to call this from something like AdaptToInputs after a new input has been wired. Often the GenerateCode ability will use a template VI instead of scripting from scratch for simplicity. So you can plop down a template VI, and wire up the terminals to the wires of the diagram, and this is the VI that is ran when the XNode executes. ModifyCode sounds like it is used to modify the already made VI, created when GenerateCode was called. For this reason I can see why you would want to try to call it after GenerateCode. In my development I've only ever used GenerateCode and I would remake the VI with scripting each time. I'm betting that in some cases a ModifyCode could be called to modify the already made VI, making that operation quicker. In some of my VIs I keep track if GenerateCode has ever been completed once and behave slightly differently if it has, so that code doesn't get re-generated all the time when it doesn't need to. I'm guessing I could do something similar where if code has been generated I could call the ModifyCode instead for faster editing of the VI.

I'm not sure if you've contacted NI on their forums yet, but I think they may be of more help.

I'm guessing while loop recursion can be used to accomplish this. If you get a moment can you post a quick VI that converts it properly using static cluster sizes? Then I can see if I can make it work similarly in the XNode.

I'll be the voice of Darren, just use quick drop and only use the palette for things you aren't familiar with. That being said I've never heard of a way to have different views for pinned versus right click palettes.

Good luck. That's one thing I spent a couple days playing with. Several times I thought I had it, and maybe I would have if I kept trying but in the end it wasn't worth the hassle. Now I see a need for trying to protect my data and have my XNode be in a class so I may re-investigate this later. If XNodes aren't complete for a reason, it is probably going to be edge cases that aren't complete, and I see XNodes in classes and libraries being one of them.

Okay I don't think so. I tried a bit and weird things happened with locking the library, but I think it could be possible for an XNode to script itself, and contain in it a copy of its own XNode but you wouldn't want to. An XNode is a library and having an instance of the XNode somewhere locks the whole library. Like a XControl having a copy will lock the facade from editing. So having a copy of itself would lock itself and may make editing impossible. It's like asking can an XControl contain an XControl that is itself? Well maybe, but don't ever try it. As for your other question I just tried this with the structure you described and it worked just fine. I had a cluster of three elements, one element was just a numeric, the next was an array of a cluster with one element in it that is a numeric. The third element was a cluster with one element, which was an array of a cluster, with one element which was a string. I turned this into an array of variants with the Data to Variant then back again with this XNode and all values came in. What structure did you try that it didn't work with?

EDIT: Alright never mind I just made the XNode from scratch. It supports LabVIEW 2011+. It supports breaking the wire if the input is not a cluster, it does clusters in clusters, it has the type adaption on the output, and the icon changes color, based on the color of the cluster wired into it. I also built an EXE using it just to make sure that worked and it does. All source is included with no passwords. To see how it works just open the XNode Template.vi. It will basically just set the cluster size and change the terminal types to what was wired. Array Of Variant To Cluster XNode.zip

Well I believe LabVIEW 2014 now includes the Database Connectivity toolkit so it can be used there. Is there a version of LabVIEW you need that is not 2014? I can try to take the 2014 version and back save it to what you need. BTW looking at the XNode it is a pretty manual process of indexing each element from the variant using an Index array (not sure why a for loop wasn't used) then it uses Variant to Data for each, element and a bundle at the end. Did you intentionally miss the case when you cluster has 2-4 elements?

I assume you meant XNodes not XControls. After an XNode is interacted with it will make the VI using scripting. And so in an EXE this VI should be what is used, and therefore no XNodes exist in a EXE, only the VIs they make. Besides NI uses XNodes all the time. A common one is the match regular expression so you shouldn't have any issues. ...that being said I just tried to make an EXE with my VR package and it fails...so yeah I need to look into that. EDIT: It looks like this does work. I've been making a few changes since this release and something in that version broke which doesn't allow EXEs to be made. This version works fine. Double EDIT: So it looks like from source works, from the files on the palette it doesn't so something got messed up in the package making process. But this shows that that XNodes themselves can be in EXEs. Tripple EDIT: Okay so I found the issue was with the Post-Install VI that was being used in the package making process. It wasn't all that necessary and I got rid of it and uploaded a new version 1.0.1.11 that I have built into EXE without a problem. The new version uses the UpdateData ability so older copies of the XNode should be replaced with newer ones after opening a VI that used the older version.

They can be added to a library, but XNodes themselves are a library. So this makes the VI name space very long "MyLibraryClassName::MyXNodeLibraryName::MyVIThatDoesStuff.vi" Also I don't know if it was me but I got into a situation where I would open the library which would load the XNode into memory, which would lock the XNode, preventing me from editing it. Not sure if it was my own fault but my solution was to just not put an XNode in a library.

Cross post

I don't have IMAQ installed but the image is reference based. So before editing the image you'll want to use the IMAQ Copy which makes a new copy of the image as a new reference. Then you can do the operations you normally do to add the fade effect. Then you have the original as the copy you made earlier.

Oh boy are you in luck. So I have tucked away some code I made a while ago for reading parts of the VI file structure. It needs some polish and more features but here is the basics of it. Open the attachment with OpenG installed, I think it uses the File and MD5 packages. Then open the Example Read VI Data. It will read in things like description, icon, version, VI title, bookmarks and a few other things from the file on disk. Yes it did have the ability to overwrite passwords but I removed that for this post. Also I'd like to mention that the VI Explorer is just crap. The way it is written it is obvious the author comes from a text based language. Looking at his PHP source shows how good he is at text programming. That is mostly what these VIs are, is the reverse of his PHP source. Oh and by the way I don't know if you have visited his site lately but he has updated source that reads front panel and block diagram objects. This is done by reading the BDHX and FPHX sections, then uncompressing them. As for editing the VI..yeah not so much sorry. I assume there are tons of hashes and checksums to look for file corruption. VI File Structure.zip

It's obvious you've never actually developed an XNode, because in my opinion it is easier than making 60+ polymorphic VIs and then having to add them. I don't want to derail the topic but here are a few reasons XNodes could be considered the better solution: XNodes make the instance with scripting so any data type can be used, where with a polymorphic VI you need one for each data type. I've had polymorphic VIs with 60+ VIs and it still didn't meet all the type needs. Most XNodes are only 5-8 VIs and can cover many more cases, with more functionality. Fewer VIs in memory - Polymorphic VIs load all VIs into memory. This means all 60+ where a XNode is just a few. Updating a polymorphic VI is a pain because you have to update all 60+ versions. XNodes have the UpdateType ability which can have revisions like classes and force a mutation to update an older version. XNodes appear to be inlined VIs and run as fast as possible. XNodes when in a built EXE are removed and they are replaced with the VI that is made so it should behave just as a normal VI in a production application. XNodes can react to other input like user interactions that normal VIs can't. Icon updating, and help can be generated based on the specific usage of the XNode. XNodes maybe unreleased and undocumented, but they are not unsupported. NI has many XNodes, and even promote a few like the Math Node. And I don't know how a polymorphic VI would be easier for the end user. My goal is to make life easier for developers and XNodes do that which is why I'm so interested in them. I do think there is a stigma associated with XNodes which maybe why people avoid them, but I saw some amazing things done with scripting in the 7.x era before NI officially supported that as well.

So sorry to hear that. Having a culture of good software development in the workplace, is more beneficial than 10 "experts" who just throw stuff together until it works. This is one reason why I feel LAVA is such a good resource because it helps encourage the good software development culture. Having enthusiastic developers in the workplace helps, and it sounds like you could be a shining light for your co-workers.