PLC5 PID after processor upgrade

[drbitboy]

1) It sounds like this program is not yours, you know basically bupkis about it, but you want to port it from a failed or failing 1785-L40E to a 1785-L80E.

2) That PID is not scheduled correctly; that may not be the primary problem right now, but let's speculate:

2.1) From various info found via the The Google it appears that a PLC-5 Logic Scan Time can be anywhere from no faster than 6ms to 500ms and up. I think my brother told me that PLC-5 logic is interpreted, not compiled; that and the age of the PLC-5 line makes those numbers seem reasonable.

2.1.1) So the 0.1s (100ms) Loop Update Time in the PID configuration menu is not unbelievable, and may actually be correct, even if by luck (or coincidence, as @Ken Roach said), or it may have been empirically determined via the "I watched S:53 and S:54 online for a few minutes on the -L40E" method, perhaps with an unconsummated "I'll fix it later" on the side.

2.2) We don't know your process, but the T_i and T_d tuning time constants are 10 and 3 minutes, so this process is slow, in which case an estimate determined via the method in (2.1.1), while something less than best practice, could certainly produce workable results.

2.3) My point is that any error in the entered Loop Update Time, which error is almost certainly no more than a factor of 15, is not so big it could not be absorbed and corrected for in those large-ish tuned values of T_i and T_d, assuming the process was manually tuned at some point.

So while tuning, and especially the Loop Update Time, is suspect and should be done correctly at some point, I would put a pin in that line of investigation for now, and look into the duplicate declaration of the PV and CV first.

 

[drbitboy]

It does not seem to be controlling properly anymore but only one of the PID's is not behaving.

Define "not seem to be controlling properly anymore" and "is not behaving."

Also, is this one PID the only one with a duplicate declaration of the same word for its Process Variable and Control Variable?

 

[alan_505]

There is a CPT that is moving a value into the SP of PD9:29.

I saw that the PV and CV are the same for PD9:29, and could not work out how that worked.

I have put a timer to trigger PD9:13 and PD9:29 and the system seems to be reacting slower now.

N407:75 is coming from a 1794-IE8 card and is the level of a hopper of liquid product.

 

[drbitboy]

1) It sounds like this program is not yours, you know basically bupkis about it, but you want to port it from a failed or failing 1785-L40E to a 1785-L80E.

2) That PID is not scheduled correctly; that may not be the primary problem right now, but let's speculate:

2.1) From various info found via the The Google it appears that a PLC-5 Logic Scan Time can be anywhere from no faster than 6ms to 500ms and up. I think my brother told me that PLC-5 logic is interpreted, not compiled; that and the age of the PLC-5 line makes those numbers seem reasonable.

2.1.1) So the 0.1s (100ms) Loop Update Time in the PID configuration menu is not unbelievable, and may actually be correct, even if by luck (or coincidence, as @Ken Roach said), or it may have been empirically determined via the "I watched S:53 and S:54 online for a few minutes on the -L40E" method, perhaps with an unconsummated "I'll fix it later" on the side.

2.2) We don't know your process, but the T_i and T_d tuning time constants are 10 and 3 minutes, so this process is slow, in which case an estimate determined via the method in (2.1.1), while something less than best practice, could certainly produce workable results.

2.3) My point is that any error in the entered Loop Update Time, which error is almost certainly no more than a factor of 15, is not so big it could not be absorbed and corrected for in those large-ish tuned values of T_i and T_d, assuming the process was manually tuned at some point.

So while tuning, and especially the Loop Update Time, is suspect and should be done correctly at some point, I would put a pin in that line of investigation for now, and look into the duplicate declaration of the PV and CV first.

2.4) Also, even if the -L80E were twice as fast as the -L40E, so the 0.1s Loop Update Time in the replacement -L80 is now "suddenly" off by a factor of two, I would not expect that to throw a huge wrench into just this one PID control loop, because if it did, then it would affect the other PIDs as well.

I.e. Loop Update Time is a problem, but I don't think it's the primary cause of what OP is seeing, although admittedly we still do not know exactly what that is.

 

[alan_505]

Define "not seem to be controlling properly anymore" and "is not behaving."

Also, is this one PID the only one with a duplicate declaration of the same word for its Process Variable and Control Variable?

I will need to look through the rest of the program to see if there are any more PID's programmed with the same PV and CV.

 

[drbitboy]

N407:75 is coming from a 1794-IE8 card and is the level of a hopper of liquid product.

