hooovahh

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.

Honestly I don't see any problem with just making a normal post asking for advice. Plenty of times someone will post a "This is how I did my CLD what do you think", or a "I'm new at LabVIEW how can I improve this" and as a collective we look over the code, post improvements and suggestions. I don't think it has ever been attempted with large projects so I don't know how it would go down. I think smaller programs work well because the effort from someone is small to open the code and say a few things. But for a large application I wonder if you won't get much contribution, because the time needed to understand the intent of the code, and then post solutions/suggestions might be larger.

Undocumented features causing LabVIEW to behave strangely? Inconceivable! But to be fair LabVIEW isn't bug free, and weird stuff like this can happen with normal features too.

I think that could be possible, if Windows supports multiple logins at the same time which it looks like over normal RDP you need the server edition. I'm not sure if other remote control programs allow for multiple logins at the same time. If they do then this shouldn't be a problem, as long as each user knows to only use their hardware. There maybe a LabVIEW solution in there, but personally I would rather use something simple that worked, rather than trying to roll my own method of hardware sharing over the internet. That problem has been solved by many companies already, just use one of theirs.

Wow that is some interesting results. I'm always interested in TDMS performance. Your timing function is a little flawed but the data is probably still close. UI elements in LabVIEW are updated asynchronously. So to get an accurate measure of how long a function takes to operate, you shouldn't be writing or reading to any UI elements, or using any property nodes in parallel with a timing test. Also it is generally a good idea to turn off Automatic Error handling, and Debugging because these can affect time measurements. That being said I don't think this changes your results much if any.

Well I found this help on the property. http://zone.ni.com/reference/en-XX/help/371361J-01/lvprop/lvclasslibrary_wire_pens/ I was thinking this was as simple as you forgetting to read the help but the help in this case isn't very...helpful.

Answering this seems far too dangerous. EDIT: Alright fine, just know breaking a NDA with NI is a very bad thing. Beta sign up.

A new technology developed by NI that has never been mentioned before? How many levels of management at NI did your post have to go through?

I remember a beta of one of the versions of LabVIEW had a bug where this wasn't true. A 5D array was bigger, and a 6D array was bigger with no limit. It was interesting to make a build array be huge and see the massive wire output like what you have here.

I almost believed you for a bit because FPGA code does do some weird things. I don't know if this is the case still or not, but at one point there were express VIs that you could open the block diagram of. If you kept drilling down into the VI you eventually found a subVI with no G code, only a single comment on the block diagram, and no objects on the front panel. The comment was a string of characters referencing the already compiled VHDL code to insert. I'm guessing the code just couldn't be easily represented in LabVIEW and NI just inserted some already compiled code to do the work. As for the XNode, add a breakpoint to one of the subVIs you think is drawing the icon, and save it. If that code does draw the node it should call it and break. Now why it gets called is a different question.

Well using the command line is the way to go, but I've never done it, I've just used tools that do it. Here is a quick link where you can get the revision with the command line. http://forums.ni.com/t5/LabVIEW/How-can-I-get-the-SVN-repository-version-in-my-VI/td-p/803586 I have yet to get the command to work for some reason not quite sure what I'm missing.

I mean the file on disk. Here is a document with some fun examples to run that describes it. https://decibel.ni.com/content/docs/DOC-20522 The way the file is written can influence fragmenatation. One way to avoid it is to use the TDMS write function as seldom as possible, where maybe you write all of the data types at once. Say you have 10 channels that are doubles and then 5 that are timestamps, and then 10 that are doubles. If you can force your code to write the 20 channels of doubles using one write function, instead of a write for doubles, then a write for timestamps, then a right for doubles, you will be better off. But even that is better than 10 writes one for each double channel, followed by 5 write one for each timestamp channel, followed by 10 writes one for each double channel. But even that is better than writing each sample for each channel one at a time.

So what you saw (I assume) is fragmentation. And as you said if the data is all in one big block getting the data is pretty quick. But if sections have to be grabbed and concatenated it takes more time. Because of this when I deal with large amounts of TDMS data, I will periodically defrag the file. This helps make the majority of the file one large block of data, with then fragmentation after that one block. This does take time, and during that the file can't really be accessed. I mean it can but I think the resource is locked, or the data you read could be corrupt. Writing the data in a way that performs the flush as seldom as possible will be the key. What this might mean for you is you have a circular buffer in memory, until it gets to a specific size, then flush it to the TDMS file. I like this idea and I've never tried using a TDMS file for this but given the fact that the offset and length can be specified on a read, I think it would work pretty well. All of my circular buffers could be held in memory at once so I never had a need for this type of thing. Post some code if you have an example of what you are thinking.

This is amazing this is fantastic...what is this? I know English isn't your first language but could you please try to elaborate on what a Plugin VI is and how it is useful? Also it crashed my LabVIEW not long after running it so there is that.

I enjoy posts like this. But with a moderator hat on it is difficult. We can't hide behind the fact that we are a forum of "advanced" developers. We are still a very public forum easily found. Searching "LabVIEW Password Crack" in Google results in the first hit being NI's forums, and the second being LAVA (thanks BTW flarn). There are topics we cannot talk about here, but then there are ones like this that are a grey area. I mean where would we be if the Super Secret INI key was never discussed? Would NI not have developed and released scripting as quickly, or at all? I am a man of few words...any questions?

This is pretty neat. One thing I noticed right away is that Auto-Tool has to be on. If you try tabbing through the tools your tab is intercepted by the front panel and your cursor moves from control to control. This also affects things like QuickDrop and the Clean-up shortcuts.