Michael Faulknor
Member
RS5000 vs.20, 1769-L35E Processor, I have had an issue that I have seemed to work out between all of the PID posts I could find here and listening to Rockwell tell me 'that should not happen'.
Here is the deal:
I have a tubular cooling system I am cooling product with. I want to get a certain product temperature while controlling a cooling loop supply temperature on a plate pack utility that varies on incoming temperature. Great application for a cascade control I think…so I took a Knowledge base example and ran with it.
But I saw the Master software manual bit setting even when I ‘ignored my code controlling it’ (not with and AFI). I talked with engineers via Rockwell Tech Support online & over the phone. After a lengthy discussion and a clear understanding between us about PIDs (even talked with a PID Instructor who had not seen an unconditional PID Loop) and everything I describe to you below he kept telling me this should not happen. Now they think I found a loop hole in the firmware, personally I think it works great…now that I am starting to understand the program order & control.
Here is what I know for sure:
My first order of operations (order of the ladder instruction sets) I had to correct to match the example from Rockwell. This corrected the two issues I was seeing. The first was the Master PID instruction being set to manual and not by my code, and I could not set it back to auto from my code. I could not ‘un-set’ the software manual bit without going first into the Master instruction and de-selecting that box. Then I could control the loops from the code & toggles from the screen. I noted that when the Slave instruction was toggled to software manual the Master followed. Page 526, Ch. 13 of the RS5000 Instruction Set Manual – Special Instructions, RA Publication 1756-RM0030-EN-P – November 2012; shows a detailed process flow diagram for both a single PID instruction & a Cascade PID instruction set. The ‘mysterious’ box (Items referenced in this box are parameters, units, and modes as they pertain to the designated Slave loop) I believe is the firmware control that I didn’t know about…and based on what I have seen here ultimately is affecting my instruction here…but it would seem from everyone I have talked with at Rockwell that should not be happening…but it is. As long as I know what it is doing, I can work with it, that is what I am doing right now.
The second was the Master .SO for the Set Point value set to the Slave was registering as a “0” and every now and then would blink the set point. The PID's were still controlling, and in a conditional set up with a timer done bit, but the SP would not remain steady. That I solved by removing the timer done condition on the slave’s PID rung, yes de-syncing the loop even though I set the .UDP the same. I have to say I have better control and I have my set point for display.
Rockwell Tells me this should not matter:
I started out with the conditions and code very much similar to the example off knowledge base for a conditional loop - BUT the timer instruction & .UDP Move's were ahead of the PID’s and the JSR's for my 'Software Manual' controls were after the PID's. Based on what I saw from the Instruction Set Manual 'something was controlling it' and that box was hinting that the slave impacts the Master . SO I set the order: JSR's first ahead of the PID's and the timer & .UPD Moves after the PID's (exactly like the example from Rockwell, except I have screen controls for the .SWM, etc. in the JSR's). I still had the Master being set to 'Software Manual' initially but now I could control it from the screen once I manually unset it from within the Master Instrution...so I switched the order of the JSR’s so the Slave set was first, then the Master's -> I started to believe that box that the Slave impacts the Master’s manual mode every time and the processor needed to look at that first, which makes sense to me and I switched the JSR's so the Slave JSR was first and the Master's was second – you could slam the system one way or another if the Master was still calculating the error but the Slave was manually being worked with.
Now I Know:
Now my program works. I have learned that when I set the Slave to a software manual mode, the Master does follow…but I can handle that. And the system does not kick the Master to manual unless I do so from the screen via the Master control selection or the Slave's manual mode state. I actually like that, the Slave must be in an auto mode in order for the Master to be in an auto mode, and if I set the Master to Manual the Slave does not follow.
This might be localized to the L35E firmware...but I am wondering if this is something I stumbled on or if it is just one these things that some haven't worked through in the past and for those that have just haven't mentioned. I have spent the last week trying to find everything on the posts here and at the time a lot of that information has helped me to this point...
I can tell you this...Rockwell wanted me to break away from their 'Cascade' control within the firmware and just run with single loops and move the set point where I needed it...so Kudos to Ron Beaufort for teaching me a thing or two with RS500. Rockwell did commend me for looking at the order and my approach...
Is there something someone has seen to keep the PID's synced with a timer done bit and can still see the set point value?
I will get a chance someday to see if this is really a localized firmware issue with one controller...but I venture it is not!
Here is the deal:
I have a tubular cooling system I am cooling product with. I want to get a certain product temperature while controlling a cooling loop supply temperature on a plate pack utility that varies on incoming temperature. Great application for a cascade control I think…so I took a Knowledge base example and ran with it.
But I saw the Master software manual bit setting even when I ‘ignored my code controlling it’ (not with and AFI). I talked with engineers via Rockwell Tech Support online & over the phone. After a lengthy discussion and a clear understanding between us about PIDs (even talked with a PID Instructor who had not seen an unconditional PID Loop) and everything I describe to you below he kept telling me this should not happen. Now they think I found a loop hole in the firmware, personally I think it works great…now that I am starting to understand the program order & control.
Here is what I know for sure:
My first order of operations (order of the ladder instruction sets) I had to correct to match the example from Rockwell. This corrected the two issues I was seeing. The first was the Master PID instruction being set to manual and not by my code, and I could not set it back to auto from my code. I could not ‘un-set’ the software manual bit without going first into the Master instruction and de-selecting that box. Then I could control the loops from the code & toggles from the screen. I noted that when the Slave instruction was toggled to software manual the Master followed. Page 526, Ch. 13 of the RS5000 Instruction Set Manual – Special Instructions, RA Publication 1756-RM0030-EN-P – November 2012; shows a detailed process flow diagram for both a single PID instruction & a Cascade PID instruction set. The ‘mysterious’ box (Items referenced in this box are parameters, units, and modes as they pertain to the designated Slave loop) I believe is the firmware control that I didn’t know about…and based on what I have seen here ultimately is affecting my instruction here…but it would seem from everyone I have talked with at Rockwell that should not be happening…but it is. As long as I know what it is doing, I can work with it, that is what I am doing right now.
The second was the Master .SO for the Set Point value set to the Slave was registering as a “0” and every now and then would blink the set point. The PID's were still controlling, and in a conditional set up with a timer done bit, but the SP would not remain steady. That I solved by removing the timer done condition on the slave’s PID rung, yes de-syncing the loop even though I set the .UDP the same. I have to say I have better control and I have my set point for display.
Rockwell Tells me this should not matter:
I started out with the conditions and code very much similar to the example off knowledge base for a conditional loop - BUT the timer instruction & .UDP Move's were ahead of the PID’s and the JSR's for my 'Software Manual' controls were after the PID's. Based on what I saw from the Instruction Set Manual 'something was controlling it' and that box was hinting that the slave impacts the Master . SO I set the order: JSR's first ahead of the PID's and the timer & .UPD Moves after the PID's (exactly like the example from Rockwell, except I have screen controls for the .SWM, etc. in the JSR's). I still had the Master being set to 'Software Manual' initially but now I could control it from the screen once I manually unset it from within the Master Instrution...so I switched the order of the JSR’s so the Slave set was first, then the Master's -> I started to believe that box that the Slave impacts the Master’s manual mode every time and the processor needed to look at that first, which makes sense to me and I switched the JSR's so the Slave JSR was first and the Master's was second – you could slam the system one way or another if the Master was still calculating the error but the Slave was manually being worked with.
Now I Know:
Now my program works. I have learned that when I set the Slave to a software manual mode, the Master does follow…but I can handle that. And the system does not kick the Master to manual unless I do so from the screen via the Master control selection or the Slave's manual mode state. I actually like that, the Slave must be in an auto mode in order for the Master to be in an auto mode, and if I set the Master to Manual the Slave does not follow.
This might be localized to the L35E firmware...but I am wondering if this is something I stumbled on or if it is just one these things that some haven't worked through in the past and for those that have just haven't mentioned. I have spent the last week trying to find everything on the posts here and at the time a lot of that information has helped me to this point...
I can tell you this...Rockwell wanted me to break away from their 'Cascade' control within the firmware and just run with single loops and move the set point where I needed it...so Kudos to Ron Beaufort for teaching me a thing or two with RS500. Rockwell did commend me for looking at the order and my approach...
Any other "black box magic" I should be wary of?
Is there something someone has seen to keep the PID's synced with a timer done bit and can still see the set point value?
I will get a chance someday to see if this is really a localized firmware issue with one controller...but I venture it is not!
