Semi-intelligent gate controls

Remote IO is likely the way to go. It will just be a pain to retrofit the existing hardware plates and mounting, boxes, wiring, etc.

You might want to consider the new 5069 CompactLogix family since local control capability in case of Master failure would be sought after in mining environments.

The 5069-L306ER with one 5069-IA16 (16 x 120/240 VAC Input) and one 5069-OW16 (16 x NO Relays) will cover a 'footprint' similar to the ML1100 and have similar power requirements; the 5069 CompactLogix CPUs have two Ethernet ports which could be used independently or as parts of a DLR.

Obviously, you could Produce/Consume to/from the L73 and each gate controller for 'normal' functionality or implement local control when the Master is not available.

The above setup will run you some $2000/instance just a bit above the proposed Point I/O Remote racks, however, with a minimum of install costs.
 
Last edited:
If the heat is a problem then clearly multiple 1100 would not be a good choice.
The would be more susceptible to heat problems then remote IO and much harder to replace then a IO if one were to fail. not accounting for the 1100's could fail and open the gate and you would not be able to close it
The key here is the communications no matter what you use ease of replacement of failed parts. The personnel on site can easily replace an IO module replacing an 1100 is altogether different thing

Also let not forget about the E-Stop controls that must be installed to make the system up to code. This is a far more compacted system then just the gates open and close
 
Is it 35 messages of unique 16 bits of data or 35 messages of the same 16 bits of data? If it is the latter, save yourself some money and hardwire a 24vdc signal from the L73 to the ML1100's the interlock data. Wire is cheap and if you have the conduit space this is a no brainer. It may not be as ***y as remote IO, but it will get the job done.
 
You might want to consider the new 5069 CompactLogix family since local control capability in case of Master failure would be sought after in mining environments.

The 5069-L306ER with one 5069-IA16 (16 x 120/240 VAC Input) and one 5069-OW16 (16 x NO Relays) will cover a 'footprint' similar to the ML1100 and have similar power requirements; the 5069 CompactLogix CPUs have two Ethernet ports which could be used independently or as parts of a DLR.

Obviously, you could Produce/Consume to/from the L73 and each gate controller for 'normal' functionality or implement local control when the Master is not available.

The above setup will run you some $2000/instance just a bit above the proposed Point I/O Remote racks, however, with a minimum of install costs.

This sounds pretty good. I would rather not introduce Compactlogix ... but I guess the micrologix 1100 is getting old, the file system is kinda retro when you get used to ControlLogix ... Compactlogix programs a lot more like ControlLogix.

I dabbled in Produced/Consumed between ControlLogix (I mentioned messages to the other 10 ControlLogix) and it worked well when the L63 and L73 were in the same rack. Not so great when I started to decentralize the control and put the L73 into MCC rooms. It ate up all of the bandwidth ... and I could only add or remove tags when ALL of the ControlLogix could be downloaded ... like once a year.

With Loadout (the system we are talking about) Produced/Consumed to CompactLogix would get rid of my messaging mess. I think this sounds pretty good.

How 'new' is the 5069? I try to stay away from the bleeding edge ... a year for major software releases, 1 - 2 years for 'new' hardware from rev 1.0

The Rockwell literature seems to show it is the same release window as the L8x?
 
If the heat is a problem then clearly multiple 1100 would not be a good choice.

The ML1100`s have worked OK. I have replaced 3 of them since 2009. Unfortunately I had to visit site each time :(

The would be more susceptible to heat problems then remote IO and much harder to replace then a IO if one were to fail. not accounting for the 1100's could fail and open the gate and you would not be able to close it

It could happen I guess. But the failures failed in the closed state. The failures were discovered when they did not open as requested. The relays remained de-energized, in their fail-closed position.

The key here is the communications no matter what you use ease of replacement of failed parts. The personnel on site can easily replace an IO module replacing an 1100 is altogether different thing

Yes. Pulling a new controller from the warehouse and installing it, and getting it to a state that I can download to it from off site ... I`ll have to check into!

I heard a rumor from a Cisco guy that their IE4000 switches support DHCP ranges per port. So I could configure the switch to assign anything plugged into THIS port with a range of 10.48.134.101 to 10.48.134.101 ... essentially allowing the PLC to be set for DHCP, but forcing the PLC to take a static IP.

The only downside I could think of is changing which port you are connected to on the switch for troubleshooting .. would not be available.

Also let not forget about the E-Stop controls that must be installed to make the system up to code. This is a far more compacted system then just the gates open and close

The E-stops are on the 3 belt conveyors. They are not inputs to the Micrologix. I probably did not explain that well. I tend to go off on tangents and get people confused.
 
