Crash course in PLC Hardware required for smart devices 3

[bdn2004]

What would be components of a PLC system that would do the following:

1) There are 20 smart devices in the field that talk Modbus.

2) Various other digital and analog devices.

3)The PLC is A/B ControLogix.

4)The PLC has to be redundant.

5)A remote I/O rack elsewhere 1000' away that takes in 10 -20 different devices.

It would seem to me that I would need a master controller, 20 Modbus cards to plug in the field devices, another controller, analog and digital cards, another card to plug in the Remote I/O - what kind? How do the screens connect? Do I need another card for them? Is a personal computer required? How does it connect?

As you can tell I'm a novice...can anyone help to get me on the right track? Thanks.

 

[jraef]

I'm no A-B expert for the rest of it, but typically a single Modbus card can talk to 32 nodes, so you don't need 20 different cards. That's why you use serial comms instead of discrete.


"If I had eight hours to chop down a tree, I'd spend six sharpening my axe." -- Abraham Lincoln
For the best use of Eng-Tips, please click here -> faq731-376

 

[danw2]

Some thoughts on Modbus:

I also am not an A-B guy, so I'd be looking to see how a remote I/O rack handles Modbus, if, in fact, the devices connected to it talk Modbus.

Prosoft used to make the Modbus cards for A-B (certified partner, or whatever A-B calls them) but I'm not sure how CLX handles Modbus.

One generic consideration is that Modbus RTU and Modbus ASCII do not mix on the same comm link, one is 8 bit, the other is 7 bit; Doing both requires putting one on one comm port, the other on a different comm port. So I'd want to know whether any of the field devices are Modbus ASCII format, to make sure there are sufficient comm ports.

A second consideration is whether the slaves have RS-485 or RS-232. RS-232 devices will need a 485 converter. I can't tell you how costly it was when I learned my lesson to buy 'isolated' converters. They cost more, but can save devices from devastating faults on the comm lines.

3rd consideration: I'm not sure whether turn around delay intervals can be set individually per request to a field device with whatever Modbus master driver CLX uses. Some field devices just take longer than others to respond and a universal/global short turnaround time might lead to time outs.

4th consideration: If I had that many field devices, I'd look at isolating segments with one or more RS-485 isolators, just so a devastating fault on any slave doesn't kill all the devices on the comm link. Did I mention isolation before?

5th consideration: Redundancy issue for the Modbus links. CLX does have redundant controllers. But redundant serial links? ? ? The kind that turn off when not in use?

Is there a Modbus slave device with redundant comm ports? There might be, the Modbus world is huge, but I've never run into one.

The redundant controllers I'm aware of use ethernet ports for redundancy. I'll bet CLX does redundant comms through ethernet. The question then is whether CLX can do Modbus TCP through either its native ethernet ports or whatever comm board/card it uses for Modbus. If it can, then one approach, if redundancy is a factor for the Modbus devices, might be to convert the slave devices to Modbus TCP with Modbus specific serial servers (Lantronix, DigiOne, Anybus) and use the ethernet fail over system to ensure that the native RTU-485 slaves don't choke on simultaneous polls from multiple masters. Pure speculation on my part, I've never done it, only postulating from your original scope. Doing so would only work if the serial server box could turn its serial side off when it was not the primary comm link. I'm not sure serial servers do that.

With regards to 'screens', an A-B distributor can tell you how many HMI panels a CLX can support.

The development software needed to program the PLC needs a PC. If you're asking about a PC to look at the data, then the PC would require some SCADA, DAQ or HMI software, all of which communicate over ethernet nowadays.

Tough job for a beginner. Is this an academic "grad student can spend forever on the learning curve" situation?

 

[bdn2004]

Danw2,

Just trying to learn something here. I'm seeking the big numbers, little converters things like that get caught in the percentage. We are trying to select between Road A, Road B, C or D.

 

[djs]

