How do you set the number of start bits for a VISA serial session?

[goharikk]

Hi,

I'm using VISA to communicate over a serial port.  I can set the stop bit, baud rate, and parity bit properties.  But there aren't any properties for specifying the number of start bits.  How can I make sure that it is only using one start bit?  Or is that the default?

Thanks

[Makoto]

At least the default Start Bit is 1 for Windows environment.  The DCB struct, which is found in Microsoft SDK document, does not contain any field for Start Bit.  Therefore it is impossible to change the Start Bit at Win32 API level.  It is also true for VISA Srial, which does internally rely on Win32 API.

The DCB struct is documented at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devio/base/dcb_str.asp

Mind that this may not always be true, if any special add-on hardware such as NI's RS-485 board is attached.

[goharikk]

Thanks, Makoto.   I do have a National Instruments PCI-8431/2 board (RS485).  How can I find out whether it is using one start bit or not. 

Also, I intermittantly get framing errors and parity errors.  If the start bits are not the problem, then I think the reason might be that I am not releasing/closing the serial port session correctly before I terminate my application program.  Is there anything I need to do withe the VISA serial session to make sure it rleases the resource (the com3 port)?

Thank you,

Goharik

[Makoto]

> How can I find out whether it is using one start bit or not. 

Sorry but I don't know how the driver handle this.  It is up to the low-level device driver.  At least Win32's Communication API does not provide functions for adjusting start bit.  Or, it is better to check the signal with an oscilloscope.

> Is there anything I need to do withe the VISA serial session to make sure it rleases the resource (the com3 port)?

Your program need to call viClose() the same number of times as you call succeeded viOpen().  It makes sure to release the resources occupied by the VISA sessions.  However, it is a resource management issue and not directly concerning to framing or parity errors.

If you are sometimes seeing framing or parity errors regardless correct BaudRate/DataBits/StopBits/Parity settings, suspective issue is flow control.  If you are just sending tons of messages to the device, which does not equip any flow-control, any strange communication problems including overrun/framing/parity errors will be generated.  To avoid this, there are three different approaches.

1)Use flow-control.  If the device equips one of XFLOW, DSR-DTR FLOW, or CTS-RTS FLOW, use it to avoid communication problems.

2)Insert some wait.  If the device does not equip any flow controls, increasing wait timing between messages will avoid the problems.

3)Insert a read operation that reads acknowledge bytes between messages to be sent, if the device can generate an acknowledge response for each of message receive.

[goharikk]

Dear Makoto,

I tried putting delays between transmissions, but it didnot help.  I still receive framing errors.  However, I found out that the device I am trying to communicate with has two lines for Transmitted data (TTX+, TTX-) and two lines for Received data (TRX+, TRX-).  It does not use any of the other handshaking lines.  Currently, my serial session setup looks like the following (see below).  Am I doing something wrong?  Is there any other parameters that I need to set?  Thanks.

rm =

new VisaComLib.ResourceManager();

session = (VisaComLib.IMessage)rm.Open(portName, VisaComLib.AccessMode.NO_LOCK, 0, "");

ser = (VisaComLib.ISerial)session;

ser.BaudRate = 9600;

ser.DataBits = 8;

ser.StopBits = SerialStopBits.ASRL_STOP_ONE;

ser.Parity = SerialParity.ASRL_PAR_NONE;

ser.FlowControl = SerialFlowControl.ASRL_FLOW_NONE;

[Makoto]

> Is there any other parameters that I need to set?  Thanks.

Normally it has enough attribute settings for serial I/Os except for termination conditions.  Since the device only has TX(+/-), RX(+/-), and GND lines, there are no hardware flow controls.  Doesn't the device provide X-FLOW control or any ackknowledge response? 

> I intermittantly get framing errors and parity errors. 

Once again I would like to ask about it.  Is the framing error generated at device side? or VISA library side?

By the way, the NI's RS-485 hardware you are using is a kind of special NI-specific hardware, and I found some NI-specifc attributes for ASRL related operations.  You can try to adjust these special settings for RS-485 by using VISA COM SetAttribute() method.  Mind that the 'hidden' attribute is given for SetAttribute() and GetAttribute() methods in the VISA COM IDL definition therefore the intellisense (auto-complete) may not appear, but it does exist.  The following attribute IDs (VI_ATTR_xxxx symbols) and setting values (VI_ASRL_xxxx symbols) can be passed to SetAttribute() calls.  (These symbols are defined in NI's VISA.H file) Sorry but I don't know about how to use them and what effect will be made, because I have no experience of using NI's 485 hardware.  But seems like no attributes are there for Start Bit.

#define VI_ATTR_ASRL_DISCARD_NULL   (0x3FFF00B0UL)
#define VI_ATTR_ASRL_CONNECTED      (0x3FFF01BBUL)
#define VI_ATTR_ASRL_BREAK_STATE    (0x3FFF01BCUL)
#define VI_ATTR_ASRL_BREAK_LEN      (0x3FFF01BDUL)
#define VI_ATTR_ASRL_ALLOW_TRANSMIT (0x3FFF01BEUL)
#define VI_ATTR_ASRL_WIRE_MODE      (0x3FFF01BFUL)

#define VI_ASRL_WIRE_485_4          (0)
#define VI_ASRL_WIRE_485_2_DTR_ECHO (1)
#define VI_ASRL_WIRE_485_2_DTR_CTRL (2)
#define VI_ASRL_WIRE_485_2_AUTO     (3)
#define VI_ASRL_WIRE_232_DTE        (128)
#define VI_ASRL_WIRE_232_DCE        (129)
#define VI_ASRL_WIRE_232_AUTO       (130)

[goharikk]

Makoto,

thanks. I will try out the special settings that you mentionned, and let you know how it goes. 

> Is the framing error generated at device side? or VISA library side?

I see the framing error messages when I look at the VISA calls made by my application in the NI-SPY debugger tool.   However, the serial port monitor software I'm using has no trouble reading the responses from the device.

>Doesn't the device provide X-FLOW control or any ackknowledge response?

I don't know whether it provides x-flow control, but I will find out.  As for acknowledgements, it does send response messages (which could be called acknowledgements).  But since VISA gives me framing errors, I cannot read these responses.  However, when I look at the responses with the HHD serial port monitor, I see that the device has sent one byte of response/acknowledgement indicating that it detected a transmission error in the command I had sent to it.   So it seems like this framing errors are happenning at both ends.

[Albert.Geven]

TTX+ and - are referring to differential transmission lines. So instead of rs232 it is either rs422 or rs485 protocol that you are using.

I guess rs422 that is software identical to rs232 but uses two wires for transmission and two wires for reception.