jzoller

Depending on your situation, you might also try "INSERT IGNORE INTO..."

See http://stackoverflow...exists-in-mysql

Joe Z.

...

To answer the OP, if we couldn't use LV anymore I'd probably switch over to C#.

Same here: C#

[soapbox]

The language used isn't all that important, really. It's just a tool.

As an analogy, the knowledge of how to build a house is much more important, and harder to acquire, than the ability to use a table saw.

In the same way, the knowledge of how to build a functioning system that includes software is more important than the tools you use.

[/soapbox]

Sorry, it leaked out.

Joe Z.

You can also parse them out of the executable, since they're stored amongst the binary in clear (if messy) text.

Joe Z.

Can you use just generic control references for controls/indicators, and calls to To More Specific Class inside of each vi with a specific type?

If To More Specific Class errors, the cast is invalid, and you can behave appropriately.

Just a (possibly fever induced) thought... a quick and dirty sample seemed to work for me.

Joe Z.

Can anyone give me a rough idea of the relative expected performance of the following interfaces:

RS232, RS485, RS422, Ethernet, USB (a direct USB rather than one of the others with a USB converter).

NI's put together a nice set of charts on it:

http://zone.ni.com/devzone/cda/tut/p/id/7278

Joe Z.

You probably only need to take them out of the polymorphic VI. Rename column calls delete column and they are both in the table polymorphic vi.

What sort of glitch?

-1 is much safer since if you supply a normal Labview string, you would have to add 1, however, if you supplied a null terminated string, you mustn't add the 1.The logic involved in detecting null chars outweighs any performance improvements you may get. If its better performance you are after, you'll have to wait for Version 1.1

However. If you are trying to insert a null char into the database. You will have problems since c strings are null terminated, So when you pass the string (even with the length) Labview needs to convert it from a Labview string (which has a length that may have leading nulls) to a C string and this conversion will invariably truncate your string.

Usually the way forward in the latter case is to use a "Blob" field but I haven't implemented that in this release.

The error is a code 1, "SQL Error or missing database".

Unfortunately, the Flatten To String function in LV returns a fair number of null chars when you feed it, for instance, a waveform. Escaped null chars don't seem to have the issue, so I might give that a try.

Thanks again,

Joe Z.

Fun stuff, thanks Shaun!

It's worth noting that attempting to write a raw "\00" causes a glitch in the low level prepare (that calls sqlite3_prepare_v2) vi. I'm guessing it's due to:

If the nByte argument is less than zero, then zSql is read up to the first zero terminator. If nByte is non-negative, then it is the maximum number of bytes read from zSql. When nByte is non-negative, the zSql string ends at either the first '\000' or '\u0000' character or the nByte-th byte, whichever comes first. If the caller knows that the supplied string is nul-terminated, then there is a small performance advantage to be gained by passing an nByte parameter that is equal to the number of bytes in the input string including the nul-terminator bytes.

The statement size is wired as a -1 by default. I'm tinkering with different sizes now, but would take any ideas out there.

Thanks,

Joe Z.

Still trying to wrap my brain around if this could be done more intelligently by applying binary type searching rather than indexing, but I think I'm satisfied enough for now.

I think you can get to O(m log n) with this using a binary search. (NI's binary search vi's are here.)

Sort and binary search are (most likely) O(log n), and the for loop is O(m). Of course, this doesn't catch duplicates, and NaN's can make it a little cross-eyed.

Joe Z.

Edit: Come to think of it, you don't actually need to sort your smaller array.

I think to some extent, yes we are walled off. I'm pretty ignorant of non NI hardware. To some extent it's intentional. My time is way to valuable to spend tackling the latest low-cost, low-support, low-functionality, low-extensibility system from some other vendor. I buy and work with NI because their hardware just works (usually). For me its an investment in a platform that is proven, stable, and reliable, with good support for both hardware and software.

This.

This is a really nice convenience, thanks!

Joe Z.

<--- Architect.

(Despite my misgivings about certification programs, I *did* learn a bit in studying for the test).

