Semi-intelligent gate controls

A very different approach...
https://www.spectrumcontrols.com/products/webport-solutions/universal-gateway/
The Gateway would do all of the communications so there won't be any messaging at the PLC level (either end). It's primary purpose in life is a protocol bridge but because it does the messaging there is a clear advantage to using it for just that as well (even though the protocol is (almost) the same on both ends). I would imagine that communicating with 35 MicroLogix 1100's involves a significant amount of ladder logic. None of it would be needed with the Gateway. The Gateway also has a Heartbeat tag that each MicroLogix could use to determine if it is communicating with the Gateway so if comms are lost it would know to close the gate. The app engineers at Spectrum can go over details about your application if you're interested.
 
Last edited:
Wow
For a simple project it would seem that some of you want to make things far more complicated than is necessary or desirable.
Using a small processor like the 1400 at each gate is not going to make things more reliable just the opposite it will be less reliable. For the communications messaging to and from a 1400 requires far more bandwidth than using the remote and you have added far more complexity to the original program. you must program in both the read and write messages. Keep in mind each message is actually multiple messages. On a write message the PLC sends out a request for data message to the 1400 and the when the 1400 receives the request for that data it replies with the data requested back to the PLC. The PLC then responds back with an acknowledgement message that it did in fact receive the requested data. This process would have to be repeated for each 1400 in the network. That’s a lot of messaging With remote this process is greatly simplified the data to from the remote is communicate in back ground the message is very small and simple module address and data very little overhead and you don’t have to program it at all .
As for using a gateway to cut down on network traffic. A gateway cannot initiate any communication on its own they only direct the flow of messages through. So the PLC would still have to control all messaging, there is no gain there.
If you are concerned about closing a gate if communication is lost. Set the output in the remote to turn off on communication loss. To increase the reliability use Point IO Isolated relay module and with the gate solenoid in series with 2 or more outputs so that it requires both puts to turn on to energize the solenoid . One more output coil in the PLC program for each gate not a big deal to program.
It would clean thing up considerably and provide you with a close to fail safe control. To take to the next level use a Guard logix processor and with safety outputs. They are designed to be fail safe and turn off on any communication problems. I don’t think you would ever need to go to that level but it’s an option.
Lets not forget with multiple small processors there is a greater risk of a single failure. I certainly don’t see any advantage to using multiple processors. The Point IO system you can select a 2 port remote communication module so no gateway / router or switch required as would be the case with multiple 1400 processors. ( More Hardware = more chances for a hardware failure.
 
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.

So you are suggesting communicating via remote IO and hard-wiring that IO to micro 810s that do the actual control?

The idea was to get away from the message instructions and overhead associated with that. Remote IO does that. It adds to the installation footprint, wiring, etc. I think it would work, but it makes me uncomfortable for some reason that I can't put my finger on.
 
A very different approach...
https://www.spectrumcontrols.com/products/webport-solutions/universal-gateway/
The Gateway would do all of the communications so there won't be any messaging at the PLC level (either end). It's primary purpose in life is a protocol bridge but because it does the messaging there is a clear advantage to using it for just that as well (even though the protocol is (almost) the same on both ends). I would imagine that communicating with 35 MicroLogix 1100's involves a significant amount of ladder logic. None of it would be needed with the Gateway. The Gateway also has a Heartbeat tag that each MicroLogix could use to determine if it is communicating with the Gateway so if comms are lost it would know to close the gate. The app engineers at Spectrum can go over details about your application if you're interested.

If I understand your intent, the gateway would poll the Micrologix 1100's and send the data to the ControlLogix. So the messages, retries, comm fail counters, etc that I have as overhead would go away. But I would be trusting a third-party device to do it for me, keep the separate backups, ... not a large overhead. If the gateway can initiate polling (@GaryS does not seem to think it can)

It makes me uncomfortable to have data 'magically' appear in the ControlLogix data table. But if the overhead is handled by the gateway, that would seem a bit better than the communications mess that I have now.

This solution (if the gateway can initiate polls) allows for micrologix or any other controller to be used for the gates, sumps, flood detectors, etc. But each Micrologix still needs to have it's program loaded in the case of a failure, since it needs it's own IP address. So that issue is still there.
 
Wow
For a simple project it would seem that some of you want to make things far more complicated than is necessary or desirable.
I make things more complex than they need to be. It's a known issue. And one of the reasons I post here - to get some perspective!

Using a small processor like the 1400 at each gate is not going to make things more reliable just the opposite it will be less reliable.
I was not confident that ethernet would work at all when the system was installed in 2007. I hedged my bets, putting in enough hardware and enough fiber that I had multiple options. I'm a paranoid.

For the communications messaging to and from a 1400 requires far more bandwidth than using the remote and you have added far more complexity to the original program. you must program in both the read and write messages. Keep in mind each message is actually multiple messages. On a write message the PLC sends out a request for data message to the 1400 and the when the 1400 receives the request for that data it replies with the data requested back to the PLC. The PLC then responds back with an acknowledgement message that it did in fact receive the requested data. This process would have to be repeated for each 1400 in the network. That’s a lot of messaging
The bandwidth required, even using a 1756-ENBT and 10 MB/half duplex, appears to be under 1%. Nothing needs to happen quickly, but it needs to happen

With remote this process is greatly simplified the data to from the remote is communicate in back ground the message is very small and simple module address and data very little overhead and you don’t have to program it at all .
Our site has had issues with plastic IO cases, limited voltage isolation, and small terminal blocks on remote IO. The plastic does not like low temperatures. Wiring with different neutrals can momentarily have 500V+ differences before you track down a missing ground - and it blows up your inputs and outputs if they are not rated. Small terminals do now allow jumpers with #16 AWG ... the smallest cable we actually pull into the field. Any suggestions on remote IO that can address these issues?

As for using a gateway to cut down on network traffic. A gateway cannot initiate any communication on its own they only direct the flow of messages through. So the PLC would still have to control all messaging, there is no gain there.
Network traffic is not an issue, so far as I know. The overhead is my programming and the complexity ... much of this is self-inflicted. I track everything I can think of. And that takes code. And data structures. But it DOES come in handy when I am troubleshooting.

If you are concerned about closing a gate if communication is lost. Set the output in the remote to turn off on communication loss. To increase the reliability use Point IO Isolated relay module and with the gate solenoid in series with 2 or more outputs so that it requires both puts to turn on to energize the solenoid . One more output coil in the PLC program for each gate not a big deal to program.
Point IO is one of the systems that ... appears to be more of a commercial solution, not an industrial solution. Pehaps things are better now. I have not looked at point IO for a while. I'm not sure if it was available or proven during the original install.

It would clean thing up considerably and provide you with a close to fail safe control. To take to the next level use a Guard logix processor and with safety outputs. They are designed to be fail safe and turn off on any communication problems. I don’t think you would ever need to go to that level but it’s an option.
The fail safe was an issue during design and implementation. It turns out that Micrologix 1100 relay outputs are more reliable than Parker single-acting solenoid valves in our implementation. The local control was over-emphasized and is under-utilized. Particularly during trouble-shooting. A welding-rod pushed through the vent of the solenoid valve will cycle the hydraulic spools and move the gate. No one uses the 'approved and published safe method for over-riding interlocks' that took so long to write up.

Lets not forget with multiple small processors there is a greater risk of a single failure. I certainly don’t see any advantage to using multiple processors. The Point IO system you can select a 2 port remote communication module so no gateway / router or switch required as would be the case with multiple 1400 processors. ( More Hardware = more chances for a hardware failure.
Point IO looked cheap and flimsy ... maybe I should re-visit it. If you guys have had success with it.
 
Adding more hardware just makes it less reliable
the Point IO system has been around for about 20 years with proven reliability and ease of maintenance
as for the gateway. A gateway can not start a communication it just passes a message through

Keep it simple. Simple is more reliable with the right hardware.
if you are concerned about the ethernet wiring then you could use wireless ethernet but running all the hard wires to each gate will be very expansive and
far less reliable.

Ethernet Gateway.PNG
 
Adding more hardware just makes it less reliable
the Point IO system has been around for about 20 years with proven reliability and ease of maintenance
as for the gateway. A gateway can not start a communication it just passes a message through

Keep it simple. Simple is more reliable with the right hardware.
if you are concerned about the ethernet wiring then you could use wireless ethernet but running all the hard wires to each gate will be very expansive and
far less reliable.

There are more than one type of Gateway. Your image is talking about a Gateway router which does act as a path to the internet. However in the context here, the Gateway is referring to a device that bridges protocols and devices. As to reliability, it's a simple mater of risk vs. benefit. Yes adding equipment increases risk of failure but you can make that argument all day long about all kinds of applications. At the end of the day you have to decide if you are willing to take the risk (which is low) to get the benefit (which is high).
 
If I understand your intent, the gateway would poll the Micrologix 1100's and send the data to the ControlLogix. So the messages, retries, comm fail counters, etc that I have as overhead would go away. But I would be trusting a third-party device to do it for me, keep the separate backups, ... not a large overhead. If the gateway can initiate polling (@GaryS does not seem to think it can)

It makes me uncomfortable to have data 'magically' appear in the ControlLogix data table. But if the overhead is handled by the gateway, that would seem a bit better than the communications mess that I have now.

This solution (if the gateway can initiate polls) allows for micrologix or any other controller to be used for the gates, sumps, flood detectors, etc. But each Micrologix still needs to have it's program loaded in the case of a failure, since it needs it's own IP address. So that issue is still there.

The Gateway does handle the polling which can be configured to execute via a time base or on the change of state of a monitored tag, which can be from any of the connected device. In other words you can have the Logix PLC change the value of a tag that the Gateway is monitoring and that would trigger the data exchange from one or any of the MicroLogix PLC's, or you could have the MicroLogix change the value of a monitored data table (N7:0 for example) and that could trigger the data exchange between it and the Logix PLC. The flexibility is high and again, the Gateway handles all of the overhead. If you go to Spectrum's web site, then the product page for the Gateway (it's under Webport), then select the Webinar button you will see a video of the latest Webinar which included a quick demonstration of setting up communications between a MicroLogix (via Modbus RTU) and a CompactLogix (via Ethernet/IP). It should give you a basic understanding of how it works.
It's worth noting (to be fair), there are a lot of gateway solutions out there most of which would probably work in your application. I happen to think that Spectrum's is the simplest to setup and use but I don't want to be bias either. Long and short is I think a gateway is one option that shouldn't be overlooked.
 
Something that I was wondering is the issue Network bandwidth or the controllogix overhead? If so would adding another ethernet module to that rack dedicated to messages for gate controls or simply just messaging. Or even a new controllogix rack dedicated for just communications. I am not completely familiar with controllogix setups as to slc's and PLC 5's. It was just a thought I had. If you have a spare one it could be tested easily other than pointing the message's to the new Ethernet module. I personaly see your fear / paranoia of a centralized system rather than what you have now with independent control for Independent Stations. That would be my preference especially as to how things always change down the road. Network issues or simple problems like someone unplugging a ethernet cable. If there are reasons that operators don't use proper methods to use the local controls. Removing that as an independent feature will also remove a reason to have them learn the safer provided means. Plus the way things go you remove something that has more capability and then a month later they ask for independent control. Just my thoughts.
 
Something that I was wondering is the issue Network bandwidth or the controllogix overhead?

Perhaps I should have stated programming overhead. The ControlLogix (1756-L73) can only have 10 buffers, which enables 10 active messages at once. So putting all of the control in the L73 is what I opted for. The Micrologix 1100 can do reads on their own, but that makes each of the PLC programs require a different target address. So all 35 (for now) of the programs end up being separately maintained. I presently have a sinlgle program that is maintained and download a different IP to the target Micrologix when I need to go online. This is far from perfect.

Another program would be developed to monitor leak detection (I think it's called a waterbug). Still another for controlling/Monitoring sump pump application, and the last one planned is to activate an indicator to show the location of the gates to mobile equipment operators.

4 source programs and changing the IP when you download or go online is much better than maintaining 35+ programs

If so would adding another ethernet module to that rack dedicated to messages for gate controls or simply just messaging. Or even a new controllogix rack dedicated for just communications. I am not completely familiar with controllogix setups as to slc's and PLC 5's. It was just a thought I had. If you have a spare one it could be tested easily other than pointing the message's to the new Ethernet module. I personaly see your fear / paranoia of a centralized system rather than what you have now with independent control for Independent Stations. That would be my preference especially as to how things always change down the road. Network issues or simple problems like someone unplugging a ethernet cable. If there are reasons that operators don't use proper methods to use the local controls. Removing that as an independent feature will also remove a reason to have them learn the safer provided means. Plus the way things go you remove something that has more capability and then a month later they ask for independent control. Just my thoughts.

A future problem is that the Micrologix 1100 is getting old and will be obsolete soon enough. Keeping track of which messages are active, which are timing out, and keeping them from becoming snarled is my present problem. If I add more Micrologix that perform different tasks, like monitoring for a high sump pump level, or turning on location indicators so that mobile equipment operators can locate buried gates more easily ... the messaging problem will get worse.

Replacing the Micrologix with Compactlogix, and using one array of Produced tags and one array of consumed tags for each one appears to work OK. Only the location (gate, sump pump, whatever) being changed is affected along with the L73 master. Everything else continues running at least locally. The upgrades will be timed to allow the master to be downloaded for the produced/consumed changes (about 2 minutes). And if I pay attention, I should be able to maintain just one source program .. like the Micrologix.

The point I/O may be a solution for another area that has things spread out quite a bit. I need to buy a couple of IO blocks and see if our electricians like working with them as much as with the Micrologix and CompactLogix. And we'll see if the Point IO survives. The largest risk to the IO appears to be during install and before everything is commissioned out.
 
So you are suggesting communicating via remote IO and hard-wiring that IO to micro 810s that do the actual control?
Using the existing ethernet infrastructure for remote IO such as Point is what I have in mind. You could continue to use the 1100s you have. Later replacements could be Micro 810 or whatever you like.

I think a 810 has enough IO to do your local control plus a couple discreet points to connect to your remote IO. I figure it’ll look like one Point output to gate PLC input for open, and one gate PLC output to Point input to confirm open. You could use more signals to monitor local enabled or whatever.

Point IO IP can be set with switches. All the local PLCs will be interchangeable with the same program with no IP concerns. Any component should be replaceable by a local technician without software, provided spare PLCs are pre-programmed.
 

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