Haha I eventually stumbled onto that 30840 (and | is a divide operator, not a bitwise OR? wow, half my life I have been totally clueless about this cool industry y'all are in ) being 20mA in Flex I/O scaling.


Interesting: a liquid level measurement is used as the Setpoint to a PID. Maybe the PID equation and algorithm are being used as a poor man's filter?

 

[Ken Roach]

I took at look at the PD block configuration and saw that the Loop Update Time is set for 0.1 seconds.

That is additional very strong evidence that this loop worked by coincidence in a heavily-loaded PLC-5/40.

If you can't get the scantimes from the PLC-5/40 easily, put this logic into an STI set for 100 ms and that should get you close.

 

[alan_505]

It is a very thick hot liquid the 4-20mA signal is actuated on the back end of a pivoted float that sits on the product.
It seems that they control the deposit conveyor speed to keep the hopper level as constant as possible, the feed pump to the hopper is running at a fixed speed.

 

[drbitboy]

So the output CV from this PID controls the outlet flow of this thick liquid from the hopper, and the PID goal is to maintain some level in that hopper?

Does the float send out a higher signal (e.g. 30840 = 20mA)for lower level, and a lower signal (e.g. 0 = 4mA) for higher level?

That might explain why the measured level value goes to the PID SP input, and presumably the target level (i.e. process setpoint level) would go to the PV, although a more common practice would be to configure the PID Control Action to be reverse (E=SP-PV, instead of direct E=PV-SP) and send the measured level value to the PID PV input.

Having N347:10 as both PV and CV parameters for the PID still has to be an error though. I would be looking for rungs and instructions that read or write that value.

 

[drbitboy]

This is MicroLogix/RSLogix 500 and not PLC-5/RSLogix 5, but it does work with the same file element, N7:22, as both Process Variable input and Control Variable output parameters of the PID.

HOWEVER, N.B. that the actual PV input value is written from N7:20 immediately before the PID runs, and the CV output value is read to N7:21 immediately after the PID runs. I shudder to think what would happen with the PID in Manual mode, when that N7:22 value, MOVed from N7:20, would be interpreted as both the current value of the PID PV input and also the manual setting for the PID CV output, used to calculate PID internals for bumpless transfer, etc.

I don't see any way that could be made to work (maybe the PID is never in manual mode?), so the question is why would anyone go through all the trouble do it this way? Having N347:10 as both parameters almost certainly has to be an error in the program file.

Or am I missing something?

​

 

[MaxK]

It does not seem to be controlling properly anymore

What made you think so?

for now, and look into the duplicate declaration of the PV and CV first.

This is extremely unprofessional (same PV and CV), but I think this design is workable.
correction: could it be that PD9:29 is not performed on every scan?

I suppose that it was like this: coder first inserted and tune PD9:13, but then, something went wrong and he added CPT, GRT_MOV, PD9:29, SUB - it's looks like scaling or smthn

It would be nice to see the settings for PD9:29 and to know what N407:75 is.

 

[shanefaulkner]

(and | is a divide operator, not a bitwise OR? wow, half my life I have been totally clueless about this cool industry y'all are in )

| is divide. Countless times I've typed / and been confused why it would not accept the change. It was probably a decent idea since the slash is used to indicate bits in an address (B3/100, N7:1/15).

 

[drbitboy]

Also, I just noticed, from Post #4 of OP,

• that the CV output of PD9:29, also N347:10, which should have a range of 0-4095 from the PID, has an offset of 1627 substracted and the result put into N347:9
  • there is no name or description on N347:9
  • 1627 is 40% of the available output range of the PID, and
• that N347:9 value with the offset is used as the PV input into the next PID, PD9:13, and
• the CV output of that PD9:13 PID is scaled with a CPT to F8:50 named DEPOSITOR_SYRUP_LEV with a description of "DEPOSITOR SYRUP LEVEL," and
• The F8:50 value is MOVed to N522:10 named O_M010502_VHZ with a description of "Depositor Main Drive"

From the little we know, here is how this small part of the process appears to be designed to operate.

Those duplicate PV/CV parameters (N347:10) are a either a clever puzzle or an error. Is N347:10 written to anywhere else?

Where does the SP for PID PD9:13 come from?

​

 

[MaxK]

could it be that PD9:29 is not being executed on every scan?

The OP states that the problem is only with this PID
I think that this is the only loop in which the scaling algorithm is applied, using PID.

If on the old (slow) CPU the scan was long, so the processing of DP9:29 was longer than the scan-time, with an increase in CPU performance, the scan-time was reduced, so there were scans in which DP9:29 did not process. Thus N347:10 will take on seriously different values

 

[drbitboy]

My money is on differences between -L40E and -L80E being things like memory and I/O capacity, not CPU clock or speed.

So I think the two PLCs scan at roughly the same rate (say ±5-10%), not enough to effect a problem with the PIDs. Note that the other PIDs are operating correctly in the replacement -L80E.

This could be tested by OP by comparing the S2 File data (S:53 and S:54) for both systems while online, not offline (the value shown in Capture3.PNG are 0, so it was probably offline).