Jack Kelledes

I currently have a VI that controls the discharge of a battery cell via several GPIB devices. These devices need to be fairly well timed for everything to work right and the discharge to be successful. I also need to acquire 15 seconds of data during the discharge like cell voltage and current and a few other voltage readings. I currently use an external device to acquire the data and wish to switch to a PCI-6143 card that happens to be installed in the computer I'm using. I have never actually used a card for data acquisition. I've always used a secondary external device. I can set up the card to get all the data I need, that is not the problem. The problem is that I cannot figure out how to integrate the data acquisition into my VI and get it to run correctly. Currently if I start the 6143 acquiring its data my VI waits until it has it all before continuing on to the next frame. Is there a way to trigger this thing in one frame and then continue on with the rest of my VI while it's recording the data?

Sorry it took so long to post back but the LabVIEW .ini key does the trick! I sure wish there was more written on what you can put in that .ini file. The problem with this software was I didn't write most of it, just modified some parts to work with a slightly different configuration than the original software. Whoever wrote it initially took the long way around (looks like they just experimented until they got it to work right) to get most of the stuff done and it was also "proprietary" so I couldn't really do much with it without getting someone upset with me. I guess without realizing it I have been doing my vi's the way that jpdrolet suggests and have not had any problems. The majority of the problems I'm called on to "fix" are because someone's software is being used on something it wasn't written for and the engineers think it's easier to just modify that code than it is to write some from scratch. Thanks again for the help. Jack

Manfred, Thanks for the reply. Unfortunately it didn't work. I removed the checkmark in LabVIEW like you said. I then rebooted (just in case) and rebuilt the application into an EXE and the same thing still happens. I tried a bunch of stuff and noticed that the only thing that matters is the decimal point. If I change the decimal in the Swedish region settings to a period everything works fine. If I leave it a comma it goes wacky again. Right now I'm changing the region of my development computer to Swedish and and then going to rebuild the EXE to see what happens. Thanks again. Jack

I wrote a fairly simple application for an engineer at my work who passed it on to his customer in Sweden. The problem is that if the region setting on their PC is set up for Sweden all the numbers get messed up. Decimals go away (Sweden uses commas) and some calculations don't work, especially those with exponents. I didn't know this would happen at all, thinking that numbers were pretty much universal. I know there are users here from Europe which is shy I didn't think about it being a problem. I have not been able to find anything on the message forums about it. Is there a way to simply change this application from English to Swedish or do they have to live with their PC set to English? Thanks, Jack

I agree with everyone partly I guess. I work for a specialized battery manufacturer and we take way more data than necessary all the time. The usefulness of human readable data cannot be ignored IF someone actually reads the stuff. We have CD's full just sitting around during the development and testing of the batteries we produce. Once the battery is out the door we either give the data to the customer or just summary data sheets. Either way we keep copies of the summary data sheets just for us for a period of time then they get disposed of. You are producing a ton of data that probably will never get looked at. If someone needs to see it you could easily convert it from binary to ASCII for them to read but in the mean time you can save storage space by saving it in binary. If your company is like mine you are better off saving space since even getting a new hard drive can be a huge proposition at times. You can also burn it to CD's and store them and delete the data off the hard drive of your storage computer to keep it running nicely. Basically what comes to mind for me is how long it needs to be stored and how often it gets looked at. If you only keep it a short time or it gets looked at frequently then ASCII may be the way to go. If you need to keep it forever and no one ever looks at it then binary might be the better option. Hope this isn't as confusing as it looks. Jack

Good Grief! Now I don't feel so bad about some of my early projects.

I may be missing something (most likely!) but I have a table on my front panel that is used for various data entry by the user. I don't have the horizontal scroll bar visible because I didn't think I needed it until one of my co-workers used his mouse in the table and caused it to scroll to the right way past the labelled columns. Is it possible to limit the number of actual columns in the table? There is a property node for limiting the number of visible columns but I can still scroll to the right when the VI is running. I suppose I could put the horizontal scroll bar on the screen but if the user puts something in a cell way off the screen it will mess up the data when it gets read later. Thanks in advance. Jack

That would solve so many headaches for me! I'm certainly in favor of this one.

For normal ascii data files you can write the column headers before you actually take the data by simply writing the headers as text to the file using the Write Characters to File function. If you use the separator in that header file that you are using for the spreadsheet data and follow the header line with a CR/LF constant it will show up nicely at the top of your data file and be formatted like you want it to be in Excel as long as you append the file and do not write to a new file.

As far as system cases go I've had pretty good luck with Dells and Gateways. They are usually big enough to have plenty of room inside and have extra USB and Firewire ports on the front for playing around. I'm sure there are many other manufacturers that are like that though. The biggest reason I use those is budgets. They both have really good deals on factory refurbished boxes. We have plenty of keyboards and mice around so you can get a good system for $300 or so. Like Michael, I usually try to go for a few generations old to get the best price for something that will still work a few years from now and may be used on a new setup. As always - the more memory the better......

Perhaps if you attached a sample of the vi or a screen shot of the block diagram we could help you find what's wrong. This is a pretty straightforward application and it shouldn't be too difficult to get you going on the right track. Jack

Congratulations! That is a great avatar.

