FieldPoint Family

cancel
Showing results for 
Search instead for 
Did you mean: 

cFP Serial Port Problem - Long Strings Garbled

I'm working on a system to log data from a cleanroom facility.  I'm developing with LabVIEW 8.5 on a WinXP PC and targeting a cFP-2100.  Both the PC and the cFP have FieldPoint 6.0 and NI-VISA 4.2 installed.

One of the devices I'm logging from is a MetOne A2408 laser prticle counter system.  The interface is via RS-232 over a 9 pin serial cable.  I'm using the VISA serial interface to communicate between the MetOne and LabVIEW.  RS-232 parameters are 9600-8-N-1 with no flow control.

Everything works perfectly when I run the system on the PC, connecting to the MetOne via the PC's COM1 port.  Most of the commands to the MetOne are a single character, and the reply is a few characters (< 10).  The exception is the response to a request for a sample record from the MetOne (that's the data I want to log).  It's a 78 byte string; typical example:

A  022008 120212 0057 0.5 105003 5.0 000158 FLO 000000 LOC 000017 C/S 000C24

(The 78 bytes includes a CRLF on the end, for anyone whose counting 🙂

My problem arises when I deploy the system to the cFP-2100 and use its COM1 port.  The commands to the MetOne work fine, and short response strings come back fine, but the 78 byte string of sample data comes back partially garbled, for example:

A
<<228<<<12<<468<<578<.5<1<58<385.8<<<<15<<FLO8<88<918LOC<<<<<178C/S8<<<C33
Š

(The line breaks are there in the string, though not always in the same places.)  I've checked and re-checked baud rate, parity, etc.  If any of those are set incorrectly, I have no communication between the cFP and the MetOne.  It's just the long string that gets messed up.  The <10 byte responses are always fine.

I've stripped the cable down to its bare essentials (pins 2 and 3 only) thinking that perhaps there is a noise issue.  No help.

Any suggestions are welcome.  I've run out of ideas...

Doug Latornell
MDS Nordion, Vancouver
0 Kudos
Message 1 of 3
(6,481 Views)


dougl wrote:

I've stripped the cable down to its bare essentials (pins 2 and 3 only) thinking that perhaps there is a noise issue.  No help.

Any suggestions are welcome.  I've run out of ideas...

Doug Latornell
MDS Nordion, Vancouver


You say only pins 2 and 3 are essential, but pin 5 the ground pin is essential as well in RS-232 communications because the transmit and receive pins are referenced relative to the ground pin.
0 Kudos
Message 2 of 3
(6,477 Views)


@Ravens Fan wrote:


@dougl wrote:

I've stripped the cable down to its bare essentials (pins 2 and 3 only) thinking that perhaps there is a noise issue.  No help.

Any suggestions are welcome.  I've run out of ideas...

Doug Latornell
MDS Nordion, Vancouver


You say only pins 2 and 3 are essential, but pin 5 the ground pin is essential as well in RS-232 communications because the transmit and receive pins are referenced relative to the ground pin.


Thanks for the reality check, Ravens Fan.  Pin 5 was the missing link.  The instrument documentation said pin 7 was ground, but I've come to the conclusion that is probably an error held over from when they used to use a 25 pin serial port.

So, with pins 2, 3 & 5 I've got good, realiable communication of both short and long response strings.

Thanks for the help...

Doug Latornell
MDS Nordion, Vancouver
0 Kudos
Message 3 of 3
(6,450 Views)