Is it 35 messages of unique 16 bits of data or 35 messages of the same 16 bits of data? If it is the latter, save yourself some money and hardwire a 24vdc signal from the L73 to the ML1100's the interlock data. Wire is cheap and if you have the conduit space this is a no brainer. It may not be as ***y as remote IO, but it will get the job done.

35 gates, each with a read message and a write message. Read is 100 integers from N7:0 - 99. Write is 20 registers from N7:80 - 99. Status, Alarms, counters, etc have used 20 integers of the read, and I think I have 10 registers of the 20 allocated used in the write. I log *EVERYTHING*.

Wire may be cheap, but installation is not.

I have a 24 inch cable tray with cables (the original 125V DC cables for the gates, lighting, sump pump 600VAC power, etc etc) dating from 1967. It`s a mess. Some have been removed to make way for the cables we installed in 2009. Teck cable is not small. 25 cables coming out of a 24 inch tray is TIGHT.
 
I had just a thought about the strain on the communications and the amount of messages.

You said that you are reading 100 integers from each micrologix, 20 integers are status, alarms, counters and logging ect. If some of your read data is not time critical, I think it would be possible to save some bandwidth on the network.

What I have done before to take the strain off of some DH+ Networks was to change the read size depending upon if data in the remote plc had changed, if not only read the critical information, then in the remote plc if any of the noncritical non time-sensitive data has changed read the rest of it.

Say you have the first 10 or 20 words read all the time. In one of those integers use a bit to flag saying that the non-critical data has changed and then change the message size from 10 or 20 to the full 100 while the data has changed or changing and then write to the remote plc that the data was read as a check and toggle back and forth between when the the maximum amount of data needs to be read.

I know it would be a little bit of work, that's why I said it was just a thought for right now, until you do upgrade to something else. I don't know the exact amount of bandwidth that would be saved, (Someone with more knowledge than I will probably give an exact number) but even if it's just 20 integers X 35 controllers that's 700 words of data that wouldn't be constantly on the network.
 
Last edited:
I had just a thought about the strain on the communications and the amount of messages.

You said that you are reading 100 integers from each micrologix, 20 integers are status, alarms, counters and logging ect. If some of your read data is not time critical, I think it would be possible to save some bandwidth on the network.

What I have done before to take the strain off of some DH+ Networks was to change the read size depending upon if data in the remote plc had changed, if not only read the critical information, then in the remote plc if any of the noncritical non time-sensitive data has changed read the rest of it.

Say you have the first 10 or 20 words read all the time. In one of those integers use a bit to flag saying that the non-critical data has changed and then change the message size from 10 or 20 to the full 100 while the data has changed or changing and then write to the remote plc that the data was read as a check and toggle back and forth between when the the maximum amount of data needs to be read.

I know it would be a little bit of work, that's why I said it was just a thought for right now, until you do upgrade to something else. I don't know the exact amount of bandwidth that would be saved, (Someone with more knowledge than I will probably give an exact number) but even if it's just 20 integers X 35 controllers that's 700 words of data that wouldn't be constantly on the network.

I hadn't thought of that. I had assumed (making an *** out of U and ME) that a few extra integers on the payload was trivial compared to the setup for the read or write.

I am not reading things fast. The timeouts buried inside the message instruction can only be dropped so far. I think I am reading every 2.5 seconds, with 6 messages active at once. So one gate from each of the 6 switches, pause 2.5 seconds, trigger the next read, on the next gate from each of the 6 switches ... until you run out of reads, then do writes for each gate, 6 at a time.

So my bandwidth is trivially small. But when one or more gates are powered down, there are delays (I think I was able to drop the timeout to 6 or 7 seconds?) I hate the **** that is buried in TCP/IP. I can handle my own retries. I don't need retries built into my transport layer! Just tell me when the darned thing is not connected!
 
A few things to consider maybe having Controllogix based I/O at each gate Vs. a Micrologix and all the messages and just do produced / consumed.

Having a core switch and going fiber from point to point (zero CAT 5) would eliminate a lot of switches and traffic and doing a DLR would offer some reliability.

If you wanted local control separate from the Controllogix you could use Device Logix in the adapter for simple local gate control logix and would give you the same functionality you have now.

Don't know how the timing is setup on your messaging but a message does not always complete in one scan. Many people use manual timing and not the message done bits for control and they can lose part of the message and generate a lot of errors and junk traffic doing that.

Its best to let each message trigger the next with it's done bit and have timing logic there to push on to the next message if that message does not complete and issue it's done bit in a certain amount of time but try to let the done bits control if possible and only push the message forward when necessary.

Using reads from each Micrologix vs using writes in the controllogix would help share the load also.

Using a counter for each message that has to be pushed along will help you zero in on problem spots also.


Just some things to give some thought to.
 
Last edited:
How 'new' is the 5069? I try to stay away from the bleeding edge ... a year for major software releases, 1 - 2 years for 'new' hardware from rev 1.0

The Rockwell literature seems to show it is the same release window as the L8x?

May 2016 for both CompactLogix 5380 (5069) and ControlLogix 5580 (L8x); Studio 5K V.28
 
A few things to consider maybe having Controllogix based I/O at each gate Vs. a Micrologix and all the messages and just do produced / consumed.

Having a core switch and going fiber from point to point (zero CAT 5) would eliminate a lot of switches and traffic and doing a DLR would offer some reliability.

There is a core fiber switch with dedicated multi-mode to each of the 2955's. 6 switches, 5 - 7 gates on each. Our IT guy says the ethernet network is not causing the mis-delivered messages ... but he does not appear to have data to back that up. It just happens too infrequently. I'd like to catch one example on wire shark ... but there is a lot of data to sift through.

If you wanted local control separate from the Controllogix you could use Device Logix in the adapter for simple local gate control logix and would give you the same functionality you have now.

I am not familiar with Device Logix. Do you have some part numbers I can look up?

Don't know how the timing is setup on your messaging but a message does not always complete in one scan. Many people use manual timing and not the message done bits for control and they can lose part of the message and generate a lot of errors and junk traffic doing that.

2.5 seconds between messages, 7.5 second timeout (I looked it up) seems like *FOREVER*. I don`t remember why it is so long. Message must be done or in error for the next message on the same switch to enable. There is a counter on enabled and waiting, and it is 0.

