PLC5 PID after processor upgrade

[alan_505]

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?

View attachment 65026​

I have updated drbitboys picture.
N347:10 is only used in the PID and the SUB after the PID.

 

[MaxK]

My assumption can be checked easily:
applying for PD9:29 CV and next SUB source B unused (clear) memory cell

 

[alan_505]

My assumption can be checked easily:
applying for PD9:29 CV and next SUB source B unused (clear) memory cell

Not sure what you mean.

 

[alan_505]

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).

I loaded the old program into another L40E and ran it without any IO attached and the scan time is less, 30 to 40 versus 40 to 55 for the L80E actually running the process.

S:53 and S54 on both processors are at zero as STI is not being used in both programs.

 

[alan_505]

What made you think so?



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.

It was producing bad product because the conveyor/depositing speed was varying by a large amount, you could hear the system slow down and speed up.
All 17 of the PID's in the program were triggered every scan, I have put a 100ms time for PD9:29 and PD9:13.

There is 2 more PID's that are using the same tag for PV and CV, on one of them it feeds the next PID's SP and on the other the CV does not appear to do any this that I can find in the program.

 

[alan_505]

Hopefully the last 3 posts clear up any questions, if not let me know.

Production are very happy with how the machine is now operating, it is close to or better than it was with the L40E.

 

[MaxK]

Not sure what you mean.

#4
PID PD9:29 Control Variable: N347:10
(next)
SUB Source B: N347:10

N347:10 - replace this "address"/"variable"/"memory cell" with any "address"/"variable"/"memory cell"(the same type) not used in the program

 

[alan_505]

#4
PID PD9:29 Control Variable: N347:10
(next)
SUB Source B: N347:10

N347:10 - replace this "address"/"variable"/"memory cell" with any "address"/"variable"/"memory cell"(the same type) not used in the program

Which one am I replacing the N347:10 in the CV of PD9:29.

or

Replace the CV and the N347:10 in the SUB instruction.

 

[drbitboy]

I have updated drbitboys picture.

Fixed another typo as well: I had swapped the sources on the SUB instruction; fixed now (see below).

N347:10 is only used in the PID and the SUB after the PID.

But that SUB Destination result does feed the level PID (PD9:13) that controls the depositor/conveyor speed, so N347:10 and PD9:29 are both part of the control scheme.

I realize the process is working now so you have better things to do and this is at best academic, but that PD9:29 configuration (N347:10 as both PV and CV parameters) makes no sense whatsoever. In normal operation it will drive the output CV (and therefore the input PV) to either 4095.0 or 0.0.

​

 

[drbitboy]

I loaded the old program into another L40E and ran it without any IO attached and the scan time is less, 30 to 40 versus 40 to 55 for the L80E actually running the process.

That makes sense; so it was not the change in actual loop update time time that caused the problem.

 

[drbitboy]

N347:10 is only used in the PID and the SUB after the PID.

So nothing else other than this PID(PD9:29), i.e. not a COP or a or a BTR or a BTD or 16 OTEs/OTLs/OTUs, etc., is writing to N347:10. Is that correct?

 

[alan_505]

So nothing else other than this PID(PD9:29), i.e. not a COP or a or a BTR or a BTD or 16 OTEs/OTLs/OTUs, etc., is writing to N347:10. Is that correct?

Not when I do a find all.

 

[drbitboy]

Not when I do a find all.

Ah. that would find a MOV or an ADD i.e a simple single assignment with N347:10 as the Destination parameter.

It would not find any of these

• COP I1:0.1 #N347:0 11
• BTR with control block covering N347:10 e.g.
  • Control block is N7 where
    • N7:1 (.RLEn) is 11,
    • N7:3 (.FILE) is 347, and
    • N7:4 (.ELEM) is 0.
• etc.

 

[MaxK]

Hopefully the last 3 posts clear up any questions, if not let me know.

PD9:29 settings?
#39 picture PD9:29 feedback is POSITIVE - it's unstable

 

[MaxK]

If N407:75 value > 1 then PD9:29 SP = 4095
(Am I right or was I being inattentive again?)

If so, then in #39 block diagram, PID controllers have no information about the tank-level