ShaunR

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.

I gave you the answer to to that in my first post. (You can press continue by the way). Check the VI properties of all your VIs and make sure this is unchecked.

Others might say you have a life

Looks like a move to a database is in order if you are shifting that much info around. Is MySQL or Access a viable option?

OK. I get it. couple of things to look at. 1. What is the 100823? If it is system time (like in excel etc) I'd expect that to be 40413 for 23/08/2010. Whereas 100823 would be 15/01/2176. 2. From your images. You show 100823 with no directories afterwards. Then you show after the roll-over 2 extra directories (albeit without the 100824). Could it be that the data you are expecting in 100824 is in fact in one of these and your program has skipped when saving for this particular date? 3. Is this the only date it happens on? Does the software quite happily save as you expect but on this particular date it doesn't? You show many directories previously and after the 100824. 4. Looking over the history of results. there are many "gaps" in the data record 100722 suddenly jumps to 100820 (98 days?) , 100531 suddenly skips to 100601 (70 days?) etc. What is the reason a file wasn't saved between those periods? Could it be a case that you just didn't receive any data therefore there was nothing to save?

You need an excuse? I thought it was our nature to play with this sort of stuff Keep it in your palette and I'm sure you'll think of something.

If you mean when there is an error condition you are getting an error dialogue when you shouldn't be, then you probably have an unwired error out cluster (or none at all) and "Enable Automatic Error Handling" is set in the offending vis "Execution" properties.

Possibly. This release basically does a "GetRow" and has to iterate for each row. There is another method, but it isn't implemented yet. (Still trying to figure out how to do it....if it is possible in LV). Do you have a real-time target that uses ETS?