I currently use Windows XP on my laptop but also have one OSx desktop computer that I've used it on. I have found that there is some difference in compatibility with the USB to RS-232 converters. I have gone through 3 or 4 of them just trying to find one that works on each machine I need it on. I finally got a cheap Targus model just for kicks and it's worked the best for me. My biggest problem when using USB converters is the power they consume. I have a 4 port USB hub (with its own power supply) with most things plugged into it and sometimes they get flaky on me. I have found that if I'm only using one thing for a long time I'll plug that directly into my computer and the problems go away. Each port is supposedly able to supply 500ma but I've found that in real life it isn't exactly true through the hub. My GPIB converter pretty much always needs to be in its own port if I have more than one instrument attached or a long cable on it. My RS-232 converter will sometimes act funny if I print while it's working (like printing programmatically with a VI). They are convenient but there are compromises that have to be made.

My main development computer right now is a laptop and I use a few USB converters. I don't know about the USB to FIFO device but my USB to RS-232 converter communicates through VISA by accessing the COM port like usual with ASRL4::INSTR. My USB to GPIB converter also works just like a normal GPIB interface using VISA using GPIB::9::INSTR. My USB printer also prints through LabVIEW. It's set up as the default on my computer so I think some of that might be handled by Windows. Basically I don't do anything different using those devices than the ports and cards in my desktop. I don't use any special USB translators or anything else, just the drivers that came with them and installed in Windows. All my VI's are usable on both platforms with no changes. I've not used a USB key through LabVIEW yet but my computer sees it as an additional drive so I think that LabVIEW would work with it as long as the drive letter is correct. I do know that my USB key is really slow so I probably wouldn't use it for my primary data storage. Hope this helps. Jack

Randy, That's what I was looking for. :thumbup: Silly me, thinking the XScale.Minimum or XScale.Start would be the beginning of the chart. Thanks. Jack

Franz, I've tried this and one of two things happen. If I have AutoScale X set to Yes, the minimum reverts to the LV default time as soon as I write data to the chart. -or- If AutoScale X is set to No, the current time and date show up but the data doesn't. If, after I write the data to the chart, I change the X scale minimum to the LV default time my data shows up. I also tried setting the XScaleStart property with the same outcome. I've tried it in LV 6.1, 7.0 and 7.1 so far. I know I'm missing something because there has to be a way to do this but I lack the experience of most of the people here. Up until now I've just started the chart at 0 and lived with it. Figuring this out would be great for me. Is there anything else I can try?

I listen to the local country station at work. I find it keeps people out of my office and the music isn't distracting. I listen to classical at home. It's Five O'Clock Somewhere by Alan Jackson was just on.

I try to stick to a max of 1024x768 mostly because that's the highest resolution that most of my targets can handle. I have strayed beyond that a few times but revised my code later and made it smaller. I haven't used a dual monitor setup but after reading some of what you guys do with it I may have to try it. Is it possible to have the front panel and the diagram visible on the two monitors? That sure would be nice instead of flipping back and forth.

Your idea is pretty much what a car really does - multiply the engine RPM by the gear ratio in the transmission to move your wheels. I think it would be simpler if you put a limit on RPM and then you wouldn't have to worry about speed for each gear. The car could shift when it reached the proper RPM. Just figure out what gear ratios you want and multiply that by your RPM. Wire that output to your Speedometer.

I almost always put in a back door if the application is going to stay in house. I will only do it for an application that is going to a customer if I had to rush it through and didn't have enough time to try every possibility. It's helped me a few times in the past. I put Easter Eggs in lots of my code and have forgotten about many of them. I got a call from a person in another lab who I supplied a test setup for asking why his screen colors were going crazy. I had forgotten that I put an April Fools egg in that software because I didn't think it was going to leave our place. He didn't mind it and asked me for the code for it so he could use it in the future.

I'm still in the dark ages with LV 6.1 so I can't see the bug you're talking about. I've started to use tab controls more and am wondering if this will affect me. Jack

I'm fairly new at creating nice interfaces so forgive me if this is too elementary. I was just trying something like this in LV 6.1 in a table. The Active Cell cluster in the Property Node uses a cluster that is the Row number and Column number. Make a property node that has Active Cell and Cell Background Color in it. Once you know the row of the data that is out of range put that number in for the row and -2 in for the column in the Active Cell cluster and put the new color in the Cell Background Color (I use color box constants because they're easier for me). To color a column instead of a row, reverse the numbers. To color a whole table, use -2 in both numbers.

I have used that type of Agilent electronic load (6063B) and have given up on any type of high speed measurement from it. When high speed is necessary we always use a dedicated meauring device because of accuracy reasons mostly as the readings of the load vary quite a bit from day to day. For your application where only a few things need to be measured I would use something like an Agilent 34970A with a 34902A module plugged in. The advantages of this from my experience are that each channel is fully differential and isolated and the unit can store 50,000 readings at around 120S/s or faster if it's set up correctly. That way you could run your test and download your data afterward. I work for a battery manufacturer and use simple setups like this regularly and have had no problems with them. Plus the unit is very versatile and can be used for many other things which might help with cost justification.

We almost never send the source code along with the executables but in every contract that includes software we have a support section that provides a number of hours of free support, including simple upgrades and equipment changes, each year. Mostly that protects the customer from allowing someone without the necessary experience damage the end product. Since we make high technology batteries that could get messy.

I work for a specialized battery manufacturer and I use LabVIEW for running semi- and fully-automated test systems and for data acquisition. Jack