Hardware handshaking causing a serial comm issue?

[tbob]

I just re-read the Cygnus spec you posted.  I'm afraid that faking out the RTS/CTS is still going to cause missing data.  If it doesn't then disregard there rest of this post.  You may have to run it for a while before you start seeing lost data.

The manual says:

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

If the computer's buffers are full, it has no way of signaling the Cygnus device to stop sending data because the cable I suggested fakes out the signal.  Cygnus will continue to send data and the computer's buffers will overrun, causing lost data.  You need to use full handshaking.  Build a cable that connects all pins from the computer to the Cygnus.  No jumpers to fake out anything.  Pin 1 to pin 1, pin 2 to pin 2, all the way up to Pin 9 to pin 9.

In your vi, just set handshaking to RTS/CTS only.  You should not have to set DTR/DSR, because those should automatically be set when you choose RTS/CTS for handshaking.  This will prevent buffer overruns.

[paris1_]

tbob...  Can you say more about what you said here...

"...In your vi, just set handshaking to RTS/CTS only.  You should not have to set DTR/DSR, because those should automatically be set when you choose RTS/CTS for handshaking.  This will prevent buffer overruns."

Over the previous weekend we ran they system precisely that way, with a standard, fully wired RS-232 cable and with the LabVIEW VISA Configure Serial Port set to RTS/CTS Flow Control...  We lowered the baud rate down from 19,200 all the way down to 2400..  I set the delay between WRITE and READ to 1 full second..  And yet still we got errors...  For every 100 day points typically 3-4 were corrupt...  

I have noticed in LabVIEW that they offer Flow Control choices that include BOTH XON/XOFF AND RTC/CTS...  They have another choice that is BOTH XON/XOFF AND DTR/DSR...  But they DON'T offer a choice that is both DTR/DSR AND RTS/CTS... Is that because of what you said above, that when you set RTC/CTS, you automatically get DTR/DSR tossed in for free???  

thanks...  bob...

[tbob]

---

@paris1 wrote:

I have noticed in LabVIEW that they offer Flow Control choices that include BOTH XON/XOFF AND RTC/CTS...  They have another choice that is BOTH XON/XOFF AND DTR/DSR...  But they DON'T offer a choice that is both DTR/DSR AND RTS/CTS... Is that because of what you said above, that when you set RTC/CTS, you automatically get DTR/DSR tossed in for free???  

---

Yes, exactly.  If you set RTS/CTS, Labview should cause the computer to assert CTS when the serial port is initialized.  No need to select anything.  That is why there is no RTS/CTS AND DSR/DTR choice.

DO NOT USE anything with XON/XOFF in it.  This is software handshaking and your Cygnus device does not support it.

---

@paris1 wrote:

Over the previous weekend we ran they system precisely that way, with a standard, fully wired RS-232 cable and with the LabVIEW VISA Configure Serial Port set to RTS/CTS Flow Control...  We lowered the baud rate down from 19,200 all the way down to 2400..  I set the delay between WRITE and READ to 1 full second..  And yet still we got errors...  For every 100 day points typically 3-4 were corrupt...  

---

You do not need any delay between write and read.  When you write, the device immediately sends back a response.  It could be sending more data than the buffers can handle.  The buffers get filled up as the Cygnus sends data.  Reading empties the buffers.  However, this is what handshaking is supposed to take care of.  If the buffers get full, the computer is supposed to drop CTS and the device is supposed to stop sending. 

When you get to the read vi, the buffers start emtying, and CTS goes up and the device starts sending again.  You may have to put your read in a loop until there are no more Bytes At Port (look up this function).  Could be that you read the data, then the computer asserts CTS and the Cygnus starts sending again, but you do not call the Read function again.  Try using this snippet in place of your serial read function.

[paris1_]

Good point...  I will try your code...  I do use the "Bytes at Serial Port" property to tell the READ how many bytes are sitting there and therefore how many bytes to read...  But I just assumed, and perhaps quite incorrectly, that once it read that number of bytes (it happens to be 24 by the way, that's how many bytes long the correct message should be from the Cygnus for the particular command we are sending) that I would then just be good to go, ie., that zero bytes would be remaining after I had read the 24...  What you are saying by deploying the loop around the read is to keep reading until you explicitly see that there are truly are zero bytes at the serial port...  That's certainly easy to implement and I will give it a shot...  

On one other point, you say there is no need to have a delay between WRITE and READ...  OK.. I set those delays because I am just searching for a cause...  But there is one other detail I need to toss out...  When we do the WRITE / wait (which you say could be zero) / READ, we do that and then we do it a second time...  There are actually two channels worth of data we are gathering from the Cygnus...  The first WRITE issues the command to get the data for the first channel and then we send a slightly different WRITE command to get the data for the second channel...  

So it is really WRITE / wait / READ followed by a different wait, and then a second WRITE / wait / READ...  

That item I call "different wait" I have currently set at 250 msec and I hadn't really thought (until now) about whether THAT wait might be too short...  So you say I don't need a "wait" between WRITE and READ....  But how about a delay longer than 250 msec between READ1 and WRITE2  ????

Your thoughts???  

I will implement the loop you suggested and let you know if that helps???

thanks...bob...

[tbob]

I didn't know you were writing twice.  The wait may be necessary, but I would not wait as long as 1 second.  The best way to do it is the use Bytes at Port in a loop, then exit the loop only when there are more than 0 bytes at port, then read.  If you have the termination character enabled (in the initialization vi), then you would not need to read in a loop like I suggested.  The termination character means that the read will continue until the termination character is received.  The end device would only send the termination after all of its data is sent.  I'm kinda grasping for ideas as to why you are losing data.  handshaking should prevent that from happening.  Here is a method to try that waits until there are bytes at port before reading.  This would replace the wait between write and read.  You may still want to wait between the first read and second write.

Here is a snippet that waits until there are some bytes to read.  If bytes never show up, a timeout error is produced after 10 sec.

[paris1_]

Hi...  I just coded up the first piece you suggested, the READ and keep reading until there are zero bytes at the serial port...  I am going to go try that but I have to drive about a mile away to do so...  Then I'm going home for the evening...  I will let you know tomorrow what, if anything, I learned...

And just to say it, we are NOT using the termination character...

And sorry for not mentioning earlier that I do the WRITE / wait / READ sequence twice...  I knew that but I was so focused on what was happening within the sequence that I just forgot to mention that we do it twice...  

I will holler back later...  

thanks... bob...

[tbob]

If not using the termination character, you will probably have to read in a loop until there are no more bytes at port as I had previously suggested.  this should fix the problem.

[paris1_]

Success...  tbob, your suggestion to put the bytes at serial port and the read inside a While Loop and to stay in that loop until Bytes at Serial Port was truly zero proved to be the ticket, well that and the earlier revelation that this hardware, which uses hardware handshaking, doesn't play well with the Keyspan Serial Port Adapter... 

Once I added the While Loop as you suggested, our data errors went to zero... 

Thanks, tbob, for that help.  Thanks also, Lynn, for the first suggestion about the Serial Port Adapter perhaps being an issue...  And thanks to all for the many, all useful replies... 

bob...