JamesMc86

Hi, This was actually released with LabVIEW 2010. The product page is at http://sine.ni.com/nips/cds/view/p/lang/en/nid/209015 Cheers, James (null)

Now I have managed to look at the video properly on my laptop it appears he is not referring to that board but a Xilinx board called the Spartan 3E XUP (Xilinx University Program). There is an old thread discussing this at http://lavag.org/topic/10838-spartan-3e-fpga-board/ but the long and short is that it is a board from Xilinx for academics and we have written a driver for it, but you have to agree to be using it for academic purposes. The page describing this is at http://digital.ni.com/express.nsf/bycode/spartan3e and there is some training material for it available at http://zone.ni.com/devzone/cda/tut/p/id/6848 if you take the plunge! Cheers, James

I think in the video he is probably referring to the academic top board at http://sine.ni.com/nips/cds/view/p/lang/en/nid/207010. The is no way to generate the VHDL for non NI targets from LabVIEW FPGA. Tge top board may work for you. Have a look through the manual but I believe you could power and use it without the ELVIS. You can also target this using Xilinx ISE and by drawing digital schematics in Multisim (requires particular versions of ISE to script but it's pretty cool! The next cheapest way onto the platform would be the single board RIO eval kit. It has recently dropped in price and included 180 days of FPGA and RT. Hope this helps!

Hi, Thanks for the point about the data buffers. I had not experimented much with the buffering but it certainly does improve the situation (I will upload a comparison to the NI community shortly) EDIT: If you want to see the effect of buffers I have now uploaded code to https://decibel.ni.com/content/docs/DOC-20522 I think this discussion sums up that the whole decision comes down to the fact it is going to depend where you want the data to end up. TDMS is easiest the NI ecosystem although I have had people impressed with the way the data is pulled into excel (theres also a plugin for open office) and the C dll does allow it to be added to custom applications (including Matlab). If you need the data to work with notepad or another specific program then you have to stick to with an ASCII format or a custom binary format that the program supports. Where I would say TDMS is a must is when your talking big sizes. With the advanced API you can actually write to disk faster than with the standard binary VIs and dealing with large files requires the random access available in the API or with DIAdem's ability with large data sets.

Hi Alex, This is expected behaviour. LabVIEW does not identify the subject of a dynamic call as a dependency because this could change by you changing the path. The same is the case on Windows but this is not so much of an issue because all the files are on your local system anyway but on RT they have to be deployed down. Not sure if there might be an easier way but you could whip up a VI that uses the project API to programmatically deploy the VIs in one hit to make your life a little simpler. I haven't used a huge amount of dynamic VIs on RT so there may be a better way. (See Mads last paragraph as well). Cheers, James

Hey Guys, Thanks for your advice. I have been looking through the properties I have in the project API and it does appear I can get all of the callers/subVIs through that so I can remove those arrays. I will still use OOP for dynamic dispatching but it will like be a wrapper for the existing objects. (null)

Just one bit to add. The method you have described with the exe is great. But just FTP often wont work because the VI is compiled for Windows. You should use a source distribution to move VIs to the target as this will recompile them for the target. Cheers, James (null)

The reason I was looking at by ref is to make sure I have one object with all the information before generating the page. Part of the issue with the original code was it got complicated editing the existing pages. I figured it will easy easier to generate the whole page at once. I suspect you may be right though that a I could be missing a simpler method! (null)

