HalfManHalfBiscuit
Member
This may be a dumb question but hear me out.
First, a little background.
There is an existing assembly process comprised of multiple PLC-5 processors utilizing the classic RIO network to read/write to I/O devices. It is a rather large system, let's say with 15 PLC-5 processors of varying sizes (5/40 thru 5/80). We have been asked by this customer to install our proprietary software application into the plant to help them monitor the performance of this system and see where there are opportunities to increase throughput. Part of our software application requires us to add code to the PLC to help concentrate the data we need to read from the processor into contiguous areas of memory to make the OPC that we use to read the data efficient. The OPC in turn presents this data to our software application that runs on a server. Enough said about that.
Here is the twist. Our software application is based on a 32-bit environment. This means the ladder or structured text logic we add to a PLC needs to work with 32-bit data types. We have used this software application successfully on ControLogix processor controlled systems. This is the first request we have had to monitor a system controlled by the PLC-5 family of processors which only has data types up to 16-bit in length. Data that we generate with the code we add to the PLC have values well beyond 65536.
First thought: convert our software application to work on a 16-bit environment and do manipulation on the data so that we concatenate two 16-bit values into a single 32-bit value when the data makes it over to our server. Conclusion: Cumbersome and many of the PLC-5 processors have memory availability issues. Time and manpower required to rework our overall product cost prohibitive as well. ROI low.
Second thought (and finally getting to my question): Add a CLX chassis with a 1756-L6x or L7x, a 1756-ENBT module to talk to our server, and any number of 1756-DHRIO modules and "scan" the same remote I/O as the PLC-5 processors are scanning. Would copy the existing PLC-5 programs and convert them to equivalent program files in the Logix5000 program. e ControLogix program, one for each of the PLC-5's we want to "snoop". Then I can add my code that would store data as a 32-bit data type and the OPC and our application running on our server would not have to be changed one iota.
The question then is, can a PLC-5 and a 1756-DHRIO both be "scanners" to a remote I/O adapter? I would like to at least be able to "listen" to the inputs that exist on the RIO network. I understand outputs are a completely separate beast unto themselves. I would also need to come up with something if I need to "listen" to input modules that reside in the chassis that contains the PLC-5. There are no spare channels on most of the PLC-5 processors that could be configured for adapter mode which would be one way to solve that problem.
My initial research is telling me this won't work. I've come across some blurbs saying "Remote I/O Scanner is offline because it is trying to connect to an adapter that is already controlled by another scanner. See if other processors in your system are trying to control this adapter and take the appropriate action."
Before you say it, yes, we have considered just completely replacing the PLC-5 controllers and using ControLogix architecture. Two issues there, customer has no money for that type of rework and re-engineering and secondly, customer cannot afford to lose production while trying to switch over. And quite frankly our company doesn't have the wherewithal to take on that type of risk. The line is functioning fine today. The reason they asked us to install our software application is to see if there are other areas for improvement. The "snooping" CLX scenario I proposed above is a down and dirty (read "cost friendly") and has smaller risk to current production.
This may be a bit wordy but I wanted to present as much info
First, a little background.
There is an existing assembly process comprised of multiple PLC-5 processors utilizing the classic RIO network to read/write to I/O devices. It is a rather large system, let's say with 15 PLC-5 processors of varying sizes (5/40 thru 5/80). We have been asked by this customer to install our proprietary software application into the plant to help them monitor the performance of this system and see where there are opportunities to increase throughput. Part of our software application requires us to add code to the PLC to help concentrate the data we need to read from the processor into contiguous areas of memory to make the OPC that we use to read the data efficient. The OPC in turn presents this data to our software application that runs on a server. Enough said about that.
Here is the twist. Our software application is based on a 32-bit environment. This means the ladder or structured text logic we add to a PLC needs to work with 32-bit data types. We have used this software application successfully on ControLogix processor controlled systems. This is the first request we have had to monitor a system controlled by the PLC-5 family of processors which only has data types up to 16-bit in length. Data that we generate with the code we add to the PLC have values well beyond 65536.
First thought: convert our software application to work on a 16-bit environment and do manipulation on the data so that we concatenate two 16-bit values into a single 32-bit value when the data makes it over to our server. Conclusion: Cumbersome and many of the PLC-5 processors have memory availability issues. Time and manpower required to rework our overall product cost prohibitive as well. ROI low.
Second thought (and finally getting to my question): Add a CLX chassis with a 1756-L6x or L7x, a 1756-ENBT module to talk to our server, and any number of 1756-DHRIO modules and "scan" the same remote I/O as the PLC-5 processors are scanning. Would copy the existing PLC-5 programs and convert them to equivalent program files in the Logix5000 program. e ControLogix program, one for each of the PLC-5's we want to "snoop". Then I can add my code that would store data as a 32-bit data type and the OPC and our application running on our server would not have to be changed one iota.
The question then is, can a PLC-5 and a 1756-DHRIO both be "scanners" to a remote I/O adapter? I would like to at least be able to "listen" to the inputs that exist on the RIO network. I understand outputs are a completely separate beast unto themselves. I would also need to come up with something if I need to "listen" to input modules that reside in the chassis that contains the PLC-5. There are no spare channels on most of the PLC-5 processors that could be configured for adapter mode which would be one way to solve that problem.
My initial research is telling me this won't work. I've come across some blurbs saying "Remote I/O Scanner is offline because it is trying to connect to an adapter that is already controlled by another scanner. See if other processors in your system are trying to control this adapter and take the appropriate action."
Before you say it, yes, we have considered just completely replacing the PLC-5 controllers and using ControLogix architecture. Two issues there, customer has no money for that type of rework and re-engineering and secondly, customer cannot afford to lose production while trying to switch over. And quite frankly our company doesn't have the wherewithal to take on that type of risk. The line is functioning fine today. The reason they asked us to install our software application is to see if there are other areas for improvement. The "snooping" CLX scenario I proposed above is a down and dirty (read "cost friendly") and has smaller risk to current production.
This may be a bit wordy but I wanted to present as much info
