Blast from the Past: SLC150 and Moore Data Gage II

Okay, I'm new on the job, been there a whole week, and I get my first upgrade project. This is basically why I am there. I am an "expert" and they really need one to help update the plant equipment. So my task is to convert an old SLC150 to something newer. Equipment is only expected to be in use for approximately two more years so a MicroLogix 1200 seems like the best choice. We have them around, still an active part number with AB, etc. The machine is a test stand that checks the OD of a part. The operator wants to be able to put it in auto and smack the two handed palm buttons to clamp the part, run the test, and get back a result. It used to work that way but quit for some unknown reason a few months back. They now have to run it in manual and hold the rotate button while it rotates underneath the LVDTs that check the part. The actual data collection and pass/fail is done by a Moore Data Gage II. They rotate the part manually until it gives them the result.

So manager says, let's just upgrade and get it working in auto again. Easy peasy, will look like a hero. Except, one problem. It turns out that the Data Gage II has a cable from it's Program I/O port to the SLC150 port. There are a handful of addresses in the 700 range that don't have an OTE which would indicate they are being written to by the Data Gage.

So now what? I have no documentation on the Data Gage whatsoever and it doesn't appear that I am going to get any since the OEM has already been contacted and provided nothing. I have no idea how to interface the Data Gage to something newer like a MicroLogix. So I am thinking I just need to punt and try to get the SLC150 working in auto again. I just finished setting up an XP laptop with DOSBOX and PCIS to try on Monday. I have an uncommented printout of the program but no electronic copy. At the very least I can get the program uploaded, commented, and checked. There doesn't appear to be any sensor issues and from what I can ascertain in the program, it is probably waiting on something from the PC that it isn't getting.

Use the "Search" button at the top of the webpage to find a lot of info about this plc. Use search terms "pcis" "slc100" "slc150" (without the quotes). Also, search user name "geniusintraining".

I appreciate the help but my real question is how to replace the SLC150 with a MicroLogix and have the new ML communicate with the old Data Gage II. I more or less have enough information to figure out the SLC150 side but I have nothing on the Data Gage II. I've already been through the old posts from geniusintraining on DOSBOX and the PCIS software. I just don't have a clue how to make the ML1200 emulate a SLC150 in a similar fashion to the way ControlLogix will emulate a SLC/50x or PLC5. This isn't an easy direct replacement where I can just unhook the I/O wires from the SLC150, hook them up to an ML1200, convert the program, and everything be happy. I have to deal with the virtual I/O from and to the Data Gage as well.

Zip and post the uploaded file from the plc. Maybe someone here can help figure out what the Moore device needs. Also post all the info you can about the model numbers, etc. on the Moore. Plenty of people here are willing to help.

You know, I just realized I have the SLC 150 communication protocol manual. In the course of looking it over, it occurred to me that all I should need is a protocol analyzer to determine the exact ASCII strings that the Data Gage is sending. Then, I should be able to write some code in the ML1200 that will intercept these transmissions from the Data Gage and respond with the same ASCII format that the Data Gage expected from the SLC 150.

Monitoring the ASCII strings traffic is certainly a good approach. Looking at the SLC150 programming might contain some clues based on the message writes and reads. It has been a very long time since working with the SLC150, my memory is quite dim.

I love a good challenge.

I'll bet you a box of donuts that the data gauge is using SLC-150 native data access commands that will look like gibberish in ASCII. And the SLC-150 is old enough that I don't think its data access language has anything in common with even the PLC-2 or SLC-500 Fixed controllers.

To make it more fun, we have the SLC-150 physical port. If it were ordinary RS-232, we wouldn't need that 1745-PCC module.

Some screenshots I've seen of old SLC-150 manuals suggest the port has TX and -TX and RX and -RX data pins, suggesting 4-wire RS422 or RS485. There's a USB version of the 1745-PCC sold by Industrial Concepts so the owner (a Forum standout) will probably know what signal levels are there.

So your first step is going to be to determine the SLC-150 physical port pinouts and signalling type, followed closely by putting a protocol analyzer on the line.

The best value for the money in serial protocol analysis is the Stratus Engineering EZ-Tap. I have both the Classic and the VersaTap (232/422/485) model, and they are fantastic little devices for intercepting serial data.

This is a blast from the past. First I ever programmed was a SLC100 with a hand held back in the 80's at a Westinghouse plant in Puerto Rico. Well, that was after I had to rewire the machine and replace the NEW SLC100 and expansion unit. Local electrical guy kinda messed up on this rebuild/upgrade and was really good at producing grey smoke. Kinda strange, but he got paid and A-B sent new hardware next day air for free.

Only SLC150 I know of is at an amusement park on a ride that's still running. Last year we had to go in and suck all the program's off this stuff, just in case.

I know this isn't any help, but it is a blast from the past.

