LuI

QUOTE(Lars915 @ Oct 5 2007, 07:49 AM) Lars, I'm a kind of a lonesome LabVIEW-fighter here, so my knowledge of Subversion-related LabVIEW usage is limited. But I use LabVIEW since v3.x and combine it with SVN for about a year now. What I do is to prefer single projects, even if a 'new' project heavily relates and is in fact derived (read 'copied') from an older one. I use tags to mark important keystones in a development process, for example when a proptotype has reached a functional status, when a new operation mode was introduced/replaced etc. or when a new version as a complete replacement of an old one is created. A branch instead is used when a new version is needed in parallel with an old one. And coming back to your multi-LV-versions setup, I'd probably prefer different versions of your libraries and drivers for each LV version. Takes a lot of extra space, on your hard disc as well as in SVN, but keeps independency between those versions. In my projects I had tried a kind of library tree (think of common sub-libraries), but this quickly turned into a whole mess during devellopment, as new relations and functions and modes turned up that did not really fit into the first library partition, so to say. This is probably a good case to start LOOP, but there is always too much to do _now_ as to try to switch ;-( As I said, thats just my limited view, but at this time it is the first reply to your posting ;-)) Greetings from Germany! -- Uwe

What are you thinking about stability and usefullness of LV8 against LV7.1.1? I have an Dev.Suite with auto-update, so LV8 is availabel. But my main job is a rather big existing project. During beta phase of and later with the final LV8 I did some tests updating parts of my app. Maybe I did not took enough time, but my impression was, it's not worth the hassles. So for the moment I'll stay with 7.1.1. Any hints/comments? Greetings from Germany! -- Uwe Frenz

Azazal, I can not imagine you could solve this problem with state-of-the-art HW. Have tested it on my fastest machine, a dual-opteron XPP. It took both CPUs with 100% and tokk not less than 740 ms - much slower than the requested real time imaging system. Even when taking two or four of the faster dual-core CPUs, the result was not below ~100 ms - neither a real time imaging system. BTW, your statement was not OK: 'I am currently acquiring about 8Ms of data,...'. What you provided was two 2D-arrays of each 4,096,000 elemets of Dbl, wich accounts to 8M*8Bytes. On a 32bit machine, this takes 16M CPU readings acesses at least. and is some ms alone for access of such large data sets. Reviewing your code, the only suggestion I can make is getting rid of those autoindexings at the right side of your loop. Replace it with 'replace array subset' on a predefined data buffer. This is called to 'work in line'. But this might just bring some smaller improvements, maybe a factor of 1.1 to 2. Much more important is to choose the right data type. Consider using Sgl instead of dbl. And make the control 'ensemble length x overlay' to an I32 to avoid the data conversion in the inner loop. This alone reduced the processing time to about 580ms on the above mentioned machine. Just my 0.02

Chrisdee, The error code does explain the diagnosed cause of your problem: "Can't open file : 'solcelledata.MYD'". This error was detected by the MS OLE DB Provider for ODBC Drivers when accessing [MySQL][ODBC 3.51 Driver][mysqld-3.23.38-log]. I was unable to find any specific explanation for errno 145. What you should do: * check for existance of 'solcelledata.MYD'. * check the access rights to that file * check if you/your app acn logg to mySQL and to the db If the original author is unable/unwilling to cooperate with you than you are off or you have to setup a new DB setting in order to use that program. That was -to say it mildly- bad behaviour of the original author. Greetings from Germany! -- Uwe

Mike, don't know about the way this was done, but Anthony Lukindo from Advanced Measurements Inc. published a solution java script:emoticon(':thumbup:', 'smid_27') smilie that acts as you asked for in LTR: "Simplified LabVIEW Database Access: A Single VI Solution for Connecting, Reading and Writing to Your Database" by Anthony Lukindo in LabVIEW Technical Resource, Volume 12, Number 3. As you probably know, LTR is gone now. I'd suggest contacting Anthony for this VI. If this does not work I could provide a wrapper around his VI that checks a global value to switch DB access on or off.

Hi all, have submitted this on info-labview, but would like to ask you as well. Here it goes: Although I am doing a one-man-show here, I am at the point now where a revision management system would be of significant help. So I'd like to do a short poll to the list for what revision control SW you use (if any), how you operate it and so on. I'm especially interested in the following Qs: 1. What system do you use, which version? 2. Can this system be integrated into LabVIEW or does it just handle complete VIs? 3. Does your configuration use a storage place on localhost or on a server, and if so, on a LAN or on the net? 4. Do you operate this with multi-user-setups? 5. Do other potential users/colleagues use different IDEs and compilers? 6. How much was it? 7. Any pitfalls/suggestions/infos? PLEASE RESPOND TO MY LOCAL ADDRESS uwe.frenz@getemed.de as I would like to summarize the responses. I'll summarize the -hopefully a lot of- answers within a relatively short period - say 1 or 2 weeks) and publish this here. Greetings from Germany!

Oh what a Q ! I started back with LV3 on WfW 3.11, more than 10 years ago. Did DAQ & analysis in biomedical research. Later some basic control of research equipment added. Now in my current job I use it to create helper tools (tests for medical devices, simulations, data transformations etc.), to devellop ATE projects for medical devices and do some special research projets in the medical area. The last bigger project was a 96 channel ECG recording device with ECG mapping calculations and display. This one measures and displays the time-course and movement of the excitement of the heart muscle in a non-invasive way. This allows to detect defects in the cardiac function.