Slowing a motor relative to weight increase speed

[drbitboy]

@walkerist:

many here could write the code, and have done so in the past, using any of a number of models/algorithms/approaches, but you are a student, so we are going to wait to see what you code first.

However, before you write even one line of code/ladder, show us your model. That's the hard part; the coding is easy.

E.g. forget all my stuff, just use the model where you predict an in-flight/tail/spill value INFLIGHT, that will fall into the bag after the PLC gets a measurement equal to or greater than [TARGET_WEIGHT - INFLIGHT] on some scan and stops the motor. Write that code, but make INFLIGHT a variable e.g. loaded from an HMI.

The problem is that the in-flight value will probably vary with the fill rate, even if the motor speed is a constant 100%. Write some code to vary a maximum MAX_INFLIGHT value* for variable fill rates, and then use write code to use that variable in-flight value to have the PLC stop the motor using the modified fill rate.

Note that now you have to

• write code to measure the fill rate continuously,
• come up with a model to calculate and in-flight value based on MAX_INFLIGHT and the measured fill rate,
• write code to implement that model.

* the MAX_INFLIGHT value will be suitable for

• 100% motor speed,
• washer not starvation-feeding the conveyor,
• 0.5g/ms (10kg/20s = 10000g/20000ms) fill rate.

 

[drbitboy]

Yes, but I thought the OP wanted the motor speed as function of weight.

OP already did that before the first post.

But, if we read between the lines, there is a problem: if the washer is starvation-feeding the washer-to-bag-filler conveyor, having breakpoints fixed in weight make the bag fill take too long, and indeed reducing the motor speed is not necessary at all.

So what OP has not yet noticed is that the breakpoints should be some direct function of ([remaining weight to be filled] / [measured fill rate]), which has units of time.

For [some] reason you have it at 25%.

Yes, because having Vmin = 0% means it never makes the fill target; better to pick a positive number, drop it to zero when the measured weight exceeds [target weight less in-flight predict] with the hope that the actual in-flight will make the final fill, but continue measuring in case that hope is in vain, in which case a second or so at a low motor speed can be used to get to the target weight.

 

[Peter Nachtwey]

In any case my equation still applies.

 

[drbitboy]

In any case my equation still applies.

Well, yeah, of course: it's a special limited case of the same (differential) equation (solution) I am using; I never said it did not apply.

 

[thewalkerist]

Happy new years!! I am back. I apologize for the long wait. Exams took longer than i expected and i had to go back to my town for a couple of weeks.

So i tried to do something with couple of math instructions.And it kinda works but i have some issues with this as well. Let me explain the system a bit first.

In our first network we have our initial activation and after the activation we start to wait for 5 seconds and after 5 seconds we move our weight value into a Val_2_Store value. After that we subtract our Val_2_store which is 800 in this instance from our Val_1_Store And after the subtraction we see how much our weight has changed in 5 seconds. What is Val_1_Store though? That was 0 at the time of subtraction but after we completed our subtraction task we pulse for 2ms and de-energize instantly which is basically nothing and then moved our Val_2_store into the Val_1_Store and then it became 800 as well so that in the next 5 seconds we can see our change from 800 to the next value.

In our second network we calculate how much weight should be added every second. In this instance i wrote 1000 grams should be filled in 5 seconds which makes it 200grams/second. So target speed is 200grams per second.

Now in our third network we divide our change(Val_2_Store(800)-Val_1_Stoere(0)=800) with our time and we find how much our motor currently fills every second. In this instance we fill 160grams/second but we needed it to be 200grams/second. So we divide our target fill speed(200) with our current fill speed and we find our ratio. It is in this instance 1.25 SO we must multiply our motor speed with this value. so that in the next time our motor run faster and try to reach that value.

Currently our motor speed is 100% so it needs to be 125% in order to reach 200grams/second. Now 125% is impossible but if the motor is running at full speed and it still isnt enough the problem is not on our program rather its on the product feed since its not enough to meet our expectations. So we must either lower our expectations so that our motor would be enough or we must add more product. THAT is not my current concern though. I am currently assuming it has enough feed. So lets say we have in this instance 50 motor speed rather than current 100%. Then we would 50x1.25=62.5 and our motor would run at the nice cool speed of 62.5%. BTW dont worry i've made the same calculation so that if its too fast my motor would slow down to achieve my 200g/s. I just didnt include it because it didnt fit and its kinda the same logic with the third network just with a little bit of tweaks.

Now this calculation works kinda nicely but i have a problem with this. Let say i am trying to fill a box to 10kg(10000grams) And my original setup still stands. So every second i want it to fill 200grams so according to this speed it would take about 50 seconds to finish filling up. That is my ideal finishing time. Lets say we are up to the 5kgs and 25 seconds have past. Everything is going well. But after 5kg it takes about 160grams per seconds rather than our ideal 200g/s. Now lets say after our current system saw this it changed the speed from 50 to 62.5% and from now on it will go with 200g/s right? Yeah But what about lost 40 grams? i mean we corrected our speed to 200g/s but we lost 40 grams along the way. And you can say 40grams is not a lot but wait. Why wont we make up for our lost 40 grams with more speed to motors so that it would fill 240 grams instead of the usual 200 grams right? And after 240grams gets filled we can return back to our 62.5% speed. And if in the next 5-10 seconds fill gets more faster lets say 300g/s we can lower the speed down so that we have a more stable system that finishes really close to our desired time of 50seconds rather than 25 seconds or 80 seconds. I want my motor to try to achieve stability. That is where i am stuck currently, and im open to ideas. I feel so close. It's in the tip of my tongue but i cant make it Please help

 

