Hi

Has anybody any experience with developing or utilising an algorithm for calculating a flow-rate (kg/hr) of powder, based upon Loss-in-Weight from a set of Load Cells.

The Flow-rate would be used as PV for a PID Loop within a PLC5, whose SP would be a manually entered value in kg/hr and the OP would be a 4-20mA output to an Inverter drive Rotary Valve.

Clearly it doesn't really matter what sort of PLC the algortim has been developed for, although in this case it is for an AB PLC5. As a result my initial thoughts were to utilised an STI program file and collect samples of weight every x msecs, its the integration part that i'm not sure about.

PT

flowrate should be simply difference in weight during period of time.
if you periodically sample weight value and calculate difference with the
last sample, that's all it is.
any integration would be part of the PID loop (that's "i" in PID).

Yeah, but its more than that.

Clearly integration is within the loop control, however, it's the sampling algoritm that i'm interested in.

Surely you cannot just measure the loss in weight, say every 10 or 50 msec, and therefore detemine the actual feedrate based upon this weight loss. There are going to be errors, and multiplying up from kg/sec into kg/hr these errors are going to be amplified.
Surely there must be some more complex sort of sampling and averaging that needs to take place.

I've done something similar for loss in level to determine flow rate.
What I did was:
1. Take a sample every second, and determine the difference from the last sample.
2. Store this value, in an indexed array. I saved sixty samples.
3. Average the sixty samples, this helps minimize noise, bad readings etc...,
this will give the average rate per second over the last minute.
4. Multiply the average rate per second X 3600, which will give you the rate per hour.
5. This rate per hour can then be used as the PV in your PID.

A lot depends on the response of your system. I have found that the longer time between samples gives the smoothest system. But, if it is a system with rapid rate changes, the longer the sample time the greater the response lag.

Once you have the logic in place, you can play around with the timer value to "fine tune" the system, use an N7 register as the multiplier, in my expample above the 3600 would have been in N7:0, then you can easily change the value while the logic is running. The N7 value will be one hour divided by the timer preset.

I have used this in some systems that had very slow response times, and used 10 second sampling, never had very much luck with sample times less than one second.


Ken

Thanks Ken

That's kind off where i'd got to. Only it only takes about 60 seconds to complete empty my hopper.

I figured smaller sample times (in msecs) but i am not particularly happy that i would scaling up relatively small samples, and thus magnifying an errors.

If it only takes 60 seconds to empty the hopper, then why do you want your PV in units per hour? Shouldn't you be using units per second instead?

You could take your rate per hour set point and derive the rate per second from that. Since your setpoint is exact, there would be no error multiplication.
Then do your controlling at the rate per second level and you remove a lot of the error magnificaton.

Doesn't make sense to me.

I'm sorry, but i am at a lost as to how it is scaling up errors......
Why because the flow rate calculated would be correct for the previous sampling period. ie if the flow rate was constant at this rate then the scaling up would be correct.

However since it is a powder and you obviously are getting a variation in flow rate then if you want a stabalised result then you will need to average out the sample data as Ken suggested. I do the same with water flow rate calcs also.

One other thing to rember is check the sampling rate of the actual AD card also if you decide to take samples less the 1 sec. I am not sure of the AB specs.

Here's a clip from the 1771-IFE manual:

my $0.02:

I would set the IFE for real-time sampling and use the block xfer 'done' bit to initiate the averageing and scaling function. This way, you know that the readings have been taken at regular intervals and you know that each time you process a reading, it is, in fact, a new reading.

Depending on how you set the STI, there's the possibility of processing a single reading twice (or more) or of missing readings between STI executions. The net effect is an erratic time-base for your calc's which presume a constant time-base.

As long as the real-time sampling period of the IFE is greater than two program scans, you should be fine.

Why don't you use simple devices such as Dayton (or others) that already
has PID loop and integrate it into your design. Using PLC PID can be very headache.