hooovahh

Okay so I didn't get around to doing the double the buffer size technique. I'm not convinced it would be for the best due to the extra memory needed, and the fact that two writes need to take place for each write. But attached is a non-XNode version of the circular buffer which is implemented with strings. I wanted to share this improved version with offset and length for reading subsets of data, and not performing a shift 1D array if it isn't needed. Also if a shift was needed for the read, then write the shifted data back. There were also some bugs with what happens if the buffer wasn't filled once. There is also a mild bug with doing a read when the offset is greater than 0, and the length is greater than the size it will wrap around. I didn't get to figuring out a way to fix that. If anyone gets a chance take a look at the read and see if they can come up with a better way, or give the thumbs up to the way it was done. Non XNode Circular Buffer.zip

The future of technology, or at least what people won't shut up about, is wireless. You know, things like walkmans, flashlights, and solar calculators.

Okay I think I get it but for this to work the dual write operations need to stop after every buffer location has been written to once correct? allocate a buffer twice the size the user requested apply writes to buffer also to buffer[usersize + i] Once the buffer has every point written to, continue writing at buffer[usersize+1] wrapping back around to buffer[0] after buffer[usersize+usersize] is written use Array Subset Node to return any contiguous part of the buffer very efficiently as a contiguous subarray

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.