hooovahh

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.

With scripting you can make an event structure, but in version 2012 and older you couldn't edit the structure, but there were methods for it. So there was a remove case where you provided the index of the case to remove, but it would also return an error of not implemented. Since then NI has added full support for the event structure but it just another example where it allows you to do something, then gives a run-time error.

Is this another group doing similar work? http://h5labview.sourceforge.net/?home They mention using XNodes for the implementation as well. I've never heard of the file format but it does sound interesting. Without knowing much I'd still think TDMS is the better approach if you are going to stay in the NI world. There are of course features of HDF5 that aren't in TDMS, I just don't know if I would need them.

Okay I haven't tried out that private method yet but I plan on it. But I have been successful with the start of this post and have attached a quick example of it. This has no documentation, very little icons, very little functionality, but it demonstrates an init changing the data type, and a read changing the data type of an output, just run Example Data Type Change.vi. The majority of the work was fixed by using the adaptive terminal types as flarn suggested. But there are times that I need to know the data type of the wire, for things like updating the icon to change with the data type change. I accomplished this by making a template VI that I would edit then run with scripting, from the XNode, which would just make a constant on the block diagram, and pull out the type within the queue, and return it. There maybe better ways but it does what I want, where an Init VI makes the data type of the wire change, and then the other functions like dequeue changes the output terminals to match. Circular Buffer XNode Start.zip

You wouldn't happen to be freemason would you? In any case here are some links I just gave out for doing SVN stuff. https://decibel.ni.com/content/groups/large-labview-application-development/blog/2010/03/29/using-subversion-svn-with-labview Ultimatly it is what ever works best for you, but this is a good start. Oh here are a few other articles that have very good information, but some of it looking dated showing older versions of SVN. http://thinkinging.com/category/tortoisesvn/

AHH, yeah that would be beneficial. During my early career I was fortunate enough to work with many talented developers and saw many design patterns and was able to have a 1-on-1 to ask questions about decisions that were made. This really helped me shape the thought process I use when choosing design patterns. Unfortunately the issue you are going to have is, no one is going to want to show you their secret sauce. I mean lets say I did a program for John Deere and I'm really proud of how it works and think its great. I can't simply share that with the world, I'd likely be taken to court. I guess the only way you'll see a full application like this, is if the project was for my own company, and I had permission to share it. Which I think is unlikely. CLD/CLA examples are probably a good idea but like you said they are 4 hours of work, sounds like you are interested in the weeks/months long projects to see how they work. It probably goes without saying, but I wouldn't look for this type of thing from NI's examples.

I know this issue and I sorta struggle with it. There are a few solutions, but all of them involve extra writes. When you write Channel 1, you can write blank data to Channel 2. If this data is a double I recommend writing NaN. Same with when you write Channel 2 you'll need to write NaN to Channel 1. Or you can have an index or time column for each channel. So Index 1 and Channel 1 get written together, and Index 2 and Channel 2 get written together. Or you can take that a step further and have a group for each set of data that comes in a different rates. Lets say you have 5 channels at the same rate and another 2 at a different rate. The first 5 channels can share the same timestamp, and the next 2 can share a different one. In this case it seems like a good idea to have one index per group in the TDMS data. EDIT: The problem you are having is one I have too, which is we are trying to treat TDMS files as a report format. When really it is meant to just store the data. Reports can be generated using this data, but as soon as you try to just use the TDMS as your final report, you will hit formatting limitations like this that can be overcome with extra work.

Oh I've thought about it. This brings about a new problem of sharing data between XNodes which I also would like help in. Are you sure adaptive types work on outputs? I'm on my phone right now so I'll try that and a few other ideas in tomorrow.

Yeah another XNode question. This isn't a need but I think it would be a nice feature if it can be done. Has anyone thought of a way to have an XNode behave like other primatives, where the init defines the data type to be used, and the other functions know the data type and change their output based on it? So lets say you drop a Obtain Queue and wire a string to the Element Data Type terminal. Now when you use the Dequeue Element, the output changes to a string. Also the wire color changes but I'm less concerned with that at the moment. The first step in this I thought would be easy but I was wrong. I made an XNode where it has an input terminal that is adaptive. I planned on wiring to this a queue and then having this XNode change the output based on the queue data type. But to get the queue data type I need to read the terminal type which gets returned as a variant, then cast it to a queue, then use a function like preview queue and use the type of the output of that. The problem is to cast the variant to the queue, you need to know the type of queue it is. I think there are a few more tricks I could try but I was curious what others thing. Anyone done this? Anyone got any ideas?

I just have my template be a normal VI set to be merged when dropped from the palette. Why doesn't that solution work for you? Why must the template be a VIT file?

So when there was a premium option, I think the limit was 10MB total for all attachments, for non-premium members. I don't think code repository, or PMs was included in that limit but I could be wrong. If you go to your "My Settings" then click on "Manage Attachments" you'll see the attachments I mean that were part of the limit. I was getting close to that limit when I became a moderator which had unlimited, and same for premium at the time. I assume if there is no limit shown in the Manage Attachments page for normal members, then that means there is no limit. Or rather no practical limit, if you upload 2TB of VIs I'm sure Michael might do something about it.