Help writing plc code for a bag filling process

[parky]

Generally speed of filling is a production must, just run at the highest speed you can until nearly full, then slow it down maybe you need say 3 speeds.
It's just a matter of trials Done this many times with liquids & solids in various ways, valves conveyors vibrators cones.
The only other things to consider is ramp down time perhaps a quick ramp down on the settings for example a VFD often will have ramp times set in seconds or part thereof, reduce the ramp down time to minimum perhaps have the final kg or lbs where you slow to a trickle plus a small in-flight value to allow for the delay before the last of the product is in the container.

 

[parky]

Here is some simple logic for speed change, so if the actual weight is below the first stage set point then run at full speed, if it then rises above first stage set point then run at x speed, then when the weight reaches second stage run at final stage set point, when the weight reaches required weight minus an in-flight stop the motor.
So although I'm showing variables for these set points you can leave them like this so they are changeable during run time (on an Eng screen on HMI) or even put fixed values in there.
So you have the following
Required Weight (Weight)
First Stage Set point (Weight)
Second Stage Set point (Weight)
In-flight (if needed)
VFD Full speed set point
VFD First Stage set point
VFD final stage Set point (Trickle)
It depends on the required accuracy, mechanical & product properties response, how many stages you have and the set points etc. but I have used this many times in one form or another for oil, rice, milk, starch and many other ingredients with good accuracy.

 

[drbitboy]

... I have used this many times in one form or another for oil, rice, milk, starch and many other ingredients with good accuracy.

All of the theorizing may be interesting (or not), but this is the crucial piece of any answer I would be looking for if I actually had to do this.

Especially considering the limitations of Siemens' brain-dead, incorrectly-implemented NORM_X that requires extra complexity to be used in this case, @parky's simple, easily-understood, tested solution is a breath of fresh air.

P.S. this is not in any way meant as a critique of @sigmadelta's advocacy for my earlier post; I appreciate it, I really do. But "this works" is simply the better answer. Also, to my eyes, the approaches are the same in essence; one is just a bit more discrete.

 

[drbitboy]

Also, just to keep our tradition alive, for extra credit, I would like OP to tell us what happens with @parky's code in the unlikely, nay, impossible, event that the weight is exactly 78 when the fill starts? And what would be the easiest way to fix it (even though it does not need fixing).

 

[drbitboy]

Using the PID in this fashion is using a sledgehammer to crack a nut,

I am stomped rn . i cant find a way to do this

Yes you can. The way to do it is to stop thinking of a PID as this:

and start thinking of it like this:

= PID control variable

= proportional gain

= error value

= integral gain

= change in error value

= change in time

 

[thewalkerist]

Also, just to keep our tradition alive, for extra credit, I would like OP to tell us what happens with @parky's code in the unlikely, nay, impossible, event that the weight is exactly 78 when the fill starts? And what would be the easiest way to fix it (even though it does not need fixing).

Oh now you got me on my toes i am excited.

Hmm if you are looking for the easiest answer then my guess would be to put >= to the second rung instead of just >. That way VFD will be automatically start at 80 speed right?

If that doesnt work maybe i can do as the master @parky says and put some steps in there and put a condition there and say that when the value is 78 forget about the first step and just go for 80 speed or something like that.

I need to test that tho .I guess i've failed. I need to do my homework more

How many points did i get?

Btw how do you guys tag ppl when you quote from them? it seems i cant.

 

[thewalkerist]

Here is some simple logic for speed change, so if the actual weight is below the first stage set point then run at full speed, if it then rises above first stage set point then run at x speed, then when the weight reaches second stage run at final stage set point, when the weight reaches required weight minus an in-flight stop the motor.
So although I'm showing variables for these set points you can leave them like this so they are changeable during run time (on an Eng screen on HMI) or even put fixed values in there.
So you have the following
Required Weight (Weight)
First Stage Set point (Weight)
Second Stage Set point (Weight)
In-flight (if needed)
VFD Full speed set point
VFD First Stage set point
VFD final stage Set point (Trickle)
It depends on the required accuracy, mechanical & product properties response, how many stages you have and the set points etc. but I have used this many times in one form or another for oil, rice, milk, starch and many other ingredients with good accuracy.

If this works for you than i guess it would serve me aswell but i am kinda sad about it. I wanted to make it self-learnable. Like an AI ya know? After beginning with those thought i feel like i am cheating rn. Cant i give some commands to PID to make it more fast in the end or something?

I guess i will use your logic since i cant accomplish anything else by myself

I feel like i cant imagine a solution. I am thinking about it constantly and trying things out in the programme, new logic, new ideas, new stuff but i cant find a way around this

 

[drbitboy]

my guess would be to put >= to the second rung instead of just >.

Full marks. Or <= on the first rung of course. Or remove the first rung's [ANDE<] instruction altogether.

Btw how do you guys tag ppl when you quote from them? it seems i cant.

Not sure I understand; I click the

button under the message instead of the

button at the top.

 

[thewalkerist]

Not sure I understand; I click the

button under the message instead of the

button at the top.

ohhh i get it. Thank you teacher :nodi:

 

[drbitboy]

I feel like i cant imagine a solution.

In the context of PID control, e is error, i.e. [Present Value - Setpoint Value] (or vice versa). The PID algorithm (above) adjusts its output, u, to drive the Present Value (PV) to the Setpoint Value (SP), which is the same as saying the PID algorithm drives the error to zero.

The output, u, of the PID algorithm is the sum of three terms:

1. Proportional Term, [Kp times error]
   1. Moves the output linearly with the error
   2. Bigger error magnitude on the current scan means a bigger contribution from this term to the output magnitude
   3. Kp is the Proportional Gain
