Hardware handshaking causing a serial comm issue?

[paris1_]

Hi...  Lynn, I think you nailed it...  It had been on my list of "things to try" and yesterday afternoon I got around to disconnecting the Cygnus unit from a port on the serial port adapter and instead plugging that cable directly in to the one real com port on this particular Dell PC, COM1...  I would have tried this earlier but since the SQC units had worked just fine when plugged in to this port expander (though granted I was told the SQC's also do not use handshaking) I had looked at other potential problem areas first...

Before making this change, I tried all sorts of hardware handshaking settings while trying to run at 9600 baud (a speed at which I would now and then get a piece of data through) and no handshaking settings seemed to help...   

So next, I removed the hardware that was plugged into COM1 and instead plugged in the Cygnus unit to that port...  Lo and behod, it took off and ran, even at 19,200 baud, a speed at which I had never before been successful at passing any data...  And I had success whether handshaking was set to "none" or to one of the other allowed settings...???  Not sure I understand that but the bottom line is, without the port expander in the system, it just worked...  

I do still see that once in a great while I get a message that doesn't quite decode properly...  The way this is set up, in every ouput message I get 26 HEX bytes, 16 of which, in four groups of 4 bytes each, are the pieces of data I am interested in...  The way I had this running yesterday, three of those bytes always converted to 0.0 and the 4th byte was a different number...  On rare occasions I would see that non-zero number show up where one the zero's should have been so it's still not perfect but it's way better than it was and I think now it is useable...  There is one other byte of that 26 HEX bytes output that is an error byte...  It is supposed to always be 00 for good data and something other than 00 for bad data...  I will monitor that byte next and see if that correlates with when I see data show up in the wrong place...

But the bottom line is thanks for the suggestion that perhaps the port expander doesn't play well with this particular unit...  You are correct...

thanks... bob... 

[Peg]

For what it is worth (now that you have found your problem), we have also had problems with USB to serial convertors. However, we have to use them since very few laptops are now available with native serial ports. Our readings are sometimes shifted, something it sounds like you might be experiencing. As a workaround to speed things up and get better results, we have LV shift the readings using known markers (maybe like the zero you get in a certain position), so that more of the readings are "good". It is still not as good as a real serial port and unfortunately the USB to serial can occasioanally lock up, requirting a computer restart to free the port.

Peg

[tbob]

If you are out of COM ports and need to use the USB converter, you can.  All you have to do is to re-wire your cable like I said earlier.  Jumpers: CTS-RTS, DCD-DTR-DSR.  All at the device end.  This will overcome the USB converter's shortcomings that Lynn described.

[paris1_]

Got it...  I will look into getting such a cable built and I will check it out...  Thanks to all for all the input...  Much appreciated... bob...

[paris1_]

tbob...  Later today I am going to try to build the cable you, tbob, suggested as I am still getting sporadic, bad data...  Maybe one bad point in every 100 or so...  And when it's "bad" it often appears to just be a partial message...  After having found the problem with the serial port expander, I went back to running at 19,200 baud and with the delay between Serial WRITE (to request a response) and Serial READ (to obtain that response) set to a full 0.5 seconds.  With the serial port expander in place I was previously getting ZERO data at 19,200, some at 9600 and almost but never quite all at 4800 or 2400...  With the port expander gone I was now getting as much data at 19,200 as I was previously getting at 2400 (about anyway)...  But still not all...  So I have since lowered the baud rate back down to 2400, increased the WRITE to READ delay from 0.5 seconds to 1.0 seconds and I have moved the VISA Serial Port Config handshaking from NONE to RTS/CTS...  But still I get errors, still around 1 bad point for every 100 points I read...  

Would this perhaps suggest a poorly designed serial interface in the Cygnus unit???  Beyond trying to fake out the Cygnus by building the above mentioned cable, does anyone have any suggestions???  Just for the heck of it I have pasted below precisely what the Cygnus manual says about handshaking.  

From the Cygnus manual on handshaking...

The port incorporates hardware flow control via Request to Send / Clear to Send (RTS/CTS) and Data Terminal Ready / Data Set Ready (DTR/DSR) signaling.

Request To Send (RTS) . . . . . . . . . . The instrument informs the host it is ready to receive a character by asserting the RTS

signal. It lowers the signal when the receive buffer is full.

Clear to Send (CTS). . . . . . . . . . . . . The host informs the instrument it is ready to receive a character by asserting the CTS

signal. The host should lower the signal if its receive buffer becomes full and raise the signal when it can receive data again. This signal has an internal pull up in the instrument. Therefore, if left disconnected the instrument will assume the host is always capable of receiving data (no flow control).

Data Terminal Ready (DTR) . . . . . . . The instrument informs the host that it is powered up and able to communicate by

asserting this signal.

Data Set Ready (DSR) . . . . . . . . . . . The host informs the instrument that it is able to communicate. The instrument will ignore

all incoming data if this signal is de-asserted. This signal has an internal pull up in the instrument. Therefore, if left disconnected the instrument will assume the host is always able to communicate.

Note that they seem to imply they use both RTS/CTS AND DTR/DSR while the VISA Serial Port Configure VI in LabVIEW 7.1 offers both separately but that there is no option that uses both together???

Beyond building the special cable which I will try next, any other thoughts on why I might still be seeing sporadic bad data???

thanks... bob... 

[johnsold]

Your description sounds like it is possible that the instrument is using the flow control but your computer is not.

As long as you do not have problems with power to the devices being turned on and off while trying to run, do not worry too much about the DTR/DSR handshaking.

Try to implement the RTS/CTS handshaking to see if that makes a difference.  If you cannot easily implement that, try monitoring the RTS/CTS lines with an oscilloscope to see if the instrument is using them.

Lynn

[tbob]

---

@johnsold wrote:

Your description sounds like it is possible that the instrument is using the flow control but your computer is not.

As long as you do not have problems with power to the devices being turned on and off while trying to run, do not worry too much about the DTR/DSR handshaking.

Try to implement the RTS/CTS handshaking to see if that makes a difference.  If you cannot easily implement that, try monitoring the RTS/CTS lines with an oscilloscope to see if the instrument is using them.

Lynn

---

My experience with RS232 devices shows that devices that use hardware handshaking (RTS/CTS) typically uses DSR and DTR.  DSR is output by the computer when the serial port is initialized, and stays on until the serial port is release.  DTR is output by the end device and it also stays on as long as the device is powered up.  Some devices will not work if it doesn't see DSR from the computer.  So DSR/STR is not really handshaking, it is an indication that the device and computer are both powered up.  I would not ignore them unless you know for sure that the device does not require handshaking at all.  If your device works with TD, RD, and GND only, then you can ignore all other lines.  If it doesn't, use all other lines to be safe.  About DCD, a few devices require that one also.  It was originally meant to detect that a modem was outputting a tone.  But I really don't think non-modem devices use this anymore.

[paris1_]

tbob... As we speak, I am having one of our techs build precisely the cable you suggested back on the first page of this same post... 

If I build precisely that cable you suggested, with jumpers as you defined on the DCE end (Cygnus chassis end), will that "faking out" of the handshaking satisfy what you describe in your most recent post???

thanks... bob...

[johnsold]

I think tbob is right.  If I had thought a bit more before typing, I would have suggested wiring the cable so that DTR/DSR always appear ready and do the handshaking with RTS/CTS.

Lynn

[paris1_]

See a few posts above where I pasted right out of the Cygnus manual how it handles handshaking...  Looking at that and looking at the cable tbob suggested I build (which I am building)(see we he reccommended back on page 1 of this thread), would building that exact cable likely satisfy what the Cygnus is looking for such that I might have more success than I am currently having getting reliable data out of it???

thanks... bob...