VISA rs-232 questions

[nightz13]

Hello,

I'm using VISA libraries in C++ to control a GPIB device and two RS-232 Devices.
The GPIB DAQ unit and RS-232 power supply are working great.  My issue is with an RS-232 Microcontroller Programmer.
I'm using a Serial PSoC Programmer by Arista Systems. 
Using this code:
viQueryf( psoc, "%s", "%t", "v\r", myIn);  //request version
I can send commands and get a response all day long.  The above command "v\r" requests the firmware version from the hardware.
It's returned in the 'myIn'.
My issue is when I change the baud rate of the programmer. 
I use the statement:
viQueryf( psoc, "%s", "%t", "b02\r", myInitIn);  //changes baud rate to 115200
Two seconds after the baud rate is changed, the programmer responds with an 'OK' string (or error code) sent at the NEW baud rate.
I'm having a hard time reading the return codes after changeing the baud rate.
The next command I send after changeing the baud rate fails...I assume it's because I have not read the 'OK'string from the buffer.  The third command and everythin thereafter work great. 

I've tried using viRead and viScanf to pick up the return codes after changeing the baud rate.  No luck.
Also, viQueryf seems to be the only way to send and receive anything with this device....shouldn't I be able to use viPrintf or viWrite?
I'm looking for any suggestions.  btw, all the above commands work great in a terminal program, so I know the programmer is working as spec'd in the manuals.
I can get by without reading the return codes after changeing the baud rate but, it would be nice to have error detection in case something is wrong.

Thanks,
-Rocko

[JoshuaP]

You mention and show that you are changing the baud rate on the instrument, but do you every actually change the baud rate for the serial port that you are using. If not, you will need to make a call to viSetAttribute and change the VI_ATTR_ASRL_BAUD to match what you have sent to the instrument.

I would suggest sending the command to tell the instr to change, then call viSetAttribute to change the setting on the port and then wait for a few mS before trying to use the new baud rate, because it sometimes takes time for this call to be processed depending on the serial driver.

-Josh

[nightz13]

Josh,

Thank you for the reply.  Yes, I am using viSetAttribute to change my port to the new baud rate, waiting, and then trying to read the 'OK' message.
I think by the time my port has been changed via viSetAttribute, my target device has already sent the 'OK' message and the buffer may be getting cleared when the hardware changes to the new baud rate.  My 'OK' response is lost forever.....

I have made progress:
I added these two lines while setting up my port:
   viSetAttribute( vi, VI_ATTR_WR_BUF_OPER_MODE, VI_FLUSH_ON_ACCESS);
   viSetAttribute( vi, VI_ATTR_RD_BUF_OPER_MODE, VI_FLUSH_ON_ACCESS);

Adding them causes viQueryf to no longer work but, I can now use viPrintf and viScanf without issue.
I send the command to my target to change the baud rate.
Change my hardware using viSetAttribute
Then re-send the command to my target to change to the new baud rate (redundant).
Re-sending the baud rate command allows me to read the 'OK' message at the new settings.

The whole purpose is, my target defaults to 19200 baud.
After I establish the 19200 link, I bump it up to 57600 for faster downloads.
The target has a max speed of 115200 but even in hyperterm, it's not reliable.  It's skipping bits. So, 57600 will have to do.

-Rocko

[LuI]

Rocko,

> The whole purpose is ... to ... bump it up to 57600 for faster downloads.
> The target has a max speed of 115200 but even in hyperterm, it's not reliable. 
> It's skipping bits. So, 57600 will have to do.

Just in case...  Have you tried a different - and hopefully shorter - serial cable?
Allthough 115200 can be problematic for some simpler hardware, if the producer states this as the max baud rate, it should work  (at least under some given circumstances).
We have coupled a number of serial devices with a single PC with 115200 and have found that the serial cabling was one of the key factors. Finally we used high quality cable that where just long enough to connect.
Just my Euro 0.02!
Greetings from Germany!<br>-- <br>Uwe