07-21-2010 10:54 AM
Hi... I posted a somewhat different but related question a few days ago when I was having no success at all communicating with a Cygnus Vapor Deposition Rate Controller from Inficon. What I discovered was that I could not communicate at all at 19,200 baud even though that was shown in the Cygnus manual as an acceptable rate. I got sporadic readings at 9600 baud and found that I had to go all the way down to 2400 baud to get a serail WRITE/wait/READ each time I requested one (once every 10 seconds)... I also found that I had to increase the wait time between WRITE and READ from an original 100 msec to 500 msec to be able to capture the entire message (rather than just part of it) each time... So now we are running the labview code that grabs data from this instrument once every 10 seconds for hours and hours... And the news still isn't as good as I hoped... What I am now seeing is that perhaps one in every 20 readings is completely wrong... The message I get back from the serial port is a long string of HEX numbers that I then parse in a known way to extract four pertinent pieces of numerical data... I then plot that data and also send it off to an Excel spreadsheet... The numbers all make sense until one of these flawed readings comes along that instead of being a number that is routinely between -100 and +100, it will instead be something like 5.7E+38... And when one of the four readings is wrong, they are ALL wrong, meaning the serial read (or maybe the serial write?) was corrupt...
I have used very similar code to extract very similar information from another Inficon Vapor Deposition Rate Controller (a Model SQC310) running at 19,200 baud and had zero issues... I contacted Inficon yesterday and all they have told me so far is that the "The 310 does not use HW handshaking for communication" (the implication being that the Cygnus must use such handshaking) and they went on to say that...
"It is possible that his LabView application may not be configured for using HW handshaking. Have him check his application settings for HW handshaking. It may be causing the Cygnus to become confused if it is not enabled or initialized correctly. He may also want to try the simplified 2, 3, and 7 (optionally pin 1) cable for the Cygnus. It would eliminate his HW handshaking communication lines and fix his communication problem."
Admittedly, I am not knowledgeable about how to properly setup this handshaking... I've communicated with several instruments using VISA serial WRITE and READ over the years and for the most part, you set up the baud rate, # of data bits, stop bits, what kind of parity and flow control if any and GO.... It's just worked... This is my first experience with an instrument that doesn't want to work with this LabVIEW code..
First, I assume I would set up or at least check handshaking via a property node (yes/no??)... Can anyone expound on how I might check this??? Second, any comments on their advice above that I build a simple serial cable that just wires up TX, RX and ground to make sure the hardware handshake lines aren't even hooked up???
Inficon told me they use some proprietary executable in house to talk serially with the Cygnus instrument and they aren't knowledgeable, and are therefor suspicious, that LabVIEW is causing the communication problems I ma seeing... I, on the other hand, am concerned this instrument, though currently manufactured and quite expensive (4 times the cost of an SQC310) is built on very old technology (it has a floppy drive on the front and the "monitor" is a CRT type screen that takes a number of seconds to "warm up" and "turn on" when you first power on the unit...
Any thoughts or advice on hardware handshaking and/or whether you think it would be a reasonable next step to "cut the handshake wires" on a special serial cable would be much appreciated...
The Cygnus unit can be viewed at the link below (also you can download its manual on that same page)
http://www.inficonthinfilmdeposition.com/en/cygnusthinfilm.html
thanks much... bob...
Solved! Go to Solution.
07-21-2010 12:19 PM
Bob,
Wow, that's a lot of info. I would try making a cable that does not use the handshake lines. I have run into issues with certain hardware that requires that the handshake lines be disconnected (in some cases shorted together at the hardware end) and that the only lines being connected are the Tx,Rx, and GND. The simplest thing to try is make a cable that has only pins 2,3,5 connected (obviously be sure to use straight through or null-modem wiring as needed).
Dan
07-21-2010 01:15 PM
If the device is set up for hardware handshaking, you cannot simple cut the wires. Here is how hardware handshaking works. I will call the Labview end as the computer, and the Cygnus as the device. If the device is setup for hardware handshaking, it will only send its data when it sees the CTS line high. I'm not sure which pin this is, you can look it up in the Cygnus manual. When the device wants to send data, it raises the RTS line (Request To Send). The computer sees this, and if it is ready to accept data, it raises the CTS line (Clear To Send). Then the device sends its data.
Lets say that the device is sending so much data, or at a high rate, that the computer cannot handle it fast enough. Normally that would cause a buffer overrun, and data would be lost. With handshaking, the computer end would know that it is running out of buffer space, and it would lower the CTS line. The device would see this and it would stop sending data. Then the computer has a chance to process the data, empty its buffer, then it would raise CTS again, resulting in the device sending more data. This continues until all data is sent, and the device drops the RTS line.
If the device requires hardware handshaking, and you don't want to use it, you can wire the RTS and CTS lines together at the device end. But this could result in loss data. Also, if using handshaking, the computer end must also be set up to produce the handshaking. I believe this is a parameter setting in the Serial Initilaize VI.
Since you are losing data, and since you must operate at a speed much slower than the device specs, you may have a bad cable. The cable should be shielded or you may have external interference, causing loss of data and forcing you to run at slower speeds. The shield should be grounded at the computer end only. Grounding at both ends could cause a ground loop, resulting in more interference. The wires inside the cable should be twisted pair to minimize the crosstalk between Tx and Rx. Use one wire out of a twisted pair for Tx, and the other wire out of the twisted pair to ground. Use a different twisted pair for Rx and Ground. This is not very important for very short cables, but the longer the cable, the more important it becomes. With extremely long cables, you may have to terminate the device end for the Tx line with a 100 ohm resistor to ground, and terminate the computer end for the Rx line with a 100 ohm resistor to ground. This eliminates reflecting waves. Termination is especially true when using flat ribbon cables of lengths longer than a few feet.
Just thought of something else. You say that after a while the data becomes corrupt. This is a classic example of buffer overruns. The computers (or the devices) input buffers start filling up faster than the computer can process the data. It my fill up very slowly if the processing rate is almost equal to the device sending rate. But after a while, the buffer becomes full, and any extra data coming in before the buffer is read will be lost. After that, more data will be lost quite often, resulting in corrupt data. This is why handshaking is so important. In most cases, the computer can process the data faster than the device can send it, and no handshaking is required. But your case may be different. Maybe you need the handshaking.
I hope you can find your problem using something I said.
07-21-2010 02:22 PM
Are you using a computer with a serial port or an adaptor from USB to serial?
Lynn
07-21-2010 04:23 PM
Hi... I am using a Keyspan 4-Port USB Serial Adapter (model # usa-49wg)... The computer itself only has one serial port (COM1) and we are already using that on another piece of hardware... I have certainly wondered about whether the keyspan is causing any issues but I use precisly this same device, even the same port while testing, to run the other Inficon device I mentioned in my post above, the SQC310, and it works fine every time, never an issue and it is running at 19,200 baud... We are evaluating this Cygnus device as a possible replacement for the SQC unit because the Cygnus as more capability in terms of how high you can set time constants and so forth in PID loops... But several times while struggling with this Cygnus comm, I have unplugged the serial cable from it and plugged it right into the SQC unit, turned it on and talked away... That is my way of trying to return to a baseline that I know works... But granted, as Inficon just told me, they claim the SQC does not use handshaking which seemed to imply (though they did not say such) that the Cygnus DOES use hardware handshaking... But those same folks are the ones in told me to try a cable with just TX, RX and GND hooked up (2,3 and 5) to see if that fixed my problem... ??? But in answer to your question, I am using a port adapter... Windows see this 4 port adapter as ports 4,5 6 and 7... It claims they look just like real serial ports at least as far as Windows is concerned...
bob...
07-21-2010 04:32 PM
Have you tried setting an inter-character delay? There are various examples that you can find if you do a search. I've had flaky serial communication that was fixed by this.
I also don't see anywhere you have tested the communication in Hyperterminal or some other terminal emulation program but that is something you should certainly do.
07-21-2010 05:00 PM
I did fire up Hyperterminal and tried to use it... I first tried the Hello command to the unit I know that works, the SQC310... It worked fine in Hyperterminal but note that the SQC wants me to send ASCII which I know how to do in Hyperterminal, ie., just type... But I then tried the Cygnus in Hyperterminal but it only knows input in HEX... I typed just the HEX numbers which I know well.. No go.. Then I tried the ASCII characters that are equivalent to those HEX numbers... No go again... Bottom line is I could not communicate with the Cygnus using Hyperterminal because I don't know how to input the characters it needs to see to work...
07-21-2010 05:08 PM
Here is what the Cygnus manual says about flow control..
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...
So how do I set up my VISA Configure Serial Port??? I see the following options under Flow Control
- none
- XON / XOFF
- RTS / CTS
- XON / XOFF & RTS / CTS
- DTR / DSR
- XON / XOFF & DTR / DSR
The Cygnus manual seems to be requesting a flow control option that is a combination that is NOT an option in the above VISA Configure Serial Port??? So what would I use instead???
thanks... bob...
-
07-21-2010 05:22 PM
Set up the flow control to none. Then modify your cable that has just 3 wires (TD RD Gnd). On the connector that connects to the device end, add a jumper wire from CTS to RTS and another jumper from DTR to DSR to DCD. This will fake out the handshaking. On a DB9 connector, the pins are as folows:
1 - DCD
2 - RD
3 - TD
4 - DTR
5 - Gnd
6 - DSR
7 - RTS
8 - CTS
9 - RI (ring indicator, not used)
If you start missing data or getting corrupt data, you may have to put the handshaking back. For this you will need a full cable, 9 wires straight through if using a DB9 connector. Then you will have to set up your serial port handshaking option to RTS/CTS.
XON/XOFF is called software handshaking. DTR/DSR just tell the computer and device that there is a connection. More like a status indicator.
07-22-2010 07:24 AM
Some USB to serial adapters do funny things with the handshaking lines. I had one several years ago which only asserted the handshaking lines while it was transmitting a character and released them between characters. The device with which I was trying to communicate got very confused because it expected those lines to remain asserted unless an interruption of the transmission was actually required. This behavior was not documented in the instructions or on the adapter manufacturer's web site. So if you decide to try to use the handshaking, verify what your adapter is actually doing.
Lynn