Slowing a motor relative to weight increase speed

[arpus4KM]

Now, as you can see, i can only afford the weigher and the motors and the conveyor. Currently i dont have any money left to buy the hopper. I have small elevator that brings the strawberries to the washer, after that comes my bag filler. Now conveyor that connects washer to my bag filler is much smaller than my bag filler conveyor that has my motor i use for feeding product to the loadcell. So the strawberries are not coming at a fixed rate.

Plus Hoppers and strawberries are a bad couple. They would get squished underneath their weight. They are pretty weak

Then you should try to make it more consistent, you need some kind of buffer zone that builds up a specific amount of product before progressing, or else you'll need to add even more automated conveyor speeds and weight/vision systems on to determine when there are only just a few strawberries on the line, or your line will be running slow, expecting to fill at the same rate. yet filling much slower, and at the slower conveyor rate called for.


it's either that, or run the conveyor fast all the time and have some kind of cutoff to the fill area with a loopback for non-bagged product that can continue on it's loop until a new bag is inserted.

 

[thewalkerist]

Then you should try to make it more consistent, you need some kind of buffer zone that builds up a specific amount of product before progressing, or else you'll need to add even more automated conveyor speeds and weight/vision systems on to determine when there are only just a few strawberries on the line, or your line will be running slow, expecting to fill at the same rate. yet filling much slower, and at the slower conveyor rate called for.


it's either that, or run the conveyor fast all the time and have some kind of cutoff to the fill area with a loopback for non-bagged product that can continue on it's loop until a new bag is inserted.

Well, my motivation for doing this is solution based and i can see where you guys are coming from. But try to understand me as well, i am a student. I am trying to help my family farm. But my biggest motivation is that i am learning a lot of things about the plcs and programming. And that is mostly thanks to you guys. Without your help i couldnt solve those countless problems i've encountered.

I want to make that cascade concept happen. If i understand you correctly i need to find/define/set my"normal" fill rate in one step and scale the motor speed based on that. But i have no idea how to make that happen in the programme tho. Can you give me a sample project? I am using tia portal but i guess others wouldnt differ that much

 

[Peter Nachtwey]

This problems isn't much different than ramping down as a function of distance rather than time. In high school I learned that speed^2=2*acceleration*distance. Therefore the speed as a function of distance should be speed = sqrt(2*acceleration*distance). In the OP's case the acceleration is negative. Speed is the fill speed and the distances is the amount of weight yet to fill. Now fill_speed = sqrt(2*fill_rate_deceleration*(target_weight-actual_weight)). This formula will result in a linear ramp to a zero fill_speed as the weight error drops to 0. It would be best to run this routine fairly often because this routine will ramp down the fill speed in steps each time this routine is executed. The smaller the update intervals the smoother the ramp will be.

In practice the 2*fill_rate_deceleration will probably just be combined into a constant K so that fill_rate = K*sqrt(weight_error). K can be fudged with to provide a satisfactory point to start ramping down the feed_rate. K can also be calculated by using K=sqrt(weight_error)/Max_fill_rate.


My formula provides a linear deceleration ramp but it is possible to have s-curve deceleration ramps based on distance but the equations are MUCH more complicated.

 

[arpus4KM]

This problems isn't much different than ramping down as a function of distance rather than time. In high school I learned that speed^2=2*acceleration*distance. Therefore the speed as a function of distance should be speed = sqrt(2*acceleration*distance). In the OP's case the acceleration is negative. Speed is the fill speed and the distances is the amount of weight yet to fill. Now fill_speed = sqrt(2*fill_rate_deceleration*(target_weight-actual_weight)). This formula will result in a linear ramp to a zero fill_speed as the weight error drops to 0. It would be best to run this routine fairly often because this routine will ramp down the fill speed in steps each time this routine is executed. The smaller the update intervals the smoother the ramp will be.

In practice the 2*fill_rate_deceleration will probably just be combined into a constant K so that fill_rate = K*sqrt(weight_error). K can be fudged with to provide a satisfactory point to start ramping down the feed_rate. K can also be calculated by using K=sqrt(weight_error)/Max_fill_rate.


