crossrulz

I've been told that NI is using the Separate From Compiled for any VI they develop. For Windows only projects, I have never had an issue (working in 2013 and 2014). We had a small hiccup when trying to use the same VI in a project on Windows and cRIO RT. Cleared the object cache once and it was fine again for the rest of the project.

I would also go the CVT route here. The API is really good and quite simple to use once it is set up. It allows for the application growth a lot more than using globals for a very small performance hit.

If computer A is hosting the NSV and it is not running, then B should get an error when it tries to read the variable. With an error, I would expect the default values. But it may be the last read value. But you should be able to look for the error.

cross post on the dark side: http://forums.ni.com/t5/LabVIEW/Matrix-Multiply-slower-on-RT-than-PC/m-p/3053426#U3053426

I do that all the time. Simple queue to send commands to the parallel process. Have some reasonable timeout, do whatever is needed in the timeout case. If a command comes in, do what is needed with that command. But there is usally some need for state. So sometimes a state machine works better. Based on your reading from the FPGA, the simple timeout for read will probably work just fine. And with your FPGA, play around with Dynamic FPGA References. You can take you main FPGA reference and cast it into a more specific reference. This way, you can pass into your subVI a very specific interface, making the code possibly reusable. It at least performs some decoupling.

cross post on the dark side: http://forums.ni.com/t5/LabVIEW/How-do-I-install-instrument-drivers-in-folders-other-than-inst/m-p/3036667#U3036667

The better solution would be to handle the value changes of those controls in the event structure.

The problem with locals is that they are only for inside of a single VI. If we are truely going wireless, the Global Variables are the way to go.

Duplicate thread in the NI forums: http://forums.ni.com/t5/LabVIEW/Is-the-compilation-done-differently-on-Linux-than-on-Windows/m-p/3000819#U3000819

Since you are talking about deterministic loops, they have to run at a certain rate. Therefore you will technically need a polling mechanism. What kind of data are you trying to transfer?

You have to have an NI DAQ card. Something like the USB-6009 would likely work for you.

The term "subVI" just screams that it is called by something. Would you rather call it "subroutine VI" (subVI for short )? I've never heard of there being a confusion with this term. I say educate those who are confused because by making up another term, you are going to just confuse the large majority who understand "subVI".

You must have edited the PNG file directly while leaving all of the header data alone. When I copied that snippet to a blank VI, that TRUE constant wired to the conditional terminal became a FALSE.

It was fun having her around. I'm glad to hear she had more fun than I thought. Yes, she must come next year.

Do you have some code you can share so we can see how you have your task setup? In general, a buffer overflow is cause simply by not reading the data fast enough while in a continuous acquisition or by setting the buffer size (which will always be less than the default buffer size).

Team up with Mark and do it. Just as long as you share your videos

Since it currently looks like I won't be there on Thursday, go for Fab's presentation on Unit Testing.

Was just trying to install a bunch of my favorite tools on a new computer last night. VIPM would not let me install the CCT because there was a conflict. Apparently, it conflicts with itself! VIPM 2014. Looking at my other systems who have upgraded to VIPM 2014 still has the CCT installed, but it is showing up as a conflict. Perhaps the conflicts with Code_Capture_Tool >= 0.0.1 should be removed from the package.

Because I can't use it in my executables.

The only bummer with this toolkit is that it requires a scripting node to get the picture's rectangle bounds. Maybe there's another property that could be used instead that doesn't require scripting?

Congratulations. Hope to see you at the CLA Summit.

Just quickly playing around with it, I like. I really like the linked thread feature where you can start a new thread based on a post. But we would never need that since we alway stay on topic...

You could use the Write To Spreadsheet File. You may have to play with the Transpose? input. Personally, I just use the Configure Streaming function to stream the data to a TDMS file. I makes things really simple.

I don't see why your UI loop would need to know the hardware state. If it doesn't get a message, it doesn't care. I find it is a lot better to keep things separated. Use the event to update your UI. Otherwise you will have to have your reading from the FPGA in the same VI as your UI to update your indicator. GUI VIs get large enough. I find it best to try to keep that as separate as you can. Even the large amount of data that I have passed around has yet to cause any issues.

I was going to suggest using the Elasped Time express VI and only read the SQL data when "Time Elaspsed" (use a case structure). As Tim_S stated, use a small wait then.