Published in: 2015 International Conference on Industrial.Are there any fundamental limitations to the speed of dealing with NI-VISA in relation to serial communication?You can use the \Codes Display of string controls and indicators in LabVIEW to verify that the termination characters are consistent. Check the compatibility of your operating system (OS) and NI-VISA driver.The prototype can be used with Minicom (Linux/Unix), HyperTerminal (Windows) and NI LabVIEW. Rename it to have the same name as the executable (name.ini) and edit the first line from LabVIEW to name. For executables, copy the LabVIEW.ini file (located in Program Files\National Instruments\LabVIEW 20XX\LabVIEW.ini) to the folder of the executable.
USB driver provided by RIGOL or VISA library. Users can programme the oscilloscope based on the. This will allow you to determine which termination characters HyperTerminal uses.Visual Basic 6.0 or LabView 8.6.
Labview Hyperterminal Drivers Are Available
I'm operating at 38400 baud and seeing a cycle time of about 30 ms for this exchange. My command is a fixed size of 12 bytes and the responses can be of varying sizes from 3 to maybe 20 bytes. You can use terminal programs such as Advanced Serial Port Monitor, Termite, TeraTerm, PuTTY, and HyperTerminal I send off a string down the bus and wait for a response. LabView drivers are available from ASI, see the ASI main website under Support. When I run my VI, it doesnt run properly. Each exchange looks something like this:I use hyperterminal to monitor port status that is defined virtually.
The port is configured such that read calls return immediately if there is any data waiting, or to wait for 1 ms for new data if nothing is there.For this test, my write operation is a constant 13 bytes, read operation is a constant 5 bytes. This involves looping on ReadFile and concatenating the returned bytes into a buffer until I successfully find my end of line character. Reading a "line" from the port. This is a simple WriteFile call. Writing bytes to the port.
Consider it public domain, anyone can do what they will with it. For what it's worth, I'll attach the library I made as a wrapper to the Win32 API. Edited by MadsWe only have four devices connected to the bus which are involved in continuous data exchange, and an optional fifth device which is for the most part silent.Over the last few days I've deployed the Win32 solution into my main application and it works beautifully.
All was working well for me until I tried to use it off a fresh boot. That is Read Line can block indefinitely if data slowly trickles in at a rate that's faster than the specified timeout.FYI, I've tracked down a bug in the code I posted earlier. As-is, if you use the Set Timeout method, it will configure the port such that Read Line will timeout if no data is received for the specified duration.
I know a lot of these settings (if not all) persist on the COM port outside the scope of any application, which is why proper practice is to get the port state before you modify it, and restore it when you're done.I'll post more info if I track the solution down. I've been playing with the DCB cluster trying to make things work by removing padding bytes, properly setting the DCBLength field, etc, but no luck yet. However if I use my library right after a boot before any other application has "properly" used the port, then I'm out of luck.
0 kommentar(er)