Thanks to all for so much help over the years,

Joe Z.

??? where do you see a sixteen element queue?

Or are you talking about the data structure of the AMC?

Sorry, poor phrasing. It's my besetting sin.

Yep, it's the data structure of the AMC. I had initially assumed it was something a little less sophisticated than a queue tracking system.

Joe Z.

...what do you see as not necessary?...

It depends on the use case. I prefer YAGNI over the "everything always available" option.

I'll probably throw together a sample with your system, though. It's intriguing.

A more detailed question: Why a sixteen element queue?

Thanks,

Joe Z.

Please post your 'Why did you do that?' questions and I'll gladly inform and instruct why the design choices were made (including why did I use colors)

Okay, I'll be a downer...

Why would you use this over something much simpler?

Joe Z.

Useful *and* fun.

Joe Z.

I found the App::Linker.Read Info From File method. I don't understand everything that it returns, but I think all I need are the file paths so it seems to be working great.

Just a note: read the help on the Linker.Read Info From File if your project includes LVOOP.

Joe Z.

No vendors (sorry), but just remember to check your card voltage requirements...

From Wikipedia:

Originally the PCI bus was a 5-volt bus. Later, in PCI Revision 2.x, the PCI bus was a dual-voltage interconnect. In 3.0 this was changed to 3.3 volts only.

Joe Z.

Is it all VI's and projects? Or just certain (large) ones?

Joe Z.

Edit: clarification

Heathen

It's so true...

Anyone have a chance to play with this, yet?

I admit, I have zoom envy...

Joe Z.

Possible, yes. Easy... hrm.

The "right" way probably involves writing something using .NET reflection to look at the assembly. From there, you could build the structure as a cluster using LV's scripting interface.

The, ah, cheap and dirty way probably involves using Redgate's Reflector in command line mode, outputting to a file, and parsing the file for the structure info. You're still going to need to use scripting, though.

Overall, it would be very time consuming over just manually doing the work.

Joe Z.

On further reflection, you could skip scripting by just using a variant dictionary, map, associative array, or other generic storage.

Joe Z.

Possible, yes. Easy... hrm.

The "right" way probably involves writing something using .NET reflection to look at the assembly. From there, you could build the structure as a cluster using LV's scripting interface.

The, ah, cheap and dirty way probably involves using Redgate's Reflector in command line mode, outputting to a file, and parsing the file for the structure info. You're still going to need to use scripting, though.

Overall, it would be very time consuming over just manually doing the work.

Joe Z.

Really cool, thanks!

Joe Z.

Hi all,

I want to be able to extract the text from PDFs from within LV. I thought this might be a common requirement but searching for "PDF" here returns nil, and Googling fairs little better. I've discovered that extracting text from a PDF is probably not easy in any language: the text seems to be contained in a very heavily encoded data stream. I doubt I could write an LV algorithm that could do the extraction well (or even badly, for that matter). My thoughts turn to interfacing with an existent DLL. Numerous PDF to text DLLs exist on the Web but I don't know C and its variants so don't really understand DLLs, to be honest.

A compay called Softinterface seem the most likely key to success. They've got some good stuff. I've had a play with some of their DLLs and the LV Import Library wizard which created some VIs but I couldn't get them to do anything (oddly, the header file for the DLL only defined very few of the functions that the DLL appeared to support).

I eventually got something going via the afore mentioned comapany's product ConvertDoc. This is a PDF to text GUI application that has a command line. So, I send the command line paramaters to it via the System Exec VI calling the cmd console. It extracts the text from the PDF and writes it to a text file (not surprisingly). LV then reads the text file and does what I want with the text.

So, I can do it but only with the clunkiest of methods. Can anyone point me in the direction of a slicker method of extracting the text from a PDF? Many thanks in anticipation.

Regards, Graeme.

How about pdftotext, from the xpdf tools?

http://en.wikipedia.org/wiki/Pdftotext

I haven't done this, but a command line invocation doesn't seem unreasonable... though I suspect it depends on the complexity of the pdf document you're looking at.

Joe Z.