Shaun Hayward

Hell yeah! It's currently way too much of a pain in the butt!

and now to further neBulus's post... A technique I used to aid the distribution of the drivers was to create a build for each class (and all its subVIs, but specifically excluding the base class VIs) to create a LLB. I then put all of these LLBs in a drivers folder and used the LabVIEW list folder VI look look recursively into that folder to find all of the lvclass files (there is an input that can be used to tell LabVIEW to treat LLBs as folders). This way, one ends up with a neat distribution solution (ie all of the LV stuuff is in one "driver" file)

Its also worth knowing that C:\Documents and Settings\All Users\Application Data is a hidden folder so you will need to either have Windows set up to show hidden folders, or navigate straight there using Start->Run... or by typing the path into an Explorer address bar (I'm not sure if the explorer address bar is visible by default or not either) Shaun

Are there advantages with this method (creating tasks in the project) over creating tasks at runtime using the DAQmx VIs?

One thing that you may want to look out for is that arrays need to be in a contiguous memory block - that is Windows needs to not only have enough spare memory in total, but it must all be in one place. This caught me out in the past - I needed a large 3D array and although the machine I was working on had 4Gb of RAM, the largest array I could allocate in LabVIEW was about 300Mb. I know these numbers are much higher than you have suggested, but its still something to watch out for (especially if you are on a system with a smaller amount of RAM and/or lots of programs open). Shaun

LabVIEW is capable of using a standard RS232 communications port with any RS232 device. As it sounds like you are trying to create your own custom device (which is less of a LabVIEW issue and more of a hardware design issue), and despite many developers here possibly having experience with microcontrolers and board design, you may be better of posting on hardware forum such as http://forum.microchip.com/ (for PIC controllers). Shaun

You could try using an invisible tab control (using the color tool to set a tab control's color to transparent after you've placed it on the front panel, and hiding the tabs themselves) Having placed that, you could then use the tree control events to programmatically change the tab control's page.

QUOTE (goran @ Nov 14 2008, 06:59 AM) There were a couple of things: 1. When calling a Win32 function, you need to ensure that you are using the "stdcall (WINAPI)" Calling Convention - that makes the function node work 2. When casting an integer to an ENUM you need to make sure that the ENUM and the integer are the same type (ie I32/U32/U16/etc). Here's an updated version in LV 7.1

Depending on how many (and how complex) the commands you want to use are, you may be able to use LabVIEW's built in RS232 functions (VISA Serial Read/Write) to send the commands directly to the motor without using the company's DLL. In the past, for simple applications, I have found this considerably easier than battling with not-so-well documented 3rd party DLLs. Shaun

QUOTE (goran @ Nov 13 2008, 07:44 AM) I dont have LabVIEW 7.1 to hand right now (and cant remember whether .net support was in that version) but a simple .NET call can be used to find out what drives are on a system, whether they are fixed, removable, or CD-ROM, and what their volume name and drive letters are (there are also many more properties). I've attached a picture of what the code could look like.

QUOTE (Sonic_Soul @ Oct 21 2008, 03:22 PM) You can get around the need to supply a fixed path by using the File Dialog express VI from the File IO -> Adv File Funcs pallet. This function will cause a file popup and will output a file path which you can then wire to the IMAQ Write File 2.vi Shaun

It seems we may be getting to the bottom of this one - what appears to be happening is everytime PushOK & LabVIEW touch a file in a repository it seems to set the svn:needs-lock property on that particular file (which is why we found it hard to trouble shoot - on our test systems we ended up with some files read-only and some not). ...now time for the whole "should we enforce locking or automatically clear any svn:needs-lock properties " debate... Thanks for all your inputs! Shaun

QUOTE (jcarmody @ Sep 26 2008, 05:32 AM) Jim, Thanks for the hint - I hadn't come across SQLite before - it looks like its doing much of the same kind of thing My only question is that the link you posted does not seem to have anywhere to actually download the toolkit - am I missing something?

I havent looked into it yet (due to time constraints) but SQL Compact Edition looks interesting. From what I have read so far (which isn't so much) it seems that it embeds a database within a particular applicatio. Therefore I would wonder whether you need to do some calls to its DLL / .Net trickery instead of a conventional UDL approach. The MSDN pages are suitably cryptic and basically talk you though using a Wizard in Visual Studio, which doesnt help so much.

I've been thinking and experimenting a lot with source control lately and one thing that has come up is that TortoiseSVN seems automatically set a file to read-only after it has been committed, meaning that before you re-edit the file you must unset the read-only status. Admittedly this is not a particularly hard task, but has anyone come up with a simple method for avoiding having to do the whole unset read-only thing after every commit? Thanks, Shaun PS. As a side note - as there seem to be more and more people using source control with LabVIEW, and with it comes a whole bunch of issues, is it worth a separate forum for source code control / project management type things in LAVA?

Thanks to everyone for such useful input on this thread - It definately seems that there is no hard and fast advantage of one method over the other, but many good talking points have been raised. We have our next planning meeting mid October so I'll be sure to let you all know what (and why) we end up going with Shaun

QUOTE (JiMM @ Sep 19 2008, 06:59 PM) From the land of Kent, but before heading over the Atlantic I was rotating around London - going to University in Guildford, Surrey and then working in St Albans, Hertfordshire

QUOTE (crelf @ Sep 19 2008, 05:37 PM) yeah, its hard to find out what would be the best as I think in reality they all could work, although we have decided that the ability to a customers earlier project to form the basis of a new project is too valuable to have 1 repo per project. What do you do?

QUOTE (jdunham @ Sep 19 2008, 02:10 PM) ...that's what they always say... :ninja: ...seriously though, I guess it was more a question of does the system cope with very high numbers of revisions, or does it start to break down at a certain point, but looking at yours and PJM's answers, I'm getting the feeling that it is not a problem QUOTE (jdunham @ Sep 19 2008, 02:10 PM) I think it would be a disaster to try to maintain separate SVN repositories at different locations if they shared data. With all the time that you will waste, it would be better to invest in more network bandwidth. Also remember you are not on the network all the time. You only really hit the network a few times per day, and SVN's deltas make network transfers very efficient. Thats a good point, I'll have to talk to the upper echelon's about their current plan with the servers... QUOTE (jdunham @ Sep 19 2008, 02:10 PM) You might want to think about separate repositories for each customer in case there are issues with customer proprietary data, since it would be easy to archive a project and remove it from your server some time after the contract ends. But I would still run them all on the same server machine. However, Philippe is right that everything will probably be easier in a single repo. I'm with you - no matter what level the repo's were going to be at, we were definitely going to put them on the same server (whether site dependant or not) - and I had not considered the ease of archive possibilities, thats a definate + for repos per customer. QUOTE (jdunham @ Sep 19 2008, 02:10 PM) Overall, I wouldn't worry abou the reliability/scalability issues. Your team is much smaller than many others which are successfully using SVN. Good luck. Thanks

Thanks for such a prompt reply! and thank you for the welcome The reason we wanted to keep the servers for the different sites is that we do not have the speediest connections between sites, and therefore when you are in your home office, you would be able access the repositories at the full speed of the local network, regardless of whether your office is the HQ. Also, as far as concurrent users go, we a little over 20 engineers right now (and are trying to find more) so we would want something that is scalable for the future. I know that pallets are good way for reusable VIs, but in this instance we were more thinking about application / system frameworks - we have the same basic software package on several systems and just pick and choose the modules that are appropriate before customizing it to suit the individual customer. Have you ever had any reliability issues with svn? (especially with the all-eggs-in-one-basketrepository approach)? QUOTE (PJM_labview @ Sep 19 2008, 01:06 PM)

QUOTE (Mikrobi @ Sep 11 2008, 05:11 AM) Thanks for your suggestion - Excel seemed to be working fine and other programs were accessing it through the various plug in interfaces (We also had the app working fine on XP and Vista systems with Excel 2003 and 2007 so it seems to not be the LV code). In the end, he seems to have found that installing a combination of SP3, and reinstalling everything seems to have worked (we're currently fine tuning what exactly was the right combination/order of installing SP3, Excel, Goldmine and our software that worked)

Hi All, Originally from the UK, but now living in New York City and working in Fort Lee, NJ, I have been using LabVIEW seriously as my day job for the last year (and probably a lurker here for the last 6 months). After going to NI Week this year, I have been promising to myself, (and trying ) to play a more active roll with the wider LabVIEW community! With the last year I have progressed from playing with LabVIEW as a tool with applications of less than 20 VIs, to developing systems with over 1000 (all be it, there was a team of us on that one) and, with a bit of luck, soon I will be a CLA (I took the exam on Tuesday)! Nice to meet you all! Shaun

If you register on the website you can download a pdf of the first chapter which will probably give you an idea of the style of The Style book (which might help you decide if its the right book for you)

Hi All, I know that a lot of you guys here are already using svn with LabVIEW, and I am currently in the process of trying to sort out a company wide roll out. We are an integration company with 3 geographical locations (and are planning on having a server in each). However, we are trying to work out whether each server should have, for example, a separate repository for each customer we work with, or one single repository per site. Amount the many thoughts we had were the following (and these are all maybes): * having one per site could facilitate reusable components (ie a previous project carried out with a different customer could be branched) and make updating reusable components with applications easier * having one per site could be more risky in terms of corruption (although backups will be made) * Would there be any performance hit of having everyone working on the same repository (and would the associated large revision numbers be a problem) * Are there any other issued affecting one system or the other that could be relevant? How do you all split up your repositories? and do you have any feed back on our thoughts? Any help is greatly appreciated, Shaun

Hi, I wondered if any of you can help me as I'm at a bit of a loss. I have an application that is complied to exe, and installed with an installer in LV 8.5.1 that uses the Excel ActiveX interface to write to an xls file. In development and on all of my testing this seems to work fine (with Excel 03 and 07) but I have just received a bug report whereby on a particular install the following error has been thrown form my Open Excel VI (see attached code). Apparently it was working but this machine has recently upgraded some data management software (Goldmine 6.0 -> 7.5) and since then it hasn't worked. Troubleshooting is complicated a little as this is running as an exe and the source code seems to work fine on my development machine. Any ideas would be GREATLY appriciated! (my current inclination is to ask the customer to resintall Office and Goldmine and then reinstall the LV app - so far he has only tried reinstalling the LV software) Shaun EDIT: I forgot to actually include the full error details Error code:-2147319779 source: "Library not registered."