ShaunR

TDS3054B

I you know the maths then use a formula node. There is an example of using the formula node shipped with Labiew.

If it is false only the reference you wire to it will be closed. If it is the last reference, the queue is also destroyed regardless if you set it to true or false.What can happen is that you get "intermittent" failures if you don't get the close exactly right. Since one part of your code may close the last ref just before another part tries to dequeue/enqueue etc.. Then a loop that obtains a reference comes around again an re-creates it but you cannot track down where the error is coming from.

Funny you should say that. Downland 1.1 I've just posted above. Using the benchmark (supplied in the update) Insert ~350ms Select ~90ms The initial release was really for me to get acquainted with SQLite map out the feature list. I'm thinking I maybe able to shave off a few more ms in the next release. Its a shame the"convenience" functions are unavailable to us Indeed. That's the next feature that I will be implementing and I was also thinking that would improve the insert speed. Good feedback. Not having other (working) implementations to compare against, I really need this kind of input. What are you running Win x64? LVx64? I don' t suppose you happen to have am RT Pharlap target?

Awwww. Don't feel bad. I found the info really easily

You can also use "BringWindowToTop" which will not set it as a top level window but will bring it to the top of the Z-Order.

Very disabling

I've been bitten by this before too.Now I use this vi. It ensures there is only ever 1 reference to a queue, you don't need thousands of wires all over your diagram and you can easily access queues from other VIs.

I hope that not the case with my cars ECU Indeed. I don't know here to start with this statement. Of the 161 known issues in LV2010, 125 are from previous versions (~78% if I've counted correctly). Rumour? Should I run for cover now?

They're not bugs. they're "unpublished features"

Same as 2009 known issues....same as 8.6 known issues..same as.....

Go into the VISA settings and look at the conflict manager..You can force certain visa drivers onto individual com ports.

What about an RSS feed? Then you know when there's a new idea and can go straight to the interesting ones.

The first error it came up with (with what you described) was here. Check that path exists. I changed if the "c:\ftpscript.txt" and no longer got the file error (obviously). However, it then complained about this one (again doesn't exist...but then it probably wouldn't on my machine) By adding an error out indicator Labview will no longer automatically handle the error. But you really need to think about your error handling because currently the software is not robust and I can see you spending the next 2 weeks creating directories that the software thinks should be there..

No .1. Labview is a niche.Mainly due to its proprietary nature, targeted at test and automation and, of course, price.

If its a waveform you can use the "Array To Spreadsheet.vi" and store it as a comma delimited string. Or even each separate value with a time stamp in its own table.

As I've said before. the Events in LV need an overhaul. There are lots of available events that we should be able to hook into. We have an event for when a VI is activated, why not when it exits, or is loaded, minimized, maximized etc?

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.

IC. Well that explains the recursion issue you are seeing. Prior to LV9.0 recursion was only supported by opening a ref and using a call vi node. But its nice to know with a bit of hacking it can work on older LV versions......even Linux . I presume (since you haven't mentioned any so far) that there are no issues in your windows LV 9?

It's an in-built definition the same as "TARGET_TYPE". I'm a bit stumped as to why LV9.0 on Linux cannot support recursive VI's when Windows x64 and x32 don't seem to have an issue. You could remove them from the polymorphic table VI and add them separately to your palette since it seems it's the polymorphic instance that is causing the problem. Unfortunately, Linux documentation a is bit lacking. I have several VMWare Linux images, but was unable to find a downloadable trial version of LV9.0 for Linux, otherwise I would have tried it. The NI website only has windows and Mac. If you go to their Linux download section you only get a windows EXE installer although it says its for all OSs .

I believe TARGET_BITNESS was first introduced in LV 8.6. Do you have any difficulties in LV 9?

Swwet. I did include aLinux x32 library but didn't advertise the fact because it was untested. I'm surprised by this. What said it? Those two function are actually a trick. They just use SQL to copy the data to another table, delete then recreate the original and copy all the data back. SQLite doesn't have delete or rename columns function, but it is needed. To get this error, one of the other VIs would have to include it. Do you have an example use that shows this error? OS and bitness are only available from within a Project. But Target Type is available all the time. Did you open them from within a project? Or just stand-alone VIs? Try adding them to a project. The problem is that linux, like windows, also has x32 and x64. We need the bitness to choose the appropriately compiled DLL. The choice of whether to use OS or Target Type was arbitrary. They both support the same things (more or less). I leaned towards OS because that is the one that NI use in their example.

You can save the cluster as a "Blob" (Binary Large Object). Although I'm not sure what you mean by "binary text" You wouldn't have to save the object data piecemeal style But databases are built for this kind of stuff and I think that if you went down this path you would see major benefits to saving each piece of the cluster as a separate field. Performance is pretty good if the DB resides on the same machine as the application. You could also look at "SQLite API". This release doesn't support "Blobs", but you could serialize the data using the flatten to string primitive.