Data Hwy slowing down

[digitalfist]

I have 10 A/B PLC 5's and 7 HMI's along with 3 computers on our data hwy. All the PLC's are messaging production data back to a computer that transfers it back to our LAN. All the HMI's are directly connected to the data hwy (rather than remote).

My question is what would be some idea's to help speed up the data tranfers? The main indicator that data is slow is the HMI's delayed reactions when a button is pressed. I would change the speed from 57k to 115k but some of the processor's do not seem to have a 115k selection. I would change them to 230k but I am conserned about the sensitivity of the data hwy at high speed.

Any suggestions would be appreciated incuding newer processor's. We are considering going to control logix but we have no knowledge or experience with them.

Thanks

 

[PhilipW]

You have not specified what the HMI's are, as this could make a big difference to how heavily loaded you DH+ is. Nor have you indicated what PLC's you are using. However what I can tell you is:

1. AB recommend a practical upper limit of 16 nodes on DH+ for reasons of performance. Clearly you are hammering hard on that limit.

2. Are the HMI's accessing multiple PLC nodes? If not then maybe you could make the connections to the PLC's directly to another spare port?

3. If the total length of your DH+ is less than 2,500ft and is correctly installed then I would definitely up your baud rate to 230k. Remember to change the termination resistors to 82 ohm at the same time.

4. Can you split the network into two segments? There are a number of possible ways to achieve this but we need more details about your system.

If you are considering ControlLogix then this suggests you are using older generation PLC5's. I have been using ControlLogix since it was first launched in 1998, and I think you will find that once you have mastered the inevitable differences, that you will love using it. ControlLogix (CLX) offers many significant improvements over the PLC5/SLC500 generation, although without knowing more about your plant it would be rash to start nominating which ones would be most important to you. Overall though, most existing AB PLC5 users will probably make the change to CLX sometime in the next few years, as the reasons to do so become more and more compelling.

 

[digitalfist]

The PLC's were using are 5/20 and 5/40. The HMI's are C/H panelmates and yes they do communicate to more than 1 processor.

When we started collecting production data management loved it so much that they just keep asking for more and more data. This is why i'm so concered since I see no end to the data collection.

I am interested in going to 230k but I am afraid that it will be ok when were down but come monday morning when the mill starts up I don't want to have the network crash.

What kind of network is available on the CLX? Is it faster and capable of more than 16 to 18 nodes? What would be involved to change from the older PLC5 to CLX?

Thank you for your response.

 

[PhilipW]

I will refrain from trying to specify a full PLC5 to CLX conversion for you by remote control, although I am tempted.

If you KNOW that your DH+ is installed according to the rules, then it is highly likely that it will run just fine at 230k. That is the first thing I would nail down...is my existing network running correctly?

Then there a bunch of things to take into consideration:

1. You state that the CH PanelMates are connected to more than one PLC, but do all the PanelMates talk to all the PLC's? If so can the network be logically split?

2. If it can then one simple way forward is to use a ControLogix bridge. CLX does not need a processor to do communications. All you need is one 1756-DHRIO module, (which has two DH+ or R.IO channels) and you can split the network into two logical segments. This simple step alone will greatly reduce the loading on your existing network.

3. Next you can add a 1756-ENBT or even a 1756-EWEB module to give you Ethernet comms to your data collection PC's. This will open up a whole new range of more flexible and powerful comms. (The EWEB module is a powerful little web server in it's own right and could take over some of the data presentation.)

4. Converting to CLX processors can be done several ways. If you have a lot of 1771 I/O the lowest cost method is to leave the existing I/O in place, rip the PLC5/20/40 processors and replace them with 1771-ASB's and then run back to 1756-DHRIO modules (in R.I/O mode) and then to new CLX processors.

5. Or bite the bullet and replace the whole lot with new 1756 processors, and I/O. This may be necessary if you have a lot of high speed I/O in the local chassis.

In either case there is a program conversion tool that will take most (but not all) of the pain out of converting the programs from PLC5 to CLX. But be aware that most people finish up writing whole new programs in order to take advantage of CLX's far more powerful data structures.

Overall I suggest starting simple and working your way through it step at a time. Much will depend on your budget and the resources available to you to make any upgrades.

 

[jstolaruk]

I'd first bump it to 230K (provided everything physical is right) and also look to see if the systems requesting production data are updating faster than they need to be. If a production counter updates every 5 seconds, is there a reason that the queries have to be faster than 2.5 secs. And finally, consider breaking up the one network into two or more.

 

