First Experience - Allen Bradley Point I/O 1734-232ASC Devicenet

Article ID: 80

Last updated: 13 Oct, 2010

For those of you that aren't familiar with my writing style, this article is what I call my first experiences. This does not mean this product is brand new on the market, but rather the first time I've personally had an integration application using this product. I will also share my learning curve ratings at the end of my first experience articles.

I had another one of those opportunities to integrate two ASCII type devices using old school Allen Bradley SLC 500 technology. Of course, I've never had a chance to use a Control Logix based system yet, so what do I know. My project consisted of a Toledo Meter scale and an EPD bag printer from ID Technologies. On my scale, I needed to read the scale value and compare this weight to a comparison pass or fail condition. On my EPD printer, I needed to populate a serial variable with a bill of material consisting of a five-digit number. Normally, if I had only one serial ASCII device, I have traditionally used the front port on my SLC 5/03 CPU. Additionally in the past if I had more than one serial ASCII device, I normally would have just bought a Basic Module and wrote my own serial to PLC driver in basic language. I knew I wanted device net on my system and my local Allen Bradley distributor turned me on to point I/O and this new 1734-232ASC (ASCII) module that I could put on device net and control a serial port device. I was kind of skeptical, one because I've never used point I/O, two because I didn't know how to get serial information to and from the device net through the M files of the CPU. I did some research and I could not find any knowledge base documents or whitepapers where these modules are used in conjunction with a SLC CPU. Naturally, my "just wing it" instinct kicked in and here I am.

The first thing to do is configure this device on the device net network. With RS Networx up and running, I decided to keep these two devices as close to the scanner master module as possible with a low node number. Each device out of the box comes configured as node 63. I recommend that you only plug in one module at a time until your able to change the node number with the device net commission node wizard.

Commissioning this device was simple, actually the whole Point I/O system came up really quick and I had zero problems.

The next thing to understand is how many bytes this device consumes. Originally I left all the defaults alone. 24 bytes input and 24 bytes output. Upon mapping this device into the scanner list, I opted to map the I/O to the M files. Later on, I needed to transmit more than 20 characters to the printer, so I change the ASCII module controlling the printer to 48 bytes input and 48 bytes output to give me 40 characters of two-way traffic. I'll explain this later.

After mapping this device into the scanner module next I configured the module to talk to my scale. The Toledo scale only requires a TX, RX and Signal ground connection, pins 2,3 and 5. There are no hand-shaking protocols supported in the printer, so setting up communication was pretty easy with this device.

I set-up a default communication setting of 8, none, 1 and 9600 baud, pretty traditional stuff going on here. The only thing different was I had to enable 2-byte swap on the receiving end. The SLC CPU and this device are byte swapped so this caused all the ASCII characters to be swapped with every other letter. You can choose to enable byte swap for receiving or transmitting. I enabled byte swap on the receiving end, but left this setting to none on transmitting. I actually cheated and used the SLC instruction called SWP instead. I did this because this naturally caused a toggle to the transaction ID byte in this module, which sent the information every time the SLC SWP function executed.

Communication to the scale was pretty easy. I just setup a time-based query. Every so many sub-seconds, I queried the scale for the weight. The cycle time of the machine wasn't that important and a timer query of 0.5 seconds worked well. During the query I monitored the transaction ID incoming from the printer to make sure communication had taking place. After sending the correct ASCII strings from ST18 memory location by copying the register from ST18 into the device net word file of N10 I had setup I then did the byte swap in the PLC rungs, which naturally toggle the send transaction ID. When the send transaction ID is toggle, the module then reads what is in the device net N10 memory area and transmits your ASCII data. Then the printer received the ASCII instruction I had sent, it replied with ASCII data. Which had to be parsed. All the ASCII data arrived into device net file N11 I had setup for device net mappings. Once the string was received, I could then do an AEX instruction, which began extracting the string into a more readable format. In my scale example, I was required to extract the scale weight value from the string. Once I got the number data all by itself, I was then able to convert the ASCII number to integer. Since my scale was sending decimal place values, I created two integers. One integer file was created for whole numbers and one for decimal numbers. I then used real number math to add the two integers together into an F8 memory area of the PLC and now could do some comparing of high weight or low weight. The method I described for ASCII communication is pretty typical for any serial device you should encounter.

One of the best features I liked about this module was the ability to monitor this device "online". You can bring up the parameter box above and click monitor. You then can see the data arriving and leaving this ASCII module. Very powerful for debugging. This is where I noticed the byte swap issue I was having. If I sent the string value" "The cat jumped over the fence." I would see the results online inside the module as: "hT eac tujpmde oev rht eefcn e" <-- byte swapped.

The second best feature is your unlimited flexibility of formatting your ASCII strings. There are tons of "limiters, delimiters, etc" settings at your disposal. I think over 30 parameters you have control of how you need your ASCII data formatted. That's a powerful tool in my opinion.

Besides being sold that this is the way to go for adding multiple RS-232 devices to your PLC system it was allot easier than I thought. No more channel-0 programming or basic module required. You can add as many modules as you have empty nodes on your device net. The disadvantage when using a SLC PLC, is that you need to make sure you got your byte swapping in place. I was told the Control Logix PLC is different and doesn't require byte swapping to correct the ASCII strings in the PLC.

I'll go over one pointer for you. The amount of data you can send and receive to this device is controlled by your device net mappings. Out of the box, the device will try and trick you into thinking you only need 24 bytes in and 24 bytes out to communicate with this module on device net. When in fact you can allocate more bytes for more characters. This is what happens when you've hit that limit 24 byte limit, it's called the "karate-chop".

So you've gotten the hint I think this module is awesome. But I did find one problem. I wasn't able to find an answer to my problem so I hope you readers will respond in the comment box at the bottom if you know the answer.

I wanted to clear the receive buffer some how in the module itself. Once my module received ASCII data from my RS-232 device such as the scale or confirmation from the printer, the ASCII data remained in the buffer. So if I accidentally queried the device again, I got the same data. The query was controlled by rungs, which read from the N11 memory area of the PLC. It was hard to determine if the data being received was old or new because of the stale data from the query previous. You couldn't just monitor the transaction ID because it would increment and still give you the same data. If your using a Control Logix, you can clear this data by research knowledgebase article at Rockwell that explains how you can clear this in a Control Logix, but I saw nor found anything that explains how to do this in a SLC PLC. Needless to say, I got it working anyway after I saw what was happening. Even if you clear the N11 register in your PLC, the buffer is refreshed from the device itself and keeps replacing the data you just erased from memory N11. If you mess with this module, you'll understand what I mean soon enough.

Learning curve rating:Curve 0 = Walk in the park.Curve 10 = Get out the scholastic cap and crash in the classroom.

I gave this device an 8 because you should be well experienced in device net configuration by now, and know how to manipulate ASCII strings. Or at least done this the old way a long time ago. If you've never done channel-0 ASCII, then you won't appreciate this little gem.