JohnDruzianic

Brief Process Description: Carpet leaves an oven (at approx 2 metres/minute), is pulled into an Accumulator by an Entry Roller. It is pulled out of the Accumulator by an Exit Roller. From the Exit Roller it spills into a "J Bin". Downstream from the J Bin the carpet is rolled up into Carpet Rolls for dispatch using the Roll Up Roller. Carpet travel through the oven must not stop. If carpet is not being rolled up, it will build up in the Accumulator. The Accumulator comprises two pairs of parallel horizontal beams. Horizontal rollers are fixed between each pair of beams. Carpet is threaded between the rollers in a zig-zag. The top pair of beams is fixed. The bottom pair of beams will float as the carpet builds up in, or is pulled out of the Accumulator. The purpose is to control the speed of the Accumulator Exit Roller. A pair of PID instructions will be used. One for Coarse speed control and one for fine speed control. The coarse speed is determined by either the Roll Up roller (if carpet is being rolled up) or the Entry Roller (if carpet is not being rolled up and the Accumulator is sitting on the bottom springs). If the Roll Up roller is stopped and the Accumulator is lifted off the bottom springs, the Exit Roller remains stopped and carpet builds up in the Accumulator until the Accumulator bottom beam rests on the bottom springs. Then the Exit Roller starts at the same speed as the Entry Roller. If carpet is being rolled up, the height of the carpet web above the J_Bin is measured and the Exit Roller speed is adjusted to maintain the height of the web at a set value using the fine PID. If the speed of the Entry Roller is used for coarse control of the Exit Roller, the speed of the Exit Roller is finely adjusted by measuring the sag of the carpet underneath the first incoming roller of the Accumulator and maintaining that sag using the fine PID. The Problem: My problem is that the Exit Roller (in order to keep up with the Roll Up roller) will have to lift the combined mass of the carpet and the bottom pair of beams (and rollers). At that stage the dymnamics are different from when the Accumulator bottom beams are resting on the bottom springs. Should I use the same pair of PID instructions regardless and have the PLC (Schneider Twido) change the Kp, Ki and Kd values depending on whether the Acuumulator is resting on the bottom springs or has been lifted off the bottom springs ? OR Have a separate pair of PID instructions (which have their Kp, Ki and Kd values fixed) to take over control when the Accumulator is lifted of the bottom springs. The non-active pair of PID instructions are set to manual mode and they track the active pair so that bumpless transfer can occur.

I have two techniques for programming alarms which require an alarm_active output and a new_alarm output. The alarm_active output is on if any alarm is active. This output can drive a light. The new_alarm output is on whenever an alarm first occurs. The output stays on, even if the alarm becomes inactive, until it is acknowledged. The new_alarm output can drive a siren or a pager. There is an alarm_now bit for every condition (e.g. a proximity switch continues to indicate that a valve is not closed for a certain time while the controller has energized the output to close the valve). A file contains all the alarm_now bits. The alarm_before file contains the alarm_now bits from the previous scan. The first technique is clever, efficient, but hard to understand because it uses file based instructions to generate the new_alarm output. On every program scan the alarm_now file is exclusive-or compared with the alarm_before file. The results of the comparison are in a file which can be called xor_alarm_now_before. Then it is necessary to isolate alarms that have just occurred from alarms that have gone away. This is achieved by anding the xor_alarm_now_before file with the alarm_now file. The result is a file which can be called the alarm_new file. It contains a 1 for every new alarm that has appeared during the current program scan. The alarm_new file can trigger the new_alarm output if the file contains a 1. Finally the alarm_now file is copied into the alarm_before file and the system is ready to respond to another new alarm. This technique can cause insanity to someone trying sort out a problem at two in the morning. Finally, to ensure that there are no new alarms when the Controller first powers up, the alarm_now file is copied into the alarm_before file on the first program scan. The second technique is less clever, consumes more program memory but is easy to understand because the logic is obvious and not buried in file based instructions. For every alarm condition as represented by an alarm_now bit, we have a statement that that is executed every program scan that says If alarm_now AND NOT alarm_before Then Alarm_new The alarm_now, alarm_before and alarm_new bits can still reside in a file but the essential difference is the use of the above statement for each alarm condition. The above statement does all the work for an alarm condition that is achieved by the file logic in the first technique. Alarm_new is true for the first scan that alarm_now is true until the alarm_now file is copied into the alarm_before file. Also, to ensure that there are no new alarms when the Controller first powers up, the alarm_now file is copied into the alarm_before file on the first program scan.

Client has lost the back-up programme for this PLC. The programming software ( FST4.0) requires that this back-up be resident on the lap-top before it "reads" the programme out of the plc. An upload of the programme is not permitted (?) with this type of plc unless a back up is installed on the laptop. Tis is a "catch-22" situation. Is there a way out apart from a new plc and an expensive rewrite. I do have a paper print-out of the progarmme. Help please.