ControlLogix redundancy really requires that you use ControlNet for I/O. Yes they can use EtherNet, however during a switch over, comms on the Ethernet can be lost for seconds at a time. So connection to remote I/O rack should be ControlNet. One ControlNet bridge in each redundant processor chassis.
Prosoft does make a Modbus master card. The Modbus side pools the Modbus slaves somewhat independently of the ControlLogix processor. You set up a series of Modbus read and write commands within the Modbus master. And yes the whole idea behind intelligent fieldbus devices is to have all of them on one network with one master. BTW the modbus master module will need to be in a "remote" rack, not in the same rack as the redundant processors. Like wise all other I/O modules.

 

[bdn2004]

djs,

The product I want to hook up in the field has these specs...

Choose from Ethernet, Modbus® TCP, DNP3 LAN/WAN, IEC 61850 , Telnet, FTP, Modbus Serial, EIA-232, EIA-485, and DNP3 RTU protocols.

You say ControlNet for I/O...this is the I/O not seeing that on the list?

 

[djs]

ControlLogix redundancy requires two processor racks. Each processor rack must have at a min a power supply, processor, network bridge module and a redundancy module. No I/O modules should be placed in the processor chassis'. Also the configuration of each processor chassis should be identical.
Any and all I/O modules (discreet input, special network modules etc) must be placed in one or more separate racks. Each of these I/O racks must also have a network bridge module of the same network as exists in the processor chassis.
The network connects from one bridge in one processor chassis to the other bridge in the other chassis and then on to the various I/O racks. When the redundant processors fail over from one processor chassis to another, the bridge modules swap their node addresses.
In the case of ControlNet bridges, this occurs very quickly and is virtually unnoticeable. However in the case of EtherNet bridges, the address swap can and will cause a communications break. For this reason A-B recommends that ControlNet be used for all redundancy I/O.
Prosoft Technology offers network modules for DNP3, Modbus serial, and Modbus TCP/IP. You can use any of those protocols.

 

[bdn2004]

djs,

Here is an existing system in the plant. It is obviously not redundant. So to make this system redundant I'd need two of these identical? This has a UPS located at the bottom of this cabinet...is that the power supply you refer to or is one of these components shown the power supply? (when I say I'm a novice...I mean it.) Your also saying I'd have to have a network bridge to fill in a slot so the two communicate to each other and the I/O.

Is one of these like the master controller and the other only works on failure...or do they both get equal time?

You want to put the I/O on separate racks in case the processor rack fails....

How do you connect the I/O modules located in the other rack to the controller? I realize via the Control Net bridge module...but to which one? the main or the redundant controller?

 

[bdn2004]

oops here is the link

 

[djs]

