Multiple CLX processors in same chassis running essentially same program

[HalfManHalfBiscuit]

I want to add some logic to an existing 1756-L73 processor to add enhanced monitoring functionality. My problem is the existing program in the processor is already running with a scan time of roughly 120 msec and cannot have any additional scan time added to it. I was wondering if it would be possible to add an additional 1756-L73 processor to the chassis and download the same program to it and have it run in a sort of "listen" mode where it read the same real world inputs and executed the same code minus writing to real world outputs. I would then add my driver to this 2nd processor. I would always want the 1st processor to "own" the outputs. Some of the connections are non-Rockwell components and don't support the "listen only" mode so I have a bad feeling about this. I know ideally it makes sense to take this process and split it up completely between 2 processors to reduce the scan time. Unfortunately this processor is already running in a production environment and is already behind in producing parts for one of the big 3 auto suppliers. Current risk is too high to go that route.

 

[Phil Buchanan]

Yes you could do this but what do you mean by add your driver?

Also the code in the new processor could listed to the Inputs and execute logic but if it does not own the any of the outputs what is the point or do you lan to add additional outputs? if so you left that out.

We can help you better if you can explain a little better exactly what you are trying to do.

 

[HalfManHalfBiscuit]

What I meant by "driver" is I would be adding a program to the existing Main task of the CLX that would be executing logic that would monitor existing signals in the processor so that I could create 32-bit time stamps that I would store in program scoped tag arrays as the signals transition. I have a computer that runs an OPC (Kepware in this case) that reads the tag arrays. I then use that data in the computer to build a graphical view of how the machine is running. This program that I add to the existing CLX adds scan time naturally. The more signals I want to capture transitioning is directly proportional to the amount of scan time that my program adds to the existing task. Let's say for this specific scenario I would potentially be adding in the neighborhood of 20 msec to the scan. It is important that I see as close to possible the real time transition of the signals to accurately display the time deltas down to the hundredths of a second. Have tried to use produced/consumed tags and peer to peer messaging but found the latency in the communications to be too much for my purposes. I have used this "driver" program successfully on other applications but none of those came close to approaching the scan time of this specific one I mentioned in my initial post. Does this help give you a better idea of what I am trying to accomplish?

This is the only reason I want to add the CLX. That is, the added CLX is only meant to create 32-bit time stamps that get stored in arrays. I have no intention of this processor ever taking control of the process or being used as a redundant CLX.

 

[HalfManHalfBiscuit]

This is the only reason I want to add the CLX. That is, the added CLX is only meant to create 32-bit time stamps that get stored in arrays. I have no intention of this processor ever taking control of the process or being used as a redundant CLX.

 

[Phil Buchanan]

So you want to display time stamped relational bit patterns of IO on an external HMI?

I don't see any issue with doing it but I don't really understand how this has value in determining how the machine is running. There are much easier methods to pull metrics from a process.

 

[Phil Buchanan]

Also no matter how fast or accurate you capture the data the bottle neck is you OPC connection so you will still be displaying old data. Or maybe I am still not understanding your scope fully.

 

[rdrast]

Running an identical program will just result in both processors running slow. Use the second CPU to split your tasks.

 

[HalfManHalfBiscuit]

Let's just say I have a unique way of storing immense amount of data that an end customer can use to see intuitively down to the device level the detailed performance of their equipment/process and can spot trends to help them avoid impending downtime events (smart preventive maintenance) and also spot opportunities to improve throughput by looking up to a years worth of data records that can be displayed with a click of the mouse. Blah, blah, blah, just the latest mousetrap on the market but I have had successful implementations of this product and the customers are extremely satisfied. Our OPC capture is not an issue. We have a solution for that and it works just fine. That is the whole purpose behind the tag arrays where I store the 32-bit time stamp values. The OPC is only looking for data transitions in those arrays. We use 32-bit time stamp values so that the values are unique for an entire year down to the hundredth of a second. That is how we can store a years worth of data that a customer can view with a click of a mouse. And it's not just a list of numbers. The data can be displayed in a number of intuitively graphical layouts that even the least tech savvy person can understand what they are looking at. I am not the original OEM who supplied the equipment and program for the end customer. I come in afterward when the end customer is trying to understand why their equipment is not performing as well as they anticipated. Personally I would not have accepted the original equipment supplied by the OEM if I knew the scan time was well above 100 msec for a machine process. I would have told them to add another processor and split the process up. Too late for that now. At least the end customer is not willing to take that risk since they are already behind in production and cannot at this time afford any downtime.
Hopefully this gives the background behind my original dilemma.

 

[Phil Buchanan]

Ok so while I still don't see the full value in logging data that way someone must so that's ok.

But I still don't understand why you want to download an exact copy of the existing program because to log data and have it in listen only mode for the IO you are going to have to add your code and restructure some of the existing code to make it work so why not just put in only the code you need to to data log?

It will be much smaller, Cleaner and easier to follow and less confusing for someone coming behind you to service the equipment in the future.

 

[mk42]

I, like most of the others, am not quite understanding how this will help.

HMHB, are you essentially trying to offload the communications load to another processor? Or are you just trying to avoid loading down the original processor ever more by adding additional code for your logging?

I'm not sure what you hope to gain by adding CPU#2.

 

[HalfManHalfBiscuit]

Ok so while I still don't see the full value in logging data that way someone must so that's ok.

But I still don't understand why you want to download an exact copy of the existing program because to log data and have it in listen only mode for the IO you are going to have to add your code and restructure some of the existing code to make it work so why not just put in only the code you need to to data log?

It will be much smaller, Cleaner and easier to follow and less confusing for someone coming behind you to service the equipment in the future.

PBuchanan, you make a good point. The easiest way was to make a copy of the program since sometimes part of my logic can be triggered by the transition of an internal memory tag rather than just a real world input. But you're correct, once I determined all the signals I want to monitor I could then selectively edit the copied program to contain only the necessary code required to drive those signals. There are entire routines that do only diagnostics (fault messages) and/or drive HMI screens that I do not need to usually monitor whatsoever. Appreciate the feedback.

 

[HalfManHalfBiscuit]

I, like most of the others, am not quite understanding how this will help.

HMHB, are you essentially trying to offload the communications load to another processor? Or are you just trying to avoid loading down the original processor ever more by adding additional code for your logging?

I'm not sure what you hope to gain by adding CPU#2.

Did not want to bog down the original processor with added scan time. From my understanding in discussions with the end customer, the scan time was even longer before and was causing issues with the operation of the equipment. They or the original OEM for the equipment went in and edited the code to reduce the scan time to a barely acceptable value so that the equipment runs without repeated issues.

 

[Phil Buchanan]

I would still say that even with their changes their OEM code is still not optimized well with scan times that high.

I have lines with well over 3000 IO points and 40-60 drives many of which are coordinated and distributed HMI's and historian data logging that do not have scan times that high.

So either this is a huge process or the OEM code needs some more work. From you point of view it would be easier to add the second processor but fron a customer point of view I would rather optimize the code and stay with one processor.

 

[HalfManHalfBiscuit]

Agreed. There are 69 robots being controlled (or more accurately integrated with one another) in this one processor. The sad thing is they have RPI rates of 10ms for each robot yet they are looking at scan times greater than 100ms. Have suggested to them to increase the RPI rates to at least 20ms if not more but they are reluctant to do so. One of those "if it ain't broke don't fix it" mentalities.

 

[mk42]

One of those "if it ain't broke don't fix it" mentalities.

Except, unfortunately, it IS broke. They just don't know it yet.