2. Integral Term [Ki times Integral(dt)]
   1. Moves the output linearly with the accumulation of error over time
   2. Bigger error magnitude means bigger a bigger contribution to the output magnitude from the current scan, but that contribution - from this scan - will not change after that.
   3. However, a longer time over all scans up to the current scan, with error either always positive or always negative, means a bigger contribution from this term to output magnitude
   4. Ki is the Integral Gain
   5. Setting Ki = 0 turns off the integral contribution
3. Derivative Term [Kd times de/dt]
   1. Moves the output linearly with the rate of change (velocity) of the error from the previous scan to the current scan
   2. Bigger changes in error magnitude from the previous scan means a bigger contribution from this term to output magnitude
      1. If the error magnitude is large, but does not change from scan to scan, then this term's contribution to the output magnitude is zero
   3. Kd is is the Derivative Gain
   4. Setting Kd = 0 turns off derivative term's contribution

Per the statements in blue above, setting Ki = Kd = 0 will leave only the Proportional Term to set the ouptut u. In that case the output value will be linear with with error. If we also define error as e = [(Setpoint Weight) - (Current Fill Weight Measurement)] and use a positive Kp, then

1. The output u will be bigger when the (Current Fill Weight Measurement) is less, and
2. The output u will get smaller and approach 0 as the (Current Fill Weight Measurement) increases and approaches the (Setpoint Weight)

If the output u is the speed command to the [Material Feeder Motor], then this is exactly how we want the system to behave. The only things left to do are to

1. Determine the setpoint (when the motor speed would hit 0)
   1. This is more or less the equivalent of the highest stage setpoint in @parky's approach
   2. This number is related to, but it is not, the (Target Fill Weight)
   3. This number will be larger than 100% of the (Target Fill Weight)
2. Determine the gain, Kp
   1. This is more or less the equivalent of the lowest state setpoint in @parky's approach
   2. This determines the error value at which the output will be 100%.
      1. A gain of 4.5 (~100/(100-78)) would output 100% for u for all measured weights below 78% of the input PV range.
   3. I would hope the Siemens PID has the ability to clamp the output to 100%.
      1. If it does not, the value could be copied and clamped downstream of the PID

 

[drbitboy]

P.S. the only point I am trying to make is that it is straightforward to use a P-only PID as a scaling function. It may look a little cleaner than @parky's step-wise approach, but the latter can achieve the same by being encapsulated in an FB.

The actual application would adjust the setpoint and the proportional gain to compensate for the physical system's characteristics, but the basic idea is shown below.

It is still using a timer .ET as the (PV) fill measurement, and the timer .ET is linear with time, while the PV would be non-linear with time as the motor speed is reduced, but this does shows the response of the output to the PV.

If there was any AI involved, it would be to optimize the setpoint and the gain values against some criteria e.g.

• Mean fill weight equal to target fill weight
• Fill weight standard deviation within some range
• Minimum time to fill one package

 

[parky]

I really do not see the point of using a PID even as a P only controller, the idea of PID control is to bring it up to set point & hold it there, in a batching process you do not hold it, once set point is reached the process ends, all you are doing is running at max until approaching set point then slowing it down & stopping, the problem is that as it approaches set point the rate of weight gain falls so the PID will try to increase it. Using P only will almost certainly slow the fill overall process, I can go back to a number of scenarios where customers have "Just because they use a particular controller" insisted on them being used, even on what is considered ideal for PID, one example was a cooking process for a sandwich filler product, this contained a made up mayonnaise with vegetables & meat. Seems ideal for bringing up a sauce to a temperature then holding it there for x minutes, NO, it did not work, the problem is that as the sauce thickened the vap injects (yes direct steam injection not jacket) caused it to blast through the sauce, the PID saw this as a lack of increase in temperature so then increased the output, this then just had no effect, the product would not achieve set point quickly enough so eventually the PID output was at 100%, the customer then brought in the controller company expert & after a number of hours he had to agree with me that PID was useless, the answer I came up with was to bypass the controllers & in the recipe had 5 set points for setting the control valves to pre-sets depending on the product. this then achieved the desired curve in reasonable time.

 

[drbitboy]

The use of the PID was only a thought experiment to get around the limitation of the broken NORM_X function in Siemens, and to expand OP's vision. The code I wrote is functionally equivalent* to the code the OP should use i.e. to @parky's staged approach.

* with a higher granularity, i.e. more "stages."

the problem is that as it approaches set point the rate of weight gain falls so the PID will try to increase it ...

I respectfully disagree. This would not happen because it is not a PID, it is P-only; as long as the motor is running the measured weight will continue to increase***, and, as verified by the trend image, as long as the measure weight continues to increase, the P-only P(ID) will decrease the motor speed.



My algorithm is P-only, so Integral and Derivative action are disabled. Therefore it would not have the same problem as the mayo/sauce, which was caused Integral and/or Derivative action**; proportional action would have either the opposite effect or no effect when the measured temperature rise either slowed or halted, respectively.


** I and/or D reacted to the temperature not progressing to setpoint; the sauce thickening changed the process, which invalidated the PID's model. Even if the sauce's measured temperature did drop, which would cause the P action to contribute to the problem, the same will not happen in the bag-filling process: as long as the motor is running the measured weight will increase***.


*** assuming the bag is big enough to hold the targeted weight; and if that is true then even @parky's staged approach algorithm, or almost any algorithm for that matter, will also fail.

 

[drbitboy]

This is bang-bang control, and we are debating the size (slope) of the bang.

 

[thewalkerist]

it seems it is not wise to use PID for this kind of application. It seems weird just having 2 or 3 or 4 or 5 setpoints but i am the newbie here. If you guys say so then it must mean that all of the applications like this use this kind of thing.