Thanks for the tip Ken. I was going to ask if anybody had any suggestions for a good serial protocol analyzer. According to Publication 1745-2.15 regarding the 1745-PCK Personal Computer Interface Kit, the signal from the SLC 150 is indeed RS-422. I have already sent an email request to purchase the cable from Industrial Concepts just so I can use the Dell WinXP laptop (running Dos-box) instead of the old Pentium 133 with DOS they've been using.

According to the protocol manual (Publication 1745-2.11), I should see one or more ASCII strings like the following for reading bytes from the SLC 150. All numbers are two character hexadecimal.

#0502 <number of bytes> <address> [ID] [CRC] <cr>

The expected response from the SLC 150 is:

:<number of bytes> <address> <data byte(s)> [ID] [CRC] <cr>

If I understand correctly, the number of bytes is limited to no more than 2 so it should be 0001H or 0002H. The address is anything from 0000H to 0112H but will most likely be in the range of 00A6H to 00BAH since those represent the internal relay table addresses of 701 to 868. The first two bytes representing addresses 701 through 716 seem to be the addresses that the Data Gage is writing to. I'm not sure yet which ones are being read but I am reasonably certain there is a read command somewhere.

So in theory, if I received the following: #0502 0001 00A6 01 4A 0D
and the hexadecimal value of bits 701 through 708 were 0111 0110
I would respond with: :0001 00A6 76 01 4A 0D

NOTE: I was too lazy to calculate a proper CRC for this example so it is arbitrary. The ID is incremented with each command so it can be anything from 1 to 127 decimal or 01 to 7F hex.

The write command format is:

#0403 <address> <data byte> [ID] [CRC] <cr>

and the SLC 150 responds with:

;R [ID] [CRC] <cr>

So using a similar example the Data Gage would send: #0403 00A6 76 01 4A 0D
and I would respond with: ;R 01 4A 0D

The one thing I am not sure about is the physical connection. Can I connect the Data Gage communicating via RS-422 directly to the MicroLogix RS-485 port?

The MicroLogix only has two pins for RS485, so it's half-duplex only. You might get away with connecting Data A to RX and TX, then Data B to RX- and TX-. The presence of a transaction ID number suggests that it's really a full duplex protocol, but since it's just one device talking to one other device, in practice it might be half duplex.

But it's equally likely you will need an RS-422 to RS-232 converter that's suitable for "4 wire" mode. B&B Electronics are my go-to guys.

The Versa-Tap does have RX+, RX-, TX+, and TX- terminals, so it will be able to intercept this data from the existing connection.

It's going to be a significant challenge to effectively calculate a CRC inside the MicroLogix.

If the DataGaugeII is only Writing to the MicroLogix, you might just get away with a limited calculation based on the transaction ID number.

Thanks for that interesting information about the protocol !

According to the manual:

"[CRC] is a 2 digit hexadecimal number representing the Cyclical
Redundancy Check for the message, derived from the <byte count>
<command code> <parameters> and [ID] fields using the polynomial
X**8 + X**6 + X**5 + X**4 + 1"

I'm not really clear on what the polynominal is telling me. Does the ** mean "to the power of" or just "multiply by"? I'm a bit fuzzy there.

It is my understanding that the SLC 150 is just verifying that the CRC is correct and then sending back the CRC it received so that the sending device can confirm the message was received correctly. I could just strip out the CRC and send it back without doing any error checking but that wouldn't really be proper. They give an IBM BASIC example of how the CRC can be calculated but I'm scratching my head on that one as I never wrote much BASIC. I'm familiar with C and structured text in general so it isn't completely over my head but a few lines I'm not sure about.

10 DIM G(16)
20 FOR I=0 TO 15
30 READ G(I)
40 NEXT I
50 INPUT “Enter data string";A$
60 CHECKSUM=0
70 FOR COUNT=1 TO LEN(A$)
80 CHAR = ASC (MID$ (A$, COUNT, 1) )
90 FOR J=1 TO 2
100 INDEX=(CHECKSUM XOR CHAR) AND &HF
110 CHECKSUM=INT(CHECKSUM/16)
120 CHECKSUM=CHECKSUM XOR G(INDEX)
130 CHAR=INT(CHAR/16)
140 NEXT J
150 NEXT COUNT
160 PRINT “The SLC CRC checksum byte is ”;HEX$(CHECKSUM)
170 GOT0 50
180 DATA 0,23,46,57,92,75,114,101,184
190 DATA 175,150,129,228,243,202,221

Lines 100 through 130 are unclear to me as I'm not sure how they relate to the polynomial. It doesn't appear that it would be too difficult to strip out the CRC and verify it using standard MicroLogix instructions if I could better understand the calculation.

As to the physical connection, I assume the best bet would be to set Channel 0 to ASCII and connect a 1761-CBL-AP00 from Channel 0 on the MicroLogix to the RS-232 D sub on something like a B&B SCP211-DFTB3.

