Leaderboard

Howdy, I wrote OpenCLV (OpenCL for Labview) about a year ago and have decided to make it an Opensource project availible on GitHub. It contains all my C code to compile DLLs, all the Labview code, some pre-compiled x64 DLL code and a pre-built .vip project if you just want to download and install it. https://github.com/amcelroy/OpenCLV.git My email is in the GPL license header in the C code if you find any bugs or have any comments. Austin

Wrong. Your specification actually states: TDMS is not a "fully featured" database system. None of this is "easy" in LabVIEW. 1. LabVIEW doesn't support QR codes. There are some threads on this forum for some 3rd party solutions 2. You will not find an "off the shelf" solution as this is a specific requirement that many would outsource - you will have to write it.. 3. If you have the Database Connectivity Toolkit - use that (you probably do as you are a student). 4. If you don't have the Database Connectivity Toolkit - use SQLite. 5. You will have to learn SQL.

I've been working some more on my LabVIEW object serialization library. I wanted to fix the problem of double precision numbers. The standard LabVIEW function for translating double to string does not produce numbers that are bitwise recoverable unless you specify a precision of 17 for all values, meaning a lot of junk in the file. LabVIEW uses the standard C printf function under the hood -- the problems LV has are the same problems most other languages have. I figured someone must have found a way to fix this. Oh, boy, did I stumble into gold. In 2010, a grad student, one Florian Loitsch, not only published an algorithm that does this, it is 5x faster for 99.5% of double values than the standard algorithm. It was the first improvement in the algorithm speed in over 20 years. And just last month, he published the code for a further speed improvement. Here's an article about the improvement. This author found a 10x speed improvement in his JSON library. That's exactly what I want to hear. It's hard to find, so here's the link to the actual C code source for this algorithm. I am going to investigate dropping this code into LabVIEW for 2015. I looked a long while at implementing the C code in G. It's doable, but it isn't small at all, so I'd rather just upgrade LV using his C code than try to recode it. Less error prone and it floats all boats, not just my library.

Normally, something like this would imply a memory leak. Use task manager to monitor your memory usage over a couple of hours; is it gradually increasing? Are you opening a reference repeatedly and not closing it? This can easily happened with "named queues" if you're not careful.

Son, I can't teach you all of programming. You need to step back and read some tutorials (and probably entire books). Here's a start: http://sql.learncodethehardway.org/

Probe the path wire going into the New Report.vi when the VI is ran. You'll see that the path provided as a xls template is a path to a location that doesn't exist. Your XLS file is in the same directory as your Main.vi but you stripped the path twice meaning the folder above where the main is. Remove one of the strip paths to fix that then if you have the report generation toolkit installed it will open excel and make your spreadsheet. It doesn't get saved because you didn't use the Save Report to File. Call this before the Dispose Report. EDIT: Cross post http://forums.ni.com/t5/LabVIEW/Error-7-with-Report-Generation-Toolkit/td-p/2695725