My formula provides a linear deceleration ramp but it is possible to have s-curve deceleration ramps based on distance but the equations are MUCH more complicated.

all of this is good, except if the system decelerates like it's supposed to when getting near a full bag, and there's not a consistent amount of product flowing, then he's better off just slowing the conveyor when the bag reaches 90% weight and leaving it there. bag gets to 95% and then takes another 2 minutes to finish filling because the system assumes there is enough product on the line to fill it in 5 seconds.


a PID loop won't work well to stabilize something if the mechanics of it don't allow for it right.

 

[celichi]

Well, my motivation for doing this is solution based and i can see where you guys are coming from. But try to understand me as well, i am a student. I am trying to help my family farm. But my biggest motivation is that i am learning a lot of things about the plcs and programming. And that is mostly thanks to you guys. Without your help i couldnt solve those countless problems i've encountered.

I want to make that cascade concept happen. If i understand you correctly i need to find/define/set my"normal" fill rate in one step and scale the motor speed based on that. But i have no idea how to make that happen in the programme tho. Can you give me a sample project? I am using tia portal but i guess others wouldnt differ that much

Not my area, but I would like to add this incase it helps you...

Some companies use Spill calculation, and adaptive cut off from previous fills. After you are done filling, measure the difference between what you wanted and what you actually ended up with, that number is the spill. Save the spill in the controller for Material X, and even average them in an array. Target - Spill is your new cutoff target.

 

[drbitboy]

If the motor is running at 100% of max speed from empty bag (0% bag full) to 90% bag full, and you also measure the time that it took to go from 0% to 90%, then you know the approximate rate.

E.g. say the empty bag's tare weight is taken at time 0s, and it gets to 9kg = 9000g, i.e. 90% full, at time 18s; the average rate over that time is 0.5kg/s = 500g/s.

Since the bag fill takes only 20s-30s, that 500g/s might - might - provide a reasonable estimate - i.e. prediction - of the ratio of the motor speed to the fill rate (g/s) for the rest of the bag.

Using @PeterN's approach, say you want do a linear ramp reducing motor speed from 100% to 30%, and the code will stop the motor when the measured weight exceeds 10000g. So, being engineers means we assume everything is linear at some scale, we make the assumption that the fill rate will be linear with motor speed, and we estimate 5(g/s)/%. So now the fill rate, which is also the change in weight with respect to time, is estimated as

dW/dt, g/s = 5(g/s)/% * (MotorSpeed, %)



W100% - W90% = DEFINITE_INTEGRAL||MotorSpeed=100% to MotorSpeed=30%||(5*MotorSpeed dt)



Let's shift the timeframe to make the math easier:



τ = t - 19



dt/dτ = 1



dW/dτ, g/s = 5(g/s)/% * (MotorSpeed, %)



W100% - W90% = DEFINITE_INTEGRAL||τ=0 to τ=τEnd||(5*MotorSpeed dτ)



Where



MotorSpeed = 100 - (100-30)*τ/τEnd = 100 - τ * (70/τEnd)



N.B. -70/τEnd is the ramp rate, %/s, of the motor, so we need to solve for τEnd



W100% - W90% = DEFINITE_INTEGRAL||τ=0 to τ=τEnd||(5*(100 - τ * 70/τEnd) dτ)



10000-9000 = (100*τ - 1/2 τ**2 70/τEnd)||τ=0 to τ=τEnd||



1000 = 5 * [ (100*τEnd - 1/2 τEnd**2 70/τEnd) - (100*0 - 1/2 0**2 70/τEnd) ]



1000 = 5 * τEnd * (100 - 1/2 * 70) = 5 * τEnd * 65 = 325 * τEnd



τEnd = 1000 / 325 ~ 3.08s



Ramp rate = -70 / τEnd = -22.75%/s

​

So the question is, can you ramp the % signal to the motor at a rate of 22.75%/s, for the given case?

The only thing that is going to change from bag to bag is the calculated fill rate, i.e. the 5(g/s)/% value above; the 100 and 30 and -70 and 65 will always be the same, so you can calculate the ramp rate at 90% from the t90, i.e. the time measured get from empty to 90% full (0g to 9000g):

