Blast from the Past: SLC150 and Moore Data Gage II

[rootboy]

It smells something along the lines of Modbus...

Go here to get an idea as to the Poly (BTW, using a polynomial is a clear indication that should this actually be Modbus, then it's of the RTU flavor).

https://ghsi.de/CRC/

Next, get yourself a free Modbus monitoring program. I've included this link which I came across just the other day, it (along with Modbus DLLs) includes a monitoring program:

http://sites.google.com/site/shortbusdll

Or here:

http://www.modbusdriver.com/modpoll.html

Since it's likely that your PLC is doing nothing more with the data than decoding measurements, you don't need much in the way of a PLC driver. Something to decode the incoming message, and something to spit out the ACK back to the gauge.

No need for a protocol analyzer, unless you just want one, and this is a pretty good excuse.

Just tap into the 485/422 as you would with any other device on a Modbus network and listen in.

That said, I would forego the Modbus program and listen in using ReatTerm. While the setup here resembles Modbus, the CRC calculation doesn't follow either the RTU CRC (which uses Polys and shifting), or the ASCII LRC (simple XOR).

If you do log responses, be sure to post them here.

.

Here's my CRC routine (written in PowerBasic). It's my interpretation of a "standard" Modbus CRC routine. Notice that it uses a different (but standard for the Modbus world) Poly than the one in your code. So while it may be Modbus-like, I sense a bit of divergence (nothing all that unusual in the Modbus world). No byte swap or shifting either.

Sub CRC16ComputeB (MBStr$, Poly As Word, CRC As Word)   'calculate the CRC treating each character as one byte (Binary).

Dim tCRC As Word
Dim b$
Dim i%

If MBStr$ = "" Then Exit Sub                       'Not too much that we can do with an empty string.

tCRC = &hFFFF                                      'Seed tCRC with -1
Do While MBStr$ <> ""
   b$ = Left$(MBStr$,1)                            'Grab a character. 
   MBStr$ = Right$(MBStr$, Len(MBStr$) - 1)        'Now remove it from MBStr$
   tCRC = tCRC Xor Asc(b$)                         'Xor tCRC with the first byte

   For i% = 1 To 8                                 'If tCRC is an odd number, we need to shift it right on place and Xor it with the Polynominal (in this case, &hA001)
      If (tCRC And 1) = 1 Then 
         Shift Right tCRC, 1
         tCRC = tCRC Xor Poly
      Else
         Shift Right tCRC, 1                       'Otherwise, just shift it right one bit.
      End If
   Next i%   
Wend

MBStr$ = Hex$(tCRC)                                'The result needs to be byte-swapped (little endian to big endian) for the Modbus world
MBStr$ = Right$(MBStr$, 2) + Left$(MBStr$, 2)      'This gets the string swapped
CRC = Val("&h" + MBStr$)                           'And this gets you the actual value.

FF_TextBox_SetText (ByVal HWND_FORM1_TXTMODBUSCRC,  ByVal MBStr$)
End Sub

So that one way of doing it, and to the best of my recollection, it works.

Here's a discussion of the CRC16 code in (more or less) plain English:

http://www.control.com/thread/1026148035

So the bottom line is that you will have to do it their way. But you have the source, it shouldn't be too hard. Like I said, snoop in on the transmissions and post the results here.

 

[geniusintraining]

I'm not sure if I follow. Are you saying there is another way to access the data tables other than the ASCII commands?

Not sure on the protocol but the port on the 100/150 is a multi-port, RS232 (3 wire) / RS422 (4 wire) and 24VDC so just wanted to bring this up so you keep a open mind and not just stuck on the RS422 data converter, you should be able to get your data from the PLC via RS232 or RS422... not sure on the ASCII side I have never tried

 

[BW2218]

A long overdue update.



It turns out that Intra Corporation is the current owner of what used to be Moore Measurement Systems. I was able to make contact with one of their engineers familiar with the DGII. He sent me a PDF copy of Application Sheet 8057 Appendix G published in 1993 when the SLC 5/03 was considered a newer processor. Below are some of the pertinent highlights.

• The interface between the DATA GAGE II and Allen-Bradley's SLC-500 Family is accomplished via AB's Data Highway 485 (DH-485) or directly to a SLC processor's RS-232 port operating in the DF1 mode.
• This interface has been designed specifically for use with AB SLC-500s. The AB commands "Unprotected Read" (CMD=01; FNC=N/A) and "Unprotected Write" (CMD=08; FNC=N/A) are used to read/write data.
• All communications go through SLC File N9 which is called the Common Interface File or CIF.
• In order to enable SLC-500 communications, rockers 5,6, and 7 on the DATA GAGE II's serial I/O board dip switch must be set to closed.
• In order to communicate on the AB DH-485, the DATA GAGE II requires a destination node address and a data table offset.
• The destination node address is the DH-485 node number of the SLC-500 with which the DATA GAGE II is to exchange information.
• The data table offset number identifies the starting location within the SLC-500's CIF (File N9) through which all data exchanges with the DATA GAGE II will take place. At least 8 words starting at this location must exist in the SLC-500's CIF and be available for use. This document assumes that the CIF is defined as Integer. The CIF can be up to 256 words in length (but only 8 are used for DG communications).
• The SLC-500 interface is between the DATA GAGE II's "AUX" port on the serial board and a RS-232 port on an Allen-Bradley 1770-KF3 or 1747-KE Communications Module. These modules provide a RS-232C interface to AB's DH-485. In addition, some newer SLC processors like the SLC 5/03 have a built-in RS-232 port which can be operated in Full Duplex DF1 mode.
• The AB Communications Module or built-in port requires the following setup for its asynchronous RS-232 port: Full Duplex Protocol (DF1), BCC Error Check, No Embedded Responses, Accept All Messages Regardless of Duplication, Use Handshaking Signals, Station Address (any unused address), 9600 bits per second, 8 bits per character, No Parity, 1 Stop Bit, Execute Received Diagnostic Commands, RS-232-C Communications
• The DATA GAGE II's "AUX" port pin out: 1=SHD, 2=RXD, 3=TXD, 4=RTS, 5=CTS, 6=DSR, 7=COM, 8=DCD, 15=DTR.

Using this information, I have attempted to get the DGII communicating with a MicroLogix 1200 via Channel 0 in DF1 mode. Unfortunately, the communications dialog won't allow me to setup this channel exactly the same as what they listed. The one problem seems to be lack of a station address for DF1. There is no way to set this in the MicroLogix when using DF1. Isn't it always 1 and the host computer always 0? The Source Link is set to 1. Should this be set to 0?

FAQ (before they are asked)

Yes, I have an N9 file in my ML1200 program.
Yes its size is 8 words long, N9:0-N9:7.
Yes, I have rockers 5,6,and 7 set to CLOSED. (However, I did have to swap out the serial i/o board and communications chip. The old board was acting flaky for lack of a better word and the chip in the replacement board didn't support PLC communications.)
Yes, I have a node address of 001 and a data table offset of 000 entered in the DGII according to the example they give.
There is a male 15-pin cable connected to the DGII "AUX" port. It is wired to a DB9 terminal board. There is a 1761-CBL-PM02 cable attached to the DB9 connector and plugged into the ML1200's Channel 0 port (on the front).