A couple of notes on your photo. The processor is the module with the key and keyswitch. The unit to the left of the processor is the power supply for the rack. The module to the right of the processor is a standard A-B ethernet bridge module. Along side of that is a Prosoft ethernet module (what kind I can't tell).

Please note that the power supply still has it's label on the top. You should remove this immediately. It will cause the power supply to over heat!

You are correct that this processor appears not to be redundant. I have attached a photo (not very good) of a panel with a redundant processors and I/O racks.

 

[bdn2004]

Thanks for the info and photo.

Why would they purchase the Prosoft Ethernet module if A/B offers an Ethernet module? If you say its because its talking to a device that speaks a different language...is that what the Prosoft module is doing, that is conversion between A/B and the device so that they can talk?

I know this is programmed with RS View, but how do you do that? I would imagine, the RS View is located on a PC and we download it into the PLC. Is that done through the CPU, how does it connect USB? or some special cord I need to buy?

Thanks for the info on the PLC label...but this has been in for a few years!

 

[dV8r]

In the past where have failures taken place?
How many times has the processor failed?
What devices have failed?
In a typical system the field devices are the "weak link" not the processor. Maybe you should look into redundant field devices.

 

[catserveng]

Try taking a look at this,

http://literature.rockwellautomation.com/idc/groups/literature/documents/um/1756-um523_-en-p.pdf

The ControlLogix PLC is programmed with RSRogix 5000, the HMI software is RSView, either RSView32 (older) or RSView SE (newer). The HMI is developed with a "Works" program, and the HMI computer you have probably has a "Runtime" version of the program. Both programs use RSLinx as a communications interface.

The ProSoft card is likely MODBUS TCPIP or some other IP protocol, the AB ENET card only speaks AB/Rockwell.

There is a pretty good book on ebay right now on how to program controllogix PLC's covers a lot of the things you are asking about.

Hope that helps

 

[bdn2004]

catserveng,

What is the title of the book?

 

[bdn2004]

I noticed in that literature you linked to it said to keep CPU usage to less than 75%...how do you know when you are doing that? Then what?

 

[JohnWaa]

danw2 Wrote:

"One generic consideration is that Modbus RTU and Modbus ASCII do not mix on the same comm link, one is 8 bit, the other is 7 bit; Doing both requires putting one on one comm port, the other on a different comm port. So I'd want to know whether any of the field devices are Modbus ASCII format, to make sure there are sufficient comm ports."

I'm in the process of writing a Modbus (ASCII) data collector for some equipment at work. While in my quest to break my software in every conceivable way I selected 8 bit (RTU) communications for the comm port.

The *plan* was to observe what kind of errors the program spit out and to build some smarts into my program so that this kind of setup error would get trapped so I could alert the operator to his mistake (rather than me getting a call in the middle of the night).

To my surprise, my program had no trouble whatsoever with the bogus port settings. I also tried it with different stop bits and various parity settings and in some (most?) cases it worked just fine.

The only surefire way of hosing the communications was to select an incorrect baudrate.

One of the other differences that I found was that the Solo process controllers that I was talking to didn't care if I adhered to the 1 second turnaround time required by the Modbus spec.

This makes sense since if the device can handle RTU's 1 1/2 stopbit turnaround time, it should be able to handle faster ASCII transmissions.

But to get back to RTU and ASCII on the same network, I haven't tried this as of yet (but I plan to once I get back to California), but offhand I can't see any reason why ASCII and RTU can't coexist on the same network.

Don't get my wrong, it wouldn't be a good idea by any means to something as silly as this, but it looks like it could be done.

FWIW, I've written my data collector in BASIC using PowerBASIC and FireFly. The comm driver that comes with the PowerBASIC compiler is outstanding.

 

[catserveng]

Programmable Logic Controllers with Controllogix by Jon Stenerson

http://cgi.ebay.com/Programmable-Lo...m&pt=US_Texbook_Education&hash=item20b12efd67

 

[djs]

UARTS are surprizingly flexible on accepting data format changes. The critical ones I have found are baud rate and also parity.

Modbus over a serial comms link is a strict master/slave protocol. In addition, only one master is allowed. I suppose you can create a master that uses Modbus ASCII for one slave and Modbus RTU for another. However I do not think you could get a slve to reliably determine if it was being talked to in ASCII or RTU.

 

[danw2]

Johnwaa,

Well, if your master handles both Modbus RTU and Modbus ASCII interchangeably on the same serial link/COM port, more power to you; go for it. Most don't, believe me. The Modbus world has zillions (figuratively) of implementations, covering the spectrum from good to bad. Apparently, you have a winner. Good for ya.

Here's a sample of responses on the topic of simultaneous RTU/ASCII from another forum. I'm not sure Poster #2 understood the question (with a single master, there are no collisions, presumably). I fully agree with Linse's assessment, the last post.

http://www.control.com/thread/1026201324#1026201481

 

[JohnWaa]

danw2,

Well, if your master handles both Modbus RTU and Modbus ASCII interchangeably on the same serial link/COM port, more power to you; go for it. Most don't, believe me. The Modbus world has zillions (figuratively) of implementations, covering the spectrum from good to bad. Apparently, you have a winner. Good for ya.

Well, like I said in my previous post, I haven't tried it as of yet (I'm still in Kentucky). And like I also said in my previous post, I wouldn't ever seriously implement it.

But for curiosity's sake, I'm going to run a test just to see what it does. Why not? I'm entitled to a few "stupid programmer's tricks".

Just as long as that particular build doesn't ever leave my laptop. ;>

Here's a sample of responses on the topic of simultaneous RTU/ASCII from another forum. I'm not sure Poster #2 understood the question (with a single master, there are no collisions, presumably). I fully agree with Linse's assessment, the last post.

Me too.