[digitalfist]

I think I will try and bump it up to 230k first. We are expecting to get our first CLX in the next couple of months as a package with a machine upgrade. Where would be the best place to get started learning about the CLX software and its differences from the PLC5?

Thanks for the info!

 

[Oakley]

Once you get knee deep in ControlLogix, PLC5 will seem archaic and you will want to do everything on ControlLogix.

 

[RSL]

If you want to get a good start I would take a class if possible. It will take several weeks to several months to grasp everything that is going on depending on the person. With a class at the beginning you will save yourself a LOT of reading PDF's.

I was forced into a trial by fire aproach. I really would have preffered a good class or two to get jump started.

Obviously it is possible to learn it on your own, many have. The sooner you can get your hands on the software and start hacking around the better. It is very different from what you are used to.

Once you get the hang of it you WILL like it better than PLC-5-SLC500 style systems. It is a really powerful platform.

RSL

 

[Mark Buskell]

Another thing you might want to look at is how you trigger your message blocks. Are you using some type of timer to constantly poll the data. To many message blocks constantly transmitting can bring a network to a crawl.

Have you grouped the data together in one word? Instead of 1 processor having 5 different message blocks (N7:0, N9:0, N11:0. etc), can you group everything in say N25:0 and use those words for your message blocks.

When transmitting message blocks, look at the length. If you only need to send 5 words and instead you are sending 100 words each time, that can slow it down a bit.

One thing that worked for us is only triggering the message block on a change of data. For example, range speed rarely changes so only send send it when it changes and not constantly.

One last thing to look at is your cabling. Are you set up to AB specs and have everything daisy chained or are you using a trunk line. Make sure your resistors are in place at each end of the chain.

 

[DanWard]

WRONG...DH+ can have 72 nodes and 10.000ft of cable.....

 

[OkiePC]

NOT SO WRONG...DH+ can have 72 nodes and work just fine as long as there is no messaging going on!

What Phillip says about 16 nodes is correct. I try to stop at about 12 nodes.

What Mark says about grouping your tags in continuous blocks of PLC memory will probably get you farther than changing to 230k baud...unless it's already optimized.

You can also select the update rates in the PanelMates to help with data throughput. Usually a refresh rate of the screen takes about 1/2 second, so reading tags any faster than that is pointless unless you are timestamping alarms in the PanelMate. even then, the alarm tag scan rate has a separate frequency adjustment.

And, refine the message trigger logic as suggested too.

 

[Sheldn]

DH+ running at 57.6 K will generally give you 12 transactions per second. A transaction will have a maximum of 128 words of contiguous memory. Each request from each device will generate transactions (Panel Mate to PLC, PLC to PLC, HMI to PLC). If your driver software optimizes memory requests or allows for blocking of addresses as in Wonderware you may get lucky. A new transaction will be created any time you change a file type or file number or have more than 128 words or have a gap of more than x registers in the same file. In some cases getting 100 addresses is easier than getting 2 registers that are separated.

You will want to spend time setting up the data in the PLCs to provide for better optimization of transactions on the data link. Suggest setting up files in the PLC such as F100 to allow for floating point to be read and F101 for floating point writes into each PLC. You can do the same for bits and / or integers if needed. This way you can control the number of transactions created.

 

[Gerry]

WRONG...DH+ can have 72 nodes and 10.000ft of cable.....

Where did you pluck that number from?

DH+ node addresses are in the range 0 - 77 octal which yields a total of 64 (decimal) available addresses. The protocol is optimised for 16 nodes or less.

 

[Black Jack]

It sounds like you are outgrowing DH+ or you will if you continue to expand. I had the same situation years ago and started using the ethernet co-processor (1785-ENET) on the PLC 5's. You can leave the Panelmates talking on the DH+ network and switch your data aquisition, HMI, and messaging to ethernet. That way you will minimize the code changes and gain an incredible increase in speed.

The PLC 5 usually needs to be a series D or higher processor for the ethernet co-processor. The control logix ethernet bridge can be used to segment your DH+ comms and help out as well.

 

[Ron Beaufort]

OLD thread alert ...

this is another old thread that somehow has been brought back up again ... we seem to be having a rash of these lately ... as always, it's good to continue adding to the forum's knowledgebase - but I wouldn't worry too much about trying to "fix" the original poster's specific problem ... I'm reasonably certain that situation has all been worked out by now ...