Its best to let each message trigger the next with it's done bit and have timing logic there to push on to the next message if that message does not complete and issue it's done bit in a certain amount of time but try to let the done bits control if possible and only push the message forward when necessary.

Yup. I'm there.

Using reads from each Micrologix vs using writes in the controllogix would help share the load also.

I tried that briefly ... managing the 35 separate source files, trying to make the EXACT same change in all 35 .. the overhead on my time was too high.

Using a counter for each message that has to be pushed along will help you zero in on problem spots also.

About a dozen messages with issues in a week, 2.5 seconds between messages, is a LOT of messages. Any suggestions on what i should trigger when there IS a problem. I have counters for attempted, completed, errors, enabled waiting, watchdog timed out. That's why I know that there are about a dozen problems a week
 
There is a core fiber switch with dedicated multi-mode to each of the 2955's. 6 switches, 5 - 7 gates on each. Our IT guy says the ethernet network is not causing the mis-delivered messages ... but he does not appear to have data to back that up. It just happens too infrequently. I'd like to catch one example on wire shark ... but there is a lot of data to sift through.

Yes getting some wire shark scans would be most helpful.



I am not familiar with Device Logix. Do you have some part numbers I can look up?

Device Logix is like an embedded PLC in many products that will do simple logic and has a function block editor and can be used when there is not PLC or in a situation like you have. Its' a feature in point I/O adapters as well as armor start units and most newer drives. If you are controlling motors an armor start may be a good choice as it would give you local motor control and could be mastered from the central controllogix.



2.5 seconds between messages, 7.5 second timeout (I looked it up) seems like *FOREVER*. I don`t remember why it is so long. Message must be done or in error for the next message on the same switch to enable. There is a counter on enabled and waiting, and it is 0.


About a dozen messages with issues in a week, 2.5 seconds between messages, is a LOT of messages. Any suggestions on what i should trigger when there IS a problem. I have counters for attempted, completed, errors, enabled waiting, watchdog timed out. That's why I know that there are about a dozen problems a week

I would be counting errors and timeouts that required a push as the message did not complete in the set time to be able to document where some of the issues my be coming from.

When you have multiple things like this going on and limited options you have to handle it like eating an elephant one tiny bite at a time.

Also are your lower level switches managed? If so you may be able to get some good problem solving data from those also. That's one reason i like to have managed switches across there board just for times like these.
 
Last edited:
Device Logix is like an embedded PLC in many products that will do simple logic and has a function block editor and can be used when there is not PLC or in a situation like you have. Its' a feature in point I/O adapters as well as armor start units and most newer drives. If you are controlling motors an armor start may be a good choice as it would give you local motor control and could be mastered from the central controllogix.

I had heard of 'PLCs' built into drives. Not in I/O adapters.

So you can use a few local function blocks. The communication appears to be built-in ... is it addressed as I/O, or produced and consumed, or something else entirely?

I would be counting errors and timeouts that required a push as the message did not complete in the set time to be able to document where some of the issues my be coming from.

I am counting them. I have not progressed any further than that. If I invested the time to get Wireshark captures, I would need at least the timestamp ... anything else? Maybe what MAC address that was received and did not match?

Also are your lower level switches managed? If so you may be able to get some good problem solving data from those also. That's one reason i like to have managed switches across there board just for times like these.

The Cisco 2955's are layer 2 managed, if I remember. A quick search on the Cisco site did not mention managed or not. I purposely did not change the config on the switches. They are default, down to not having an IP address, or any VLANs besides 0. I told IT that was what I was doing. It was temporary, until they came up with some guidelines .. I think the guidelines are in draft now.

Each of the 6 switches has been changed out multiple times, most of the time just exchanged with another switch, during troubleshooting to determine if a problem follows the switch or stays with the group of gates. I have not had to visit site during these switch changes. The ... 8750? .. switch handling the fiber stuff has dealt with switches moving from one port to another. And we have switched or changed out the communication modules in the 8750 in a similar way for troubleshooting.

I have a small bit of training on Cisco, but no tools and no experience. I have tried to leave that to others and it has sort of worked out, most of the time. This is an exception.

This particular network is `firewalled`by a ControlLogix rack. Anything that does not speak CIP does not see the network. But obscurity is not longer good enough .. so we`ll have to install some security.
 