The pin out for the 8-pin SLC 150 connector is:

1 = !RXD (from remote device to SLC )
2 = RXD (from remote device to SLC )
3 = TXD (from SLC to remote device)
4* = GND
5* = +12VDC to +30VDC
6* = +12VDC to +3OVDC
7* = GND
8 = !TXD (from SLC to remote device)

"* These pins provide power from the SLC to the pocket programmer. They are
not used for communication."

! = my way of trying to show what I interpret as the NOT --- over the top of the RXD and TXD in the manual. I assume this is really -TXD and -RXD.

So the wiring for the RS422/485 terminal block on the SCP211-DFTB3 would be:

Existing Pin 1 wire to terminal RDA(-)
Existing Pin 2 wire to terminal RDB(+)
Existing Pin 3 wire to terminal TDB(+)
Existing Pin 4 (and/or Pin 7) wire to terminal GND
Existing Pin 8 wire to terminal TDA(-)

Does this look about right?

In general, CRCs are calculated on the data packet that's being transmitted, and the only time you will find an identical CRC on a reply is if the reply is literally an echo of the incoming data.

I'm not brilliant with CRC calculations and end up plugging them into various Web-based calculators and comparing them to real-world values until I hit on a combination of polynomial, seed value, and byte order that is correct. That's just one of the reasons why I don't write firmware.

There's a CRC calculation routine for ControlLogix that's part of the Logix 5000 Modbus RTU example code. It's been a while since I looked at that.

Thanks for the plug Ken...

Ken Roach said:

But it's equally likely you will need an RS-422 to RS-232 converter that's suitable for "4 wire" mode.

Click to expand...

We also have data converters http://www.plccable.com/data-converters-rs232-rs485-rs422/

For our serial version of the PCC we use the RS422 to RS232 yes its a 4 wire

They also have a back door on the port that works good for RS232, I will have to look it up if you need it (if I can find it) we are closing this week and moving over the holiday so if you need it call me and I will see if I can help, this maybe what Data Gauge is and not ASCII

Best of luck
Mark

geniusintraining said:

They also have a back door on the port that works good for RS232, I will have to look it up if you need it (if I can find it) we are closing this week and moving over the holiday so if you need it call me and I will see if I can help, this maybe what Data Gauge is and not ASCII

Click to expand...

I'm not sure if I follow. Are you saying there is another way to access the data tables other than the ASCII commands? If the Data Gage isn't using ASCII, then I may be really screwed. My assumption would be that it is using the ASCII commands described in the SLC 150 communications manual which details the protocol for reading and writing bytes from and to the SLC 150 data tables.

I had our purchasing guy order the VersaTap that Ken recommended so that I can see what is being passed. Its supposed to be there tomorrow. Hopefully I'll be able to make some head way on that part this week. In the meantime, I've converted most of the code over now. I noticed today that there are a handful of internal bits in the 800 range that only have OTEs so I would assume those are the bits being read by the Data Gage. I'll figure it out eventually. Just more time consuming than I originally thought.

Does the ** mean "to the power of" or just "multiply by"?

Click to expand...

X** means X^ or X raised to the power of.

Lines 100 through 130 are unclear to me as I'm not sure how they relate to the polynomial.

Click to expand...

They don't seem to relate to the polynomial expression that you gave earlier. The lines of BASIC code are creating a CRC checksum based on the 16-number series of Data values in lines 80 and 90. The array G(I), where I = 0 to 15, is set equal to those 16 numbers. I will try to describe what the lines between 100 and 130 are doing (based on my faulty memory of BASIC from 50 years ago)!

Lines 100 to 130 are inside two For-Next Loops. On the first pass, Count = 1, J = 1, G(0) = 0.

100: A$ is the data string that was enterd to be checked.
100: CHECKSUM will evaluate to 0
100: CHAR = ASCII value of (MIDSTIRNG$(A$, 1, 1)) = value of 1st character of A$
100: INDEX = (CHECKSUM Exclusive OR CHAR) AND &"HF" = (0 XOR ASCII value of 1st character of A$) & "HF".
If ASCII value of 1st character of A$ = 0, then
INDEX = (0 XOR 0) AND "HF" = (0) AND "HF" = "0HF"
If ASCII value of 1st character of A$ is NOT 0, then
INDEX = (0 XOR 0) AND "HF" = (1) AND "HF" = "1HF"

110: CHECKSUM = INT(CHECKSUM/16) = Integer(0/16) = 0

120: 120 CHECKSUM = CHECKSUM XOR G(INDEX) = (0 XOR G(0)) = (0 XOR 0) = 1

130: CHAR = INTEGER(ASCII Value of 1st character of A$ / 16)
(The maximum ASCII value is 127, so the value divided by 16 can be any number from 0 to 127/16 or 0 to 7.9. The CHAR value then will range from 0 to 7.)