I have been working on some basic experimentation with OOP and want to apply it to a project that I have wanted to do for a while. At university I created a VI that would traverse a LabVIEW project, print a HTML page for each subVI etc. and then create a home page and link the pages together. It worked quite nicely but when I started to look at additional features or customisation I knew that it was not scalable enough and I would treat that as a prototype and start from scratch. That was 2 years ago now and I am finally looking at it again! I thought back then that OOP is going to be the best way to approach this and it's a good chance for me to write a largish OOP application (I have used bits before and understand practicalities but not some of the higher level design priniciples). Attached is an initial class diagram which is currently fairly simple. The basic idea is: The project class to generate my ProjectItem classes (This will be the parent class for various item types). It will generate these as references (I want to only generate a single page for each project item) and store them in a dictionary. For this I have been told that variant attributes are actually highly optimised. I will use scripting or similar to find each items subitems (e.g. SubVIs) and generate an array of these references. As each subitem is found it will identify itself as a caller to that subitem. Then I just have to generate the pages... My thoughts are that each project item will have an array of DVRs to it's callers and one for it's subitems so that any methods for generating pages should have all the information they need. This however is naughty according to LVOOP as it is a recursive type. I see 2 potential ways around this: The children of project items contain their own arrays of DVRs to project items. I believe this is allowed however it seems like I will then be repeating functionality accross these child classes. I can "override" LabVIEW and cast the DVRs to I32 or similar and do it how I want. The thing is in my experience that LV has often known better and when I have forced it to do something like that it has come back to bite me in the arse! Having just been doing a bit of reading, there may be a 3rd. Is this a case for some sort of delegation pattern? I would be interested if anyone had any suggestions for best practice on this or whether there is another option that I am missing. I have just thought of a 4th possibility would be rather than using the arrays of objects and dictionary would be to use a database implementation instead but that feels like overkill for this.

I think all the points above are great. I always get a good reaction when showing it to customers and the excel importer can produce easier data to go though that your own text files. One thing to just be aware of with it is fragmentation. It's a common problem that we see, esp. on embedded platforms where file size is more sensitive. There is a white paper describing the exact implementation but the short version is that each time you use TDMS Write a "chunk" of data is written to file (Im not sure if this is the proper term). If that chunk matches the previous (same channels, datatype, I think size) then it is written just as binary data and maintains the efficiencies. If it does not match then it writes a new piece of XML header data with the data, which is very inefficient. The result is if you mix the reads to a single file your XML header becomes huge, as does your file and your access becomes slow. The solution is to try and keep to a single write function to stream to disk. If it is unavoidable then there is a TDMS defrag function which will then reduce the size again but this can take some time and CPU. Don't misunderstand me though, this is the main caveat you could run into but overall the benefits outweigh this (and it is avoidable as long as you know it exists!) you do get extremely compact, searchable data that can be easily shared. To get similar write performance you would have to go to a binary format which means the end user will need a program capable of reading that. Cheers, James

Hi Hugo, Nice tool! I have done some work on a similar function for my department but I bottled out a bit on proper right-click integration and just put a shortcut in the send to... menu. What did you find the best way of customising the right click menu was? Cheers, James

To echo what has been said a bit, using serially directly or through a USB converter shouldn't really impact much other than USB is more widely available. There are hundreds of converters out there, functionally I am not sure if there would be a key advantage to using NIs but it is going to be a higher quality than a cheap converter off eBay! The USB instrument is an interesting point. My experience when you have this choice is that the manufacturer has simply built the converter in. This is the case where it gives you a virtual COM port in which case there is no reason not to go with that. What I wanted to add is that if it is not a virtual COM port, I would avoid at all cost! VISA USB programming is more difficult than serial. EDIT: Unless it conforms to USB test and measurement class Cheers, James (null)

Hi Val, Official LabVIEW for Linux support is currently limited to 3 distros (although unofficially I am aware people have managed to run on many more). The key distros targeted are Red Hat and SUSE but support for Scientific Linux has increased in the past few versions. The full support table for Linux is at http://digital.ni.com/public.nsf/allkb/4857A755082E9E228625778900709661?OpenDocument. From my experience I have tended to come across more people using Red Hat but I think this is an enterprise thing rather than any technical reasoning. Cheers, James Mac

Another technique for this (but only in 2010 onwards) is network streams. They suit the command model well although the disadvantage is they are 1:1 like TCP so can require an element of connection management. (null)

Could you implement a UDP heartbeat instead? Have the mute controller send hb to a port on the other controller. If it times out waiting for it then the other controller is off/down. This would be a typical alternative to ping and confirms not only that the controller is on but that it is running. (null)

Hi Mike, If your time critical code is running at 65% it is possible that it is the CPU requirements of the engine that is causing the issue. What is your total usage? Ideally we would aim for about 80%and the engine can take quite a lot. http://zone.ni.com/devzone/cda/tut/p/id/4679 I don't think it has much useful now but I always refer to this document for a quick overview of how it works. What might be worth doing is using RT FIFOs on your variables if your cluster supports it. It will ensure you time critical code is not affected. (null)