[drbitboy]

[Update: rather than updating Fill_Remaining by subtracting the measured change (Val_2_Store - Val_1_Store), [SUB 10000 Val_2_Store Fill_Remaining] would be more direct.]

The code shown in the OP is a type of feedback controller of product feedrate:

• every 5s (five seconds),
  • it uses two measurements,
    • which measurements were taken at the beginning and end of those 5s,
    • to calculate the actual feedrate (Present Value, PV),
    • and adjusts the motor speed (Controlled Value, CV)
      • to a value that is intended change the actual feedrate
      • to the target feedrate (Set Point, SP, 200s),
        • which setpoint is fixed by the process i.e. 1kg/5s => 200g/s by Network 2
    • which adjustment is made assuming a linear model of the relationship between CV and PV,
      • specifically PV = k*CV,
        • where k is a proportionality constant that is recalculated every 5s from the measured data.

The overall target fill time, from the start of the fill, is not present in that calculation other than to calculate the target fill rate. So if the PV is 40g/s low i.e. measured PV is 160g/s during the past 5s instead of 200g/s duirng the past 5s, then the process has "lost" 200g (=40g/s * 5s) along with the concomitant time needed to replace those 200g, and the current algorithm has no way to compensate for that.

If it is instead desired to finish accumulating 10kg at a time 50s after the start of the fill using a feedrate as constant as possible, then the feedrate's feedback control algorithm should model that instead, and the SP (Target_Speed %MD62), should be recalculated differently than it is now in Network 2, using the formula (Fill_Remaining, g)/(Time_Remaining, s), where

• Fill_Remaining and Time_Remaining are initialized to 10000g (10k) and 50s, respectively,
• and are reduced every 5s by measured changes in weight (Val_2_Store - Val_1_Store) and in time (5s), respectively.

The algorithm will need to use an initial speed estimate for the first 5s period.

Example:

• At time 0s out of 50s, the initial Fill_Remaining is 1000g (10kg), and the initial Time_Remaining is 50s.
  • Assume the initial motor speed is 50%,
    • and the actual feedrate is 160g/s,
      • which is 40g/s short of the target 200g/s (=10000g/50s).
• At time 5s out of 50s,
  • 160g/s will be the calculated flowrate at 50% motor speed
  • 800g (=160g/s * 5s) will be the calculated change,
  • Fill_Remaining will be 9200g (10000-800) [N.B. See Update above]
  • Time_Remaining will be 45s (50-5)
  • The new target feedrate (SP) will be 204.4g/s (9200g/45s)
  • The new motor speed will be 63.9% (50 * (204.4/160))
• At time 10s out of 50s, assuming the linear motor speed-to-feedrate model used at time 5s is correct,
  • 204.4g/s will be the calculated flowrate at 63.9% motor speed
  • 1022g (=204.4g/s * 5s) will be the calculated change,
  • Fill_Remaining will be 8178g (9200-1022) [N.B. See Update above]
  • Time_Remaining will be 40s (45-5)
  • The new target feedrate (SP) will be 204.4g/s (8178g/40s; no change)
  • The new motor speed will be 63.9 (63.9 * ((204.4/204.4); no change)
• At the end, at time 50s out of 50s, i.e. 40s after the previous calculation,
  • another 8178g (204.4 * 40) will have been filled,
  • and the total over that 50s would be 10000g (800 + 1022 + 8178).

Caveats

• It is numerically possible to calculate a negative SP and motor speed.
  • This should be protected against with specific code
• More generally, the motor speed should probably be clamped to a range of 0% to 100% at every 5s interval.

Side issues

1) The fourth instruction in network 1 appears to be a SUB, and it subtracts Val_1_Store from Val_2_Store, not the other way around.

2) The second timer instruction in Network 1, with PT:=T#2ms, will never finish if it's a TON because its input RLO is a one-shot, assuming the scan time is less than 2ms; if that T#2ms timer is a TP instruction, then the output Q will be 1 as soon the input RLO changes from 0 to 1, and that happens when the first (TON) timer completes, not 2ms later. So that timer does nothing and can be removed.

 

[drbitboy]

Here it is

It still needs to clamp the output (Needed_Speed %MD26).

Formula in middle branch of Network 2 is

              SP
CVn = CVn-5 * --
              PV

where

• CVn is the output of the feedback algorithm at time n
• CVn-4 is the previous output of the feedback algorithm i.e. at time (n-5)
• SP is the target feedrate, (Wrem / Trem)
• PV is the measured feedrate over the past 5s, (Change / Tsample)
• Wrem is the measured Weight Remaining at time n, (10000g - Current Weight)
• Trem is the Time Remaining to 50s since the start of filling, (50 - n)
• Change is the difference in measured weight since the last sample, (Wrem - Wrem(n-5))
• Tsample is 5s, i.e. the sample time i.e. the PT of the timer, (n - (n-5))