Tim_S

QUOTE(jennifer @ Jan 25 2008, 06:04 AM) It would help if you'd attached a sample of your csv file. Based on your description, processing the file as a double won't give you the proper first value as it's a timestamp and not a double. You'd have to process everything as a string array to preserve the timestamp. After that you'll have to process the strings. Depending on what you're doing, there may be better ways of processing the csv file.

QUOTE(Neville D @ Jan 23 2008, 02:01 PM) The LabVIEW VIs for INI files are definitely slow. It's not bad on small files, but very noticable with large files. My initial workaround for reading in the INI file was to read in the entire file as a string and then process the lines. I don't remember the time difference at the moment, but it seems like it was an order of magnitude change. I've not used the David Moore VIs. Can anyone relate how they compare? Tim

QUOTE(bayram_mercan @ Jan 24 2008, 05:57 PM) You're getting 100 samples back because that's how many you've configured the DAQ assistant to return. I suspect that 100 samples is the default and it wasn't changed. I'm not sure what you're looking to do with getting the exact time. Are you looking to have a timestamp for every sample? For the start of the data? For the end of the data?

QUOTE(eoin @ Jan 24 2008, 01:37 PM) OPC shouldn't be hard. If you open up the NI Example Finder and search for OPC you'll find several examples, plus there's shared variables. Tim

QUOTE(eoin @ Jan 23 2008, 07:42 AM) Ethernet is pretty vague as it's a hardware protocol. What software protocol does your gateway use to communicate? It could be EthernetIP or ModbusTCP or something in swahili. Does the gateway have an OPC server? Tim

QUOTE(Raquel @ Jan 22 2008, 06:42 AM) You've not included anything about the hardware you're using nor any code, so it's not really possible to provide any useful advice. Tim

QUOTE(dsch @ Jan 21 2008, 04:12 PM) You'll have to use a separate +12VDC power supply. I wouldn't try powering anything from an analog output as I doubt it has sufficient current capacity nor does it go to your 12 volts. The card has the pieces you mentioned. One thing you may want to make sure of is that the valve you're using has the proper electrical isolation to protect your DAQ card and PC. From what I've seen, most manufacturers are assuming their equipment will attach to a PC nowadays rather than something significantly more rugged.

QUOTE(YaSmEeN @ Jan 19 2008, 05:13 AM) From the controls standpoint, you're missing hardware or information; once you have the values into your program, how do you control the pump to provide X units of water. I'm guessing that's not a concern and that getting the information into your program is. On that, I see two methods of doing so: 1) have LabVIEW open the Excel file using ActiveX, .NET, etc., and read the information in using that link, or 2) export the information from Excel into a text file then have LabVIEW read the text file.

QUOTE(dsch @ Jan 19 2008, 07:56 PM) From what you describe, you're going to be soldering up a cable. Have you tried looking at National Instruments' website? They sell hardware as well as LabVIEW.

QUOTE(Natu @ Jan 20 2008, 05:39 AM) Mike... I'll remember that students use this board in the future. Natu... If you open up the VI properties and go to the Execution category, I think you'll find what you need. By default, one copy of a LabVIEW VI exists no matter where it is placed in a program. This is desirable for most cases. However, there are cases such as what you're describing, where you want one copy of the VI to exist per use in your application. In LabVIEW this has been called "Reentrant execution".

QUOTE(Natu @ Jan 19 2008, 01:41 PM) Creating a flip-flop involves a clock and logic gates. The information on these is redily available. For an RS flip-flop, a good gate diagram is at http://www.play-hookey.com/digital/rs_nand_flip-flop.html I've attached an implementation of an RS flip-flop based on the site. You'll still need a clocking source. Note that the flip-flop has to see both edges of the clock before it fully changes state with this implementation. Also attached a second (simpler?) implementation that clocks on the falling edge of the CLK signal.

QUOTE(TobyD @ Jan 17 2008, 02:59 PM) Ah! I was using an image depth of 32 and that was messing things up for me. Thanks for the assistance! Tim

QUOTE(TobyD @ Jan 17 2008, 01:41 PM) Yes, the first part looks recognizable. I don't see a "Get Image" under the clipboard, so I assume there's a flag I've not set in the LabVIEW ini file. Taking the data into a Draw Flattened Pixmap produces an interesting image, but not a correct image. The results remind me of interlaced image files. Before I forget again, thanks to everyone who is helping!

QUOTE(tcplomp @ Jan 17 2008, 07:09 AM) The Code Capture Tool doesn't provide what I'm looking for as I want to perform a screenshot of the entire display, which could include, say, an instance of Notepad. It appears that the tool accesses the clipboard, but is this different than the method that the invoke node Read from Clipboard performs?QUOTE(Louis Manfredi @ Jan 17 2008, 10:18 AM) Hi Tim:Have you tried SnagIt? (http://www.techsmith.com/) Not completely free, but inexpensive & has a free trial & I've been happy with it.Best, Louis In 10 minutes of playing about with SnagIt, I'm impressed with the user interface and the apparent ease of use. However, it doesn't appear to have a programmic interface, which is what I need (lousy customer specs!). There is an registration for ActiveX for SnagIt (nothing in .net), but the property and method nodes were empty.

I'm looking to perform a screen capture and am having some difficulty finding how to do this. By screen capture I don't mean a single VI's front panel, but the entire display. I found an example that simulates using the print screen button to capture the display to the clipboard. This worked when I pasted into paintbrush, however reading the clipboard in LabVIEW returned a zero length string. Searching resources hasn't produced any other information on how a screen capture of the display can be done. Ideas I've had appear to have run into walls. I'm using LabVIEW 8.5 on Windows XP. Anyone have ideas? (Dare I hope for sample code?)

QUOTE(Tomi Maila @ Jan 16 2008, 01:48 PM) From a bit of poking about, it appears that all of the information you're looking for is blocked from any remote access. I think the sugestions of the local application publishing the information in some manner (TCP, UDP, front panel, shared variable, etc.) to be your best solution.

I'm assuming you're using the open application reference, though I've noticed that you could be using the TCP communication or similar as well. Looking at the Open Application Reference, you have to know the machine name and can optionally add the port number when making the connection from A to B, so I assume you know both of those at A. You'd still need to get that information to C, though if you all ready know this information at A to where you can make the connection in the first place, then why don't you know it at C? What version of LabVIEW are you using? You may be able to use shared variables to have B publish the needed information to where A and C can access it. Tim QUOTE(Tomi Maila @ Jan 16 2008, 07:30 AM)

I've used both methods and which I've used depends on what the dynamic VI is doing. If it's something that I'm going to run once, I set the front panel control values and then run the VI. If it's something that's going to loop in the background, I may pass some initial values (configuration files path, for example) and then pass information to it using events, queues, and LV2 globals. The method I used depended on the application's structure and the nature of data to send. For example, error handling routines get their information from a queue so all the errors can be handled at once while a value that can be set from or used in multiple points in the application goes to a LV2 global.

This what you're looking for? QUOTE(thevoiceover @ Oct 3 2007, 02:18 PM)