An update to a long-term project

You might want to consider the new 5069 CompactLogix family since local control capability in case of Master failure would be sought after in mining environments.

The 5069-L306ER with one 5069-IA16 (16 x 120/240 VAC Input) and one 5069-OW16 (16 x NO Relays) will cover a 'footprint' similar to the ML1100 and have similar power requirements; the 5069 CompactLogix CPUs have two Ethernet ports which could be used independently or as parts of a DLR.

Obviously, you could Produce/Consume to/from the L73 and each gate controller for 'normal' functionality or implement local control when the Master is not available.

The above setup will run you some $2000/instance just a bit above the proposed Point I/O Remote racks, however, with a minimum of install costs.

I have gotten around to entering a few of the suggested configurations into Integrated Architecture Builder.

I was surprised to see that *ALL* of the suggestions fit easily into the bandwidth, available CIP connections, TCP connections, etc. I'm used to Controlnet ... and being careful with bandwidth to ensure that everything fits.

So I went further. Entering worst-case numbers for this network (50 nodes, 10 switches, 10 ms update, 1 array of 100 ints produced per node, 1 array of 20 ints consumed) ... and it fit easily. Even when I changed the network to daisy-chain from one node to the next instead of using the switches.

So I kept adding. I would never do this in practice .. but I added the largest MCC room that I have on this same network to see if I ran out of resources. 20 racks of rack-optimized 1756 IO, analogs at 10 ms, devicenet scanners at 10 ms with room for 20 drives on each, intelligent motor starters, etc etc.
And it STILL fits with room to spare.

This one, as you said, requires a bit more cash per installation. The pluses are nice though:
- can be installed one at a time
- allows for some local intelligence when communication goes down
- minimal re-work for wiring
- no re-work for ethernet

Using remote I/O is a bit less money per node. The big plus being that all of the code resides in the ControlLogix. The thing that makes me uneasy is that I am relying on 'power off defaults' for the state of each node when communication is lost due to any number of issues.

Thanks to everyone that proposed solutions.

We'll be adding new non-gate nodes to the installation this August to deal with flood switches and sump pumps, with a plan forward to change out the Micrologix on the gates one or two at a time as we have issues with the gates.

The issues that we have had are more hydraulic or mechanical, but as we visit each gate, we are going to upgrade to the CompactLogix and add monitoring to our outputs .. sort of. We want to ensure that the relay outputs to the hydraulic solenoids have not 'welded on'. Most of the time, the hydraulic spools just don't move (spring return to gate close), but this is a question that gets asked ... mostly because it is a long walk to get to the gates and no one wants to go unless they are sure that it is 'their problem'.

That's enough typing!

Thanks again.
 
A thought that occured to me as I read through these:
You could use whatever remote I/O you like at each gate and have that wired to a small PLC at each gate. For example, you could use Point IO with a discrete output feeding a discrete input of a Micro 810 and one or more Micro 810 outputs feeding Point IO inputs. That retains local control capability and each Micro 810 has the same program so there can be a couple spares on a shelf pre-programmed, ready to drop in. You could also keep using the ML1100s for this.
 
Last edited:

Similar Topics

Dear all, I have a FX2N-20MR chinese semi-clon of a Mitsubishi PLC. It has only a serial DB9 port that cannot be removed or exchanged (which is...
Replies
5
Views
2,026
HI I am looking for the operating manual for the Aeg minisemi 500/875+GO dc drive Any help would be appreciated.
Replies
0
Views
1,581
Need schematic for AEG minisemi 220/24.2 Any minisemi schematic would be good. THX
Replies
0
Views
1,829
Hi all, Fanuc has a line of spider robots we've been taking a look at. Really neat and incredibly fast, but I have zero experience with Fanuc...
Replies
4
Views
3,146
HI ALL i am looking to found informations about a DC drive AEG MINISEMI D V 3.1 Has anybody an idea where i can ? maual-software etc.
Replies
0
Views
2,285
Back
Top Bottom