RampRate, %/s =-70 / τEnd = -70 / (1000 / (((9000 / t90) / 100) * 65)) = -70 / (1000 / ((90 / t90) * 65)) = -70 / (1000 / (90 * 65 / t90)) = (-70 * 90 * 65) / (1000 * t90)



RampRate = -409.5 / t90



Checking the test case:  -409.5 / 18 = 22.75, good.

​

Again, this is a model that assumes the empty-to-90%-based rate predicts the future rate. And the critical part of any model is its level of fidelity. Who knows, maybe measuring from 40% to 90%, which discards data 10s and older, would be a better predictor?

I still think the time would be better spent figuring out how to accumulate strawberries at the feed to the motorized system so the rate is more consistent.

 

[JesperMP]

Some companies use Spill calculation, and adaptive cut off from previous fills. After you are done filling, measure the difference between what you wanted and what you actually ended up with, that number is the spill. Save the spill in the controller for Material X, and even average them in an array. Target - Spill is your new cutoff target.

We do that, except we call it "tail".

About the strawberries.
I see that it rules out the use of an intermediary hopper.
You are filling them into bags ? Doesnt that squeze the strawberries as well ?

I think the solution is to possibly make sure that the strawberries comes one at a time and with a tiny bit of separation between them. In the food packaging industry there are many ingenious solutions as this happens at a blistering speed, and I think it may take some know how.

I am guessing that you can use the scale to calculate the average weight of the strawberries and when you are getting near to the setpoint, instead of weighing the last strawberries you can count them with a photocell.

And yes, use the loadcell to detect the "spill" or "tail" and compensate in the next weighing sequence.

If this is packaging for sale, then there may be regulations you may have to adhere to.
If the bag says there are 500 g of strawberries then you may have to stay within some tolerances.

 

[drbitboy]

Tail = Spill = In-flight.


Search for posts with those terms in this forum; I imagine they will compose a proper codex!

 

[drbitboy]

I have small elevator that brings the strawberries to the washer, after that comes my bag filler. Now conveyor that connects washer to my bag filler is much smaller than my bag filler conveyor that has my motor i use for feeding product to the loadcell. So the strawberries are not coming at a fixed rate.

I think we have not yet understood the root of the problem: the motor does not control the bag fill rate of strawberries over the long term. It only delivers strawberries to the bag filler at the rate delivered to it by the washer.

So at whatever long-term rate, gram/second, at which the washer processes strawberries and puts them on the entrance to the conveyor, that is the rate they will come off the end of the conveyor. Increasing or decreasing motor speed will give a temporary increase or decrease in the bag fill rate at the exit of the conveyor, but when the last strawberry, which was already on the conveyor at the time the speed changed, exits the conveyor, the bag fill rate at the conveyor exit will drop back to whatever rate the washer is delivering strawberries to the conveyor entrance. Assuming a constant rate of washer output, the only long-term effect of conveyor motor speed is how many strawberries are on the conveyor at any time.

Caveat: this assumes the washer speed is independent of the conveyor speed; if they run from the same motor, then the process is limited by the delivery rate of strawberries to the washer, or perhaps delivery rate to the elevator if that is on the same motor as well.

 

[drbitboy]

I made a model of the washer exit and conveyor to the bag filler using clock memory and the SHL instruction to move bits (strawberries) through a 32-bit UDInt.

• The washer exit/conveyor entrance is modeled by changing bit 0 of the UDInt from 0 to 1 at 0.625Hz (slow washer/low density of strawberries) or 1.25Hz (fast washer/high density of strawberries)
  • It does this once, and just after, the conveyor shift trigger fires and shifts the bits of the UDInt (see next item bullet point).
• The SHL instruction models the conveyor by shifting bits of the UDInt via a one-shot conveyor trigger at either 10Hz (conveyor motor running at 100%) or 5Hz; (conveyor motor running at 50%).
• The conveyor exit is modeled by extracting bit 31 of the when the conveyor shift trigger fires but before the SHL executes.

The trace image below shows that the conveyor motor speed does not change the long-term bag fill rate (delivery rate of bits to the "conveyor" UDInt, bit 31).

Caveat: again, this assumes the washer rate and conveyor motor speed are independent. However, even if the are not, the long-term bag fill rate will still be controlled by the most-upstream independent feed rate to the process.

 

[drbitboy]

Still, continuing with the linear model:



If filling the bag to 100% of target weight takes 20-30s, then filling 16% of target weight takes 3-5s, and perhaps over that time the we can assume (model) that,

• the motor speed has been constant at 100%spd for 90%wt of the fill,
• and the strawberries per dm loading on the conveyor is evenly distributed,
• also that those evenly-loaded strawberries on the conveyor are enough to complete the fill from 90%wt to 100%wt

So if we model the fill from 74%wt to 90%wt, we know the times

• t74 when the fill was 74%wt
• t90 when the fill was 90%wt
• t100 = (2* t90 - t74), when the fill will be 100%wt
  • assuming we ramp the motor speed from 100%spd at t90 to 25%spd at t100

The model could start at the first measurement after 73%wt and end at the first measurement after 89%wt, using a free-running TON for time (.PT is large, say 100s), sampling TON.ET at each new weight measurement, w, and summing ET, .ET**2, .ET*w, and w. The model is evaluated once at the first measurement after 89%wt, and comprises the following formulae:

Sampled w, %wt past 90wt% = 100% * (measured weight, g / 10,000g) - 90%wt

Modeled w = m .ET + b

where

N = number of samples

m = (N * (Σ[.ET * w]) - (Σw) * (Σ.ET)) / (N * (Σ[.ET**2] - (Σ.ET)**2)

b = ((Σw) - m * (Σ.ET)) / N
​

The predicted time (.ET) for 90%wt fill will be t0 = (-b / m); the end .ET, tEND, will be tEND = ((16 - b) / m).

Leaving the TON running and sampling .ET, the speed during the ramp of the motor from 100%spd to 25%spd will be:

S, %spd = 100 - 75 * (.ET - t0) / (tEND - t0)
​

There will also be an in-flight (tail; spill) at the end, I would guess it would be proportional to m, that should set the weight, at the in-flight weight subtracted from 10000g, at which the motor should be shut off. That in-flight value (factor) will be found by experiment.

 

[Peter Nachtwey]

Still, continuing with the linear model:S, %spd = 100 - 75 * (.ET - t0) / (tEND - t0)

This is where you should go back and look at what I wrote. Your equation will not result in a linear ramp as shown in your gold area. What you have found out since my post is that the ending speed will not be zero. OK, the Vmax^2-Vmin^2 = 2*deceleration_rate*Weight_left_to_go). Re-arrange like I did in my post and you have the speed as a function of weight_left_to_go instead of time. My formula will approximate a linear ramp down from Vmax to Vmin.

 

[drbitboy]

Typo in previous post; missing paren provided here.


m = (N * (Σ[.ET * w]) - (Σw) * (Σ.ET)) / (N * (Σ[.ET**2]) - (Σ.ET)**2)

 

[drbitboy]

Your equation will not result in a linear ramp as shown in your gold area

Not sure that is correct; abscissa is time.

Of course there are problems in that the PLC is solving the differential equation with discrete samples instead of analog, so the measurement used is not concurrent with the change in speed, etc.


But to first order, and considering that the motor will be stopped at some in-flight/tail/spill delta before the target, I think it's about as good as it's going to get.

Also, as presented, my post with the least-squares fit to rate does not answer the OP: if fill rate is low at 100% motor speed, how to delay the ramp and/or decrease its magnitude.

 

[Peter Nachtwey]

Not sure that is correct; abscissa is time.

Yes, but I thought the OP wanted the motor speed as function of weight.
This way it will correct for when the material flow is not constant.
Your way assumes the weight increase linearly with the motor speed.

Of course there are problems in that the PLC is solving the differential equation with discrete samples instead of analog, so the measurement used is not concurrent with the change in speed, etc.

No differential equations are required. Only some high school physic math.

If Vmin should be 0 when the bag is full. For reason you have it at 25%.