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