longzoo

nice. I was not thinking of using the DI sampling rate. I was thinking of "reading" the input in a loop..*smacks forehead* Thanks

I have an application where i need to send a variable DC voltage output (from 50-250mV) then time when an event happens after the voltage is applied. I envision a switch tied to a DO then measure the time to the DI event. Some of these events will occur within 1ms of the output event. Can anyone suggest hardware that is capable of this kind of timing?

one other note...i noticed when i plugged another identical device in (same UART different serial number) and went to change the COM that the old COM number was "in use" as long as LabVIEW was still open. Regardless of restart, rescan, disable and enable cycles

ding dang it...It's still latching up. I found that the version of devcon.exe i was using was a tad old and when i downloaded the new WDK (version 8.1) i was able to disable, enable, rescan and restart, however LabVIEW still won't allow me to use the port until i completely quit LV and come back in Any other thoughts?

hmmm, no i was running with the rescan swithc....let me give that a shot NICE! thanks so much

Thanks for the reply viSci, I downloaded, installed and ran devcon.exe both manually (right click>>run as administrator) and with system exec.vi. Either way when i run VISA configure...vi I still get a -1073807330 occurred at Property Node..... I seem to be missing something here

Thanks Chris, I manually ran Visa close several times but it seems to just latch up.

I have a USB device that I need use with COM drivers as well as D2XX. In order to switch between the two drivers a registry edit has to be made (which is no small feat for Windows 7 and the many levels of permissions). At times I have to switch from COM to D2XX, send some commands then switch back to COM. As expected, when i switch to D2XX i notice my COM port disappears from Computer Management then swiching back to COM it reappears. HOWEVER, after this point I can no longer run "VISA configure Serial Port (Serial Instr).vi" without the -1073807194 property node (arg 8).... error. I found in LAVA that arg 8 has to do with the flow control but regardless of the flow control setting i cannot make it pass. The only way to get VISA configure to run is to close LabVIEW COMPLETELY then reopen it. I also read that the arg 8 error can be caused by a hub so I moved the USB to the side of the computer rather than the monitor to no avail. Can anyone tell me if LV is holding that port somehow, and how i can make it release?!? I have attempted to run VISA close as well as FT_Close_Device but nothing short of a complete closure of LabVIEW seems to work. Thanks, Dave

Thanks Mellroth! That was it....i did a "search and replace" for 0x5C with null on both strings and it is working now...although i see a new folly in the way we do this, there are many characters we will inadvertently hit since our string is any combination of hex characters 0x3F (?) 0x2E (.) etc. Thanks for the info Dave

Hello all, I am having an interesting problem that i finally traced down to the simple little "match pattern" vi. I inherited many programs that use that vi for everything from pulling a single character out to sorting a huge list from a text file (neither of which i advocate). HOWEVER, I was troubleshooting some code that only showed an error in one specific situation and upon delving in I found this vi to be misbehaving, or more likely I misunderstand how it is behaving ;-) The vi has to remove an echo command then display the response. it goes like this i send 0xABCD and read back 0xABCD1234, i need to display 0x1234. I did a workaround where i read the number of bytes sent then use that as an offset for "string subset" vi. but i am curious why "match pattern" is not working for this one hex command . Please see the attached vi. that will show two hex commands, one that works and one that does not. You will notice both sent commands have 14 bytes and match the first 14 bytes of the reply, both show a match if you pull the first 14 bytes of the reply but only one matches with match pattern...it is written with LV 2011 SP1. Thanks for looking. Dave MatchProblems.vi

Philip...that is AWESOME! It's much better and easier than my clunky workaround. many thanks! Dave

NOTE: while typing this up i found my solution but decided to post anyway in case it may help someone else I decided to quit beating my head off the keyboard and ask for help...I have a vi that will eventually be an .exe distributed across a variety of windows xp to windows 7 machines (32 and 64 bit). In this vi a bunch of data is saved to a .tsv file at C: i then need to open the .tsv file in excel. After some searching i found System Exec.vi. it initially seemed to be my silver bullet because if i open command line in windows and type " excel.exe c:temp.tsv" Excel is opened (and this should work across different versions of Office). BUT with system exec.vi i get an error "Error 2 occurred at System Exec.vi Command was "excel.exe c:temp.tsv" Possible reason(s): LabVIEW: Memory is full." blah blah blah... If i replace "excel.exe" with Notepad it opens the data no problem with notepad but i need it to be in Excel. i read about using "cmd /c" and attempted to no avail Here's where i found my issue... it is "cmd /c" NOT "cmd c" ! so i used "cmd /c c:temp.tsv" and voila it opens with the default program for .tsv (which is obscure enough that i can make Excel a default on all of the computers in the building) for some reason cmd /c excel.exe does not work to open excel. i found this odd as excel.exe entered directly in the command line will open excel regardless of which version you have installed, but i believe i can live with this.

update: the LCD on the front of the meter responds with a 2 second delay, so apparently the lag is inherent in the system, i can read it every 170ms but the data shown is always 2 seconds behind ;( thanks again for the info ASBO

Thanks for the response, First the easy questions...the baud rate is 9600, the 70 ms is added between a visa write and a visa read in my subvi. As far as multiplexing I don't think that is necessary as I specify an address when I "visa write". Then when I read the buffer the only thing there is the reading from that address. I don't think there is a "read all" command. I determined the read time from multiple reads of all 5 sensors that i have into an array, ie. write to address 1, read ->to array; write to adress 2, read->to array; etc. when i ran that 100 times i got 500 readings and when i averaged it I still got ballpark of 170ms. I am not trying to split hairs here, a 500ms delay would be fine but when constantly reading the two sensors and displaying on the front panel you can cover a sensor and count... one-mississippi-two-mississippi then the bar drops. I am starting to suspect that the delay is in the meter itself before it sends the data to me. I will do some more experimenting today and let you know. regardless, thanks for the info and especially the "unrelated things" I am always open for suggestions on how to clean up my code !

I am working on a project that requires alignment of a light source. There is two light meters sitting 45 degrees from one another and when they both see the same amount of light the fixture is aligned. I have a sub-vi that reads the light meters with approx 70ms execution time but when i put them in a loop and read continuously to a set of graduated bars there is considerable lag (more than a second). I put a tick counter to determine loop time which is around 170ms. any ideas on why the long lag?