09-23-2011 12:16 PM
Grettings,
I am using a serial interface to a Flux Gate Compass. Its not working because some how the serial port timeout setting is getting set to zero so that the read after a write is always timed out. I have attached my code for LabVIEW 10. Essentially it searches all my com ports for the instrument, configures the settings and then reapeatedly polls the instrument for a measurment. My find routine runs ok but when the VISA session is passed inot the polling loop the timeout somehow is set to zero.
Any help appreciated. Feel free to disect my code and nick pick it. I love feedback.
Norm
09-24-2011 01:38 AM
If am I right, you are getting timeout error when read the serial device after your write. So, I guess the problem is in about handshaking. Try to put some time delay between write visa and read visa. You can find in programming-->structures-->flat sequence structure and then go for timing options and select time for 500s and pass all the wires through flat sequence structure with inside a timer. If you still get the same problem, try increase waiting time again and test.
09-24-2011 01:40 AM
Sorry it was milliseconds not seconds.
09-26-2011 12:08 PM
Turns out I used a formula for the timeout that was applicable for the data update rate but I used it for the baud rate. It was always less than 1 so when it was converted to I32 it rounded down to zero. I replaced the formula and its now working.
Since I know how many bytes are comming from the compass I can set the timeout to 150% of the response time + transmit time. That way if it doesn't come back the timeout is short to increase my error response time. No wait state is needed since the read either terminates on the specified number of bytes (even if they dribble in) or on timeout. Adding an additional wait state isn't necessary in my case.
Thanks,
Norm
09-27-2011 01:23 AM
09-28-2011 11:23 AM
Hello to Netherlands,
Yes you would think NI would put error in/out connections on the get Data/Time vi so that the flat sequence could be eliminated. It rather is a clunky way to control when the time is acquired to use flat sequences. It's also a good way to get bad timing information.
Norm