hooovahh

Support, documentation, and examples are a few things I know you get without ever having used it. If I were experienced with CUDA (which is sounds like you are) you might not see enough value in it. Download a trial and try it out, and if you do please report back your honest opinion of the toolkit for others to see, I get the feeling few have ever used it.

FYI Crosspost

Yeah I actually took that and modified it to make this QD. https://decibel.ni.com/content/docs/DOC-31302 When using mine, adding the Shift modifier should do just like that function where it shows the file in explorer. Without the shift it does something completely different where it shows the currently opened VIs. I just thought it was a waste to not have some secondary function, especially when QD shortcuts are in high demand.

I have seen that issue many times all on 2012, or 2012 SP1. I believe they fixed that in 2013 not just 2014. I still have some programs made in 2012 and I dread making changes just because I know it will take several restarts of LabVIEW to get my EXE built again. Usually I say not to upgrade to a new version of LabVIEW mid project due to the unknown risk, but for me I think the risk is worth being able to make EXEs easier again.

Another neat trick is you can open an explorer window, and have a specific file in that folder selected using the /select switch when calling explorer from a command line. I tried this, this morning and it worked but for some reason the new windows were minimized. Probably another switch I'm missing.

If you asking how to read a file, it doesn't really matter what the file is, you can use the Read Binary File with an array of bytes. But the usefulness of this is very small. It still isn't clear why you need to load a hex file with LabVIEW.

Yeah it should be possible. But rather than trying to read the file into LabVIEW, can you just use the hex file in a commandline program to load your device? AVRDUDE has command line support so you can provide the file and interface and it uploads it. You can make this a batch file if you wanted which is probably easier than LabVIEW.

I don't want to go off topic...but you have 7 posts...been registered since 2005...and you are a premium member. Congratulations to you sir, and thank you for supporting this forum.

The typical disclaimer to be said is that using this INI key enables private functions of LabVIEW which NI does not officially support. Using any of these private functions means you are more or less on your own. Support for these functions is non-existent, documentation is non-existent, and these functions may change from version to version without mention in a change log.

Revive a 5 year old thread? Why not. Turns out there is a easier way to concatenate a 2D array of numerics horizontally using the matrix math build matrix function. There is a right click option for append columns, or append rows. http://forums.ni.com/t5/LabVIEW/Concatenate-2d-arrays/m-p/2959175#M853118

They aren't the same, but another term you maybe more familiar with is Instance, as in Application Instance.

You will never see advertised maximum transfer rates on any bus. The 480MB/s mentioned doesn't take into account all the extra bit packing, bookend messaging, bit correction, or CRC checking of data. Getting higher transfer rates highly depend on how the data is being written. Lets say you have 10 bytes of overhead for a packet over USB. Well if you write one byte at a time you are going to have a lot of wasted overhead. It would be best if you could write 1KB and only have that extra 10 bytes. If you aren't already I recommend using TDMS. It's made to be a streaming file format which handles buffering well for the most part. You just perform the write operation and then it will flush to disk when criteria are met. You can then post process the file into some other format if you like. Of course you don't need TDMS, you can do your own buffering on a CSV file and it will probably work just as well in your application.

I don't know if I would call this buggy, but unintended instead. The OpenG fit function just resizes the window to be the same size as the decoration. In this case 720 by 504. If I resize the window to be this size manually then what the UI looks like, is exactly what the UI would look like if you run the VI and have it resize the window. The window resize resizes the graph, and the graph resize resizes the whole UI. So resizing the UI either by manual means or the fit function screws with the whole thing. EDIT: Proposed solution, splitters and panes, or subpanels.

Yeah I assume flush would fix this, but cause the index file to be larger than it could be. I handle this by only having the open in one place and reading and writing all comes from that one actor, with messaging to other actors if they want to write, or read data. I understand the concurrent references idea and that is an appealing feature, but race conditions like this can happen and sometimes that doesn't matter, but it sounds like in this case it does.

I never thought of that, but I use User Events not Queues. So while the reference will still be destroyed, I wouldn't have any idea it was destroyed unless I again polled the reference to see that it was still valid. EDIT: Maybe I could get away with just the watchdog actor polling the reference, and the other actors being told by the watchdog to shutdown if the reference goes invalid.

Absolutely. While I'm sure this type of thing has been done many times over I would find value in seeing this and I think others might too. If you want to drum up more discussion on your implementation feel free to make a new topic on it.

There are cases where a graceful shutdown just doesn't happen. During development weird things may happen, that's why it is development. You should never use the abort VI right? CTRL + <Period> But it happens from time to time. For what ever reason you aborted a VI and didn't run clean up. So you didn't automatically kill the rogue actors. Closing and restarting LabVIEW is an option, but a quicker option would be an abort all VIs (including clones). EDIT: I re-read you post and I don't hate it but then you are constantly polling in each actor right? Or you have an actor that just monitors the top level VI activity and sends the abort to the other actors if needed.

Okay here's the issue or what I believe is the issue. TDMS may not write to disk immediately after a write or set properties. Because of this opening a second reference to a file is really a race condition between the flush routine and the read. The way to fix this is to only perform the TDMS open in one location, and then share that reference to the read, and write operations. Don't open a second reference to the file.

I agree that as long as none of the new features are being used why upgrade to 2014 for package building? But one could argue that VIPM is free for the community and why would you not want to use the latest? And that's where edge cases like you (and me) come in.

Not sure if there was a reason, or it just happened to be the version of VIPM installed. In either case a package file is a glorified zip, so you can extract it and get at the files if you can't install it. Sure a packages does more things like it can run a Pre/Post VI, and copy files to specific locations, but if you can't open a 2014 package in VIPM you can at least look at the files by extracting it with 7-zip, or many other zip programs.

The Abort VI doesn't work in this case. Clones don't show up in the All VIs in Memory. The best technique at the moment is for all VIs in memory that are clones, try to guess the VI name (with the instance). Which I believe is what the Task Manager does.

It is the same process more or less. I couldn't find an article that was only for local EXE debug but it is the same steps in EXE building.

I started saying Wife/Spouse in my message and then got lazy and only said wife. I hope it is understood that I meant it for spouses not just wives. If I remember I'll start a new thread next year to see if there is interest in a spouse ribbon.

http://digital.ni.com/public.nsf/allkb/8DA679805915DE40862572D5007B2F70 You enable it when building an EXE and the EXE will contain all the front panels and block diagrams. Then with a full development system you can see the EXE execute just like a VI.

Had a great time with you guys. Her comment about how the ribbon collection started did get me thinking. Would it be a good idea to have a "Wife/Spouse" ribbons made? On the one hand I don't like the idea of having ribbons made for every category, but I think the wives catch on to the fact that the length of your ribbons is something to show off. Wives probably feel left out with no ribbons of their own. I was the one that had the LAVA ribbons made this year so I feel like I could probably get something together and make some for the wives to have. I just feel like they should feel more welcomed, not isolated. It did seem like there were a good number of wives there this year. EDIT: BTW I almost brought my wife but something came up. There is a good chance she'll be coming with me next year.