ShaunR

Thanks Priscilla I'm not really sure what you have in mind here. Maybe your current VBA application is sequential because the operations are indeed sequential (no point re-indexing a table before you delete a load of rows for example). I think generally speaking though, that any move away from VBA (and definitely away from Access ) will have performance benefits with the caveat that there are not many interfaces to Access that would be more efficient than the interface between VBA and the DB (I assume your using VBA within Access). With databases, just running more threads of the same process doesn't equal better performance (a thread will stall if a table is locked by another thread), but moving away would enable you to optimise your queries and give you greater control over those functions that can be executed simultaneously. Perhaps a better short-term route might be to look at Visual Basic since you will be able to more easily port existing code (CopyPasta with Hacksauce) whilst being able to assess what functions can be realised asynchronously. In addition, you will be running compiled code rather than interpreted (I think VBA is interpreted at least) and you will be able to see more easily how and where the software is idling; waiting for the database to complete. Many people just go for a text file with the SQL and squirt the SQL direct using PassThrough to bypass JET. The VBA becomes little more than a file reading function with a for loop and to change the queries you don't have to write any VBA. I have heard of significant performance improvements just by doing that alone. Indeed, you could very easily write something similar in LV (very quickly) and see if you can achieve better performance by doing a side-by-side comparison with a section of the existing VBA code. After all. You don't want to commit to a technology change only to find 2 months later after re-implementing that it's just as bad

The internal representation of a char (1 character of a string) is a byte. If you write the character "A" it s a byte of value 101 (decimal) or 41 (hex). So when you write A to the port you are in fact writing a byte of value $41. A string is an array of characters and therefore an array of bytes. So writing "ABC" you are actually write an array of bytes $41,$42,$43. You can easily convert to and from the representations by using using the "String To Byte Array" and "Byte Array To String" primitives in the string/array/path palette (under the strings palette). But you can only ever write read and write strings using the VISA functions;. Now. When you read (or write) "bytes" that are in the printable character range everything is fine. You will be able to type in values to string controls when writing and when you read it back you will see characters if you usea string indicator However. What if you want to write a hex byte of value 0?. Labview has a very easy way of doing this. If you right click on a string control (or indicator) you will see a menu option for "\" Codes Display and "Hex display. Setting the control/indicator to these will display the "string" in either the escaped format (e.g \00 \00) or in hex byte format (e.g 00 00). so unless you are going to do some function on the values of the bytes (like a CRC) then there is no need to convert and has the added bonus that you can use the string splitting functions to break up the data..

" Desktop/My Documents/My Pictures" isn't a real path. It's similar to a short-cut to a folder that changes with each user. To find what the real path is you can open "My Pictures" in explorer and right click on the address bar. Then choose. "Edit address". The address bar will then show you the absolute path which will be something like C:\Documents and Settings\user name\My Pictures (XP) or C:\users\user name\My Pictures (Win7/Vista).

Nope. I think you were right the first time. I no longer use the probe window preferring to slap indicators all over the place

Well. you are jumping 2 rather large technology areas.. It took me a week to figure out how to find the control panel and to turn off the User Access Control in windows 7 I've also always moaned about LV activation since I have to apply activation (for the 24 modules) manually. I'm sure once you are familiar with win7 you'll try again

Something like this.

I'm 100% with you here...ESPECIALLY the tree view..... - and my UI are "simple" (or they would/should be...lol). I went through a stage of writing front ends in another language and have only the backend IO and stuff in LV. I didn't find many downsides to this apart from my abhorrence to mixing languages. In fact I might play with it again but using TCPIP as the glue rather than DLL calls. Oooh. Epiphany This would mean the UI doesn't even have to be on the same machine

Only code monkeys need speed....for all the changes I want them to do I too like the new editors purely because you can import icons. It used to take me ages to try and make a new icon pixel-by-pixel...now I just import an image and (sometimes) make a box round it ...much quicker. Amen! Data-finder? What's that? Never used it. and If I ever decide to find out what it does I probably never will. NI device Monitor? I don't have any USB devices. NI PXI manager? Don't have a PXI rack., NI Motion Device Manager, NI WebServices.... et al. This is one of my pet peeves too. Along with the amount of coding that must be done just to make a UI work. Most projects I find nowadays are about 60% UI code and 40% real-stuff. The UI hasn't really changed much since the MAC original (in look and feel). No matter what you do. It always "looks" like LabVIEW. I think we would see many "new" looks if NI gave us access to the controls canvas and "onPaint" event..

Here's one from me then I wouldn't worry too much. If rep points could be taken away; I'm sure there'd be a minus sign in front of mine

You mean C++ ?

My version is set as you describe (yellow with a grey border for BD labels, LV 2009 and 10). My problem is that I can't remember how I did it an cannot change it back . But it is possible I'll have a play and see if I stumble across it again

I like the one in the red dress

I don't know how the JKI install works, but you are right. You only need to compile the hierarchy from the top level VI (which is what your VI tree is doing) rather than compile every VI.. I scan all VI's and see if they have any parents (lone VI's - these will be the top level VIs) then compile "Entire Hierarchy" only for those VIs and just save all the dependants. Opening a reference is quick, but compiling isn't. The advantage of this method is that you don't need a VI Tree VI (so it's more generic) and, for a couple of hundred VI's you only end up compiling a small subset and the compilation process is smart enough that shared VI's that are already compiled and/or saved are skipped (or so it seems) It's no really an issue in 2009 because it's all very quick. But 2010 is such a slug (installing SQLite API in 2009 takes about 20 seconds. In 2010 it's about 1 minute i.e 3x slower)

There's a few programmatic solutions on this thread

Check the ports in MAX. Labview gets its VISA information from it and it will have better diagnostics.

I've never used it....but a quick Google revealed that not only you have this (and similar) problems.

Version 1.3.1 released This is a purely a bug-fix release (addresses the bug reported by MarcA) and adds an installer. Upgrading to this version is optional..

Hmmm. I wasn't aware that mass compile skipped anything.It doesn't say anything about skipping in any logs when it comes across a password protected VI. Thats unfortunate. It means that a password protected VI is no more portable than a VI with the diagram removed. I had always thought of password protecting to be a better solution because having the diagram meant you could re-compile for different platforms/versions.

You could draw your own axis using the 2D picture plot functions (2D picture plot). The downside is you don't get all the zoom candy etc.

Indeed. But not really solution though. I'm hoping I'm just missing something obvious since the mass compile (and presumably the VIPM) can do it, however the mass compile only scans directories, rather than project trees.

How do you re-compile a password protected VI? I have a couple of VIs that are password protected, and a little tool that goes through a project, recompiles it and returns any errors and what they are (which then goes into a database) The mass compile copes with it no problem and simply compiling from 2009 to 2010 shouldn't be a security problem. But I can't find a way to do it. The open VI reference takes a password parameter so I presume you can't get a reference with that. And getting the reference from a project returns error 1040 (password protected) when the compile script node executes. Any ideas?

Deleted 'cos can't be bothered.

I would suggest replacing them in the palette (like the space constant '). I've been using my ones for over 10 years so it's not really a maintenance issue, I appreciate the thought, but really the primitives need to be changed.

+ 1 kudos. And while they're at it they can do the same with tick count, and wait next ms tick.