But you didn't get this error when you got the garbage characters and some partial data? How are specifying the number of bytes to read? If you specify too many bytes to read, you'll get the error. Are you sending the command and then using VISA Bytes at Serial Port to determine how many bytes are available? Do you have VISA Configure Serial Port set to terminate read when a termination character is received? If you do and the term character is not sent, you'll also get this error. Can you attach the VI that you've written with all control values set to the values you're using?
Shouldn't make a difference. If you can communicate with it with hyperterminal, you can use LabVIEW. That example isn't one of my favorites but it can be made to work. First, modify the VISA Configure Serial Port by wiring a False to the Enable Termination Character input. Verify that the default settings of 9600 baud, 8 data bits, 1 stop bit, and no parity are correct. I'm assuming that you've modified the String to Write control to '\' Codes Display. Run the VI with the front panel Read and Close controls set to OFF and Write to ON. Next, set Write to OFF and Read to OFF. Set Bytes to Read to some small number (like 1 or 2). Run the VI and see if you get anything back. If you get nothing back, change your termination character (if you used \r before, try it with just \n) and repeat the Write and then the Read steps. If you get some data back, you can repeat the Read until you get a timeout. This will mean you've read all data in the buffer. At that point, you'll know tha basic communication works. Then you'll want to write you own VI. You might want to do a write, a small delay, a VISA Bytes at Serial Port, and wire the output of that to the byte count input of VISA Read.
You've also got the Instrument I/O Assistant to try if you want another example for serial communication.
It's only an educated guess but I do think the reason why you are getting some "garbage" data in your reads is that the micro controller response is formatted in to a console response like a VT-100 console for example. HyperTerminal is configured to emulate a console by default (File>>Properties>>Parameters of the current connection). Considering that: - The garbage data you're seeing is the formatting that allows the user to see the micro-controller's data in a "formatted way" - The data you are getting with LabVIEW is the raw data from the buffer but should include somewhere in there the correct answer (like the version for example) - You probably will have to write a "filter" to be able to extract the correct data out of the frames in the serial buffer
I am currently communicating with chips that sends out the information in a VT-100 console response. What I had to do was: - Make a raw capture of the buffer ("garbage" and data) - Open the data in UltraEDIT for e.g - noticed that the data was represented on the VT-100 emulator screen(like hyperTerm) by system of Vertical and horizontal row (i.e coordinates) and followed by a special termination character (5B in Hex) - Write a string filter that reads the content of the buffer and locate the data in it.
This is just an example as the behavior will probably be different on your side.
Thank you for all your help. I have implemented Dennis latest suggestion with a Write = ON and Read = OFF. Then with a Write = OFF and Read = ON. I did retrieve meaningful data, however I do have some questions about filtering the data. After the Write, I have to run the Read twice or more. For example Writing "Version", I should read "Program Version 1.0 Beta chip x". However during the first Read I get "Version" (I believe is the echoing effect - please clarify). The 2nd Read I get "Program Versio" and the 3rd Read I get n 1.0 Beta chip x". I have set my byte counter to 50, however I find it take a long time to do the read. How can I program it so that my read is independant of my byte counter.
I'm glad that you're finally getting data. The reason I had you do the write separate from the read is that there is always some finite amount of time for the instrument/micro to process the command and send all of the data back. Now you have some idea of the actual time it takes. One simple thing to do now is to put a time delay function after the write and a VISA Bytes at Serial Port before the read. If the delay is long enough, the Bytes at Serial Port will return the exact number of bytes that the device wrote and you would do a single read and get everything. The downside is that the time delay required might change depending on the command and if you make it too long, you're justing wasting time. A more sophisticated method is to put VISA Bytes at Serial Port in a loop. As soon as the bytes available becomes greater than 0, do a read and keep reading until the bytes available are 0 again which would indicate that you've read everything. I've got an example somewhere on my pc or netwrok that does this but it might take me a while to find it. I'm also sure that similar examples have been posted to this forum so it might be faster for you to do a search.