Vibrator Speed Control using Load Cell weight

[parky]

DR I think you may confuse him with one ninth.
It's simple, you have a flow rate of 12,500 per hour & 80 or 90 % large (no need to enter the rest as the total is always 100%) i.e. 100% = 12,500 lb/hr
So the operator enters the large peanut percent i.e. 90 the PLC does the maths
90% of 12,500 is 11,250 so that is the set point for large peanuts.
Sub the 11,250 from the total = 1,250 so that is the small peanuts.
There is no need for the operator to enter the small peanut as it could be automatically displayed as 100 - large peanut percent = small peanut percent just for display purposes.
On the operator display for the settings:
Production Rate: [12,500] lb/hr Operator entry
Actual production Rate: [12,467] lb/hr
Large Peanut %: [90%] Operator Entry Large: [11,224] lb/hr
Small Peanut %: [10%] Automatically calculated Small:[1276] lb/hr

Ignore the sums do not add up perfectly, just could not be A$$$D to calculate it, but you get the idea.

 

[drbitboy]

The one-ninth cannot be avoided, and I disagree that it is at all confusing, because it represents the most direct solution.

It's simple, you have a flow rate of 12,500 per hour...

@parky, this is where the wheels come off your approach: OP does not know the total flow rate:

I am planning on keeping the feeder that is running at the higher percent constant.

... I run the larger peanuts at max speed 60 hz and always keep that constant. I can calculate my [large] flow after running for a minute by taking my weight loss. Once I get my [large] flow of one vibrator running at 60 hz ...

Also, OP wants to set the rate of small as a percentage of total flow, not as a percentage of large rate:

I have two bags of two different types of peanuts hanging on a load cell above two separate feeders. I am using Studio 5000 and would like to add a speed control to each feeder so I can run one at 10 percent or 20 percent, and run the other at 90 percent or 80 percent.

OP does not knows the total rate a priori, they only set the large peanut vibrator speed input (no PID) and measure the resulting large peanut flow. The one-ninth (or small% / [100% - small%]) of the measured large peanut flow is the most direct way to the setpoint of the small peanuts' PID.

Whether the reference rate is the total flow rate or the large flow rate is neither here not there, because the math based on the same set of equations, solving for Fsmall, the small peanuts' PID setpoint:

(eqn 1) Fsmall = small% * Ftotal ==> specification
(eqn 2) Flarge = large% * Ftotal ==> specification
(eqn 3) 100% = large% + small% ==> conservation of mass
​

With only small% (spec) and Flarge (measured) as knowns, solving for the unknown Ftotal takes two steps:

(eqn 3.1) large% = 100% - small%
(eqn 2.1) Ftotal = Flarge / large%
​

Then applying eqn 1 solves for Fsmall, the PID setpoint.

However, substituting (eqn 3.1) into (eqn 2.1):

(eqn 2.1.1) Ftotal = Flarge / (100% - small%)
​

then that into (eqn 1):

(eqn 1.1) Fsmall = small% * Flarge /(100% - small%)
OR
(eqn 1.1) Fsmall = Flarge * (small% / (100% - small%))
​

So if small% is 10%, then (small% / (100% - small%)) = (10% / (100% - 10%)) = (10/90) = one-ninth, i.e. of the a priori known, Flarge.

An alternative path to the same result, which is more direct and eliminates the unknown and unnecssary Ftotal out of the box, starts by dividing (eqn 1) by (eqn 2):

(eqn 4) Fsmall / Flarge = (small% * Ftotal) / (large% * Ftotal) = small% / large%
​

Rearranging, then substituting (eqn 3.1) for large%:

(eqn 4.1) Fsmall = Flarge * (small% / large%)
(eqn 4.1.1) Fsmall = Flarge * (small% / (100% - large%))
​

which is the same as the (eqn 1.1) above, and the formula I provided twenty-some posts ago.

If both of those paths are confusing to OP, then they have no business working this problem.

 

[parky]

The wheels do not come off, he does not know the actual flow rate but that is the set flow rate, the rates are based on the set point of 12,500, but the actual flow of the small peanuts are calculated from the actual flow of the large peanuts so regardless of the large rate the small rate follows suit.
For the first few moments the actual flow will not be known until the loss in weight is measured (probably a second or two), I have done this on an in-line mixing system in 2000, as far as I'm aware it is still running.
It was a meat slurry & sauce, I do like the non scientific way they actually check the mix, they take a known sample size & count the small cubes of meat in it. so I know my way of doing it works. On initial start, both products are forced to a manual set point (based on trials) this gets the product within a small tolerance, from that it starts to do the calculations using bump less transfer to the PID. Trials indicated that it was well within 1.5% of expected tolerance required. As the meat was also in a slurry (or it would not move as such) the meat content was calculated based on an offset to allow for the slurry which is not part of the ratio of meat slurry to sauce but became a part of the sauce.

 

[drbitboy]

The wheels do not come off, he does not know the actual flow rate but that is the set flow rate, the rates are based on the set point of 12,500,

There is no setpoint of 12,500 in the process the OP describes; they are "trying to run at about 12,500lb/h" yes, but that is not a setpoint. The only relevant known starting values are the large peanuts' rate (measured, not a setpoint), and the Fsmall/Ftotal percentage.

 

[parky]

Regardless of whether they set the set point or use a fixed value it is just a flow rate they want so a total of 12,500 of both at a ratio of 90/10 or what ever they want. This equates to 11,125 for large & 1,250 for small Maybe OP will fix the value will depend on what the production targets are this is just a flexible way for example he may need to set his inverter at 45hz to get the production rate but he needs to know what the flow is. I have just spoke to an engineer at the plant I put in 21 years ago, he has just sent me a sample of one of the reports on that system, he has removed some of the details & only posted the graph, this is just a part of it, yes it still is working

 

[drbitboy]

...at a ratio of 90/10...

\


There's my one-ninth, expressed as its reciprocal; QED.



I was not saying any of your math was wrong, just that it was starting from a place other than the OP was starting.

 

[parky]

Perhaps the US need to start using universal measures like kg & litres lol,
We were dragged into the 20th century in the 70's kicking & screaming well almost, mechanical engineers still use imperial on pipework, seems very odd years ago we complained about decimalisation now we moan about inches & feet, BSP.

 

[drbitboy]

...

(eqn 4.1) Fsmall = Flarge * (small% / large%)
(eqn 4.1.1) Fsmall = Flarge * (small% / (100% - small%))
​

Fixed a typo; the magenta small above was mistakenly typed as large in the previous post.


Thanks to @MikeyN!

 

[drbitboy]

Perhaps the US need to start using universal measures like kg & litres lol,
We were dragged into the 20th century in the 70's kicking & screaming well almost, mechanical engineers still use imperial on pipework, seems very odd years ago we complained about decimalisation now we moan about inches & feet, BSP.

I know you are just trolling and spinning me up, but you and I are at sixes and sevens today, good buddy.

Yes, the US should change over to make it easier to operate in a global environment, but there will be a short-term cost that our capitalistic system is unwilling to pay, and certainly others' misguided opinions are no incentive to make the US pay itself.

Show me a preponderance of proportionality constants that are a power of 10 (i.e. other than the density of water at 39.2°F ), and there would be an argument to be made. E.g. if the speed of light were actually 3.0000D+05km/s, but it's a 2 followed by a couple of 9s, then some other digits.

But from a functional standpoint, units are irrelevant; I use whatever my customer wants, without bias. But SI/metric offers almost nothing useful over any other system. I don't mind it any more, or less, than other systems, because like I said it is irrelevant; but I it is amusing to see the baseless religious fervor of its proponents.

From XKCD.com/927:

 

[parky]

Yeah, I'm winding you up lol.
We still have the same problem, although food is sold in grams or multiples of they still display it in ounces or lbs, we still use miles, acres so we have never truly converted.
I'm just waiting for those overpaid idiots in those think tanks to add another universal measure to harmonise weights & measures.
It's the ancient Egyptians Babylonians & Julius Cesar who made a mess of it based on astronomical events & Roman leaders, they all got it a bit wrong.
I agree that the units are irrelevant, but it can often cause problems, in the 80's, the Japanese flooded the UK market with calculators, the problem was the Asian gallon was smaller than the UK gallon so it was 3.8 litres but imperial gallon is 4.55 (roughly), kids at school were allowed to use calculators in their studies & it was found that many students were getting it wrong. thankfully, schoolchildren today do not know much about the old weights & measures, although it does crop up now & again. My step daughter a few years ago was given some previous year exam papers by the school as preps for her up & coming exams, She was stuck on a question about distance for yards, furlongs miles and a few other length measurements can't remember the whole question but it was there are x yards in a chain, x chains in a furlong etc. etc. so how many yards in a mile, I told her if there are 22 yards in a chain, 10 chains in a furlong & 8 furlongs in a mile just multiply them. the answer was 1,760 yards which I know is correct, the teacher marked it wrong ? what, it turned out even they did not know how many yards there are in a mile, my guess is the teacher did not know what furlongs, chains etc. were just like my step daughter, what a dressing down I gave them.

 

[drbitboy]

I have always wondered about this:

A pint's a pound,
the world around

while an imperial gallon is 10 pounds (16oz weight) of water at 62°F, and an imperial pint is 1/8 of an imperial gallon (20oz weight of water). Is the quote above based on a liquid other than water?

 

[parky]

No idea, but probably, an imperial gallon is a standard that used to be used by customs & excise the gallon container they used was volume of one gallon in fuel nothing to do with weight, I do remember C&E doing tests in petrol stations the vessel was copper, inspected for dents and filled to a rolled lip.

The three sizes of measurements are significantly different with an imperial gallon defined as 4.546 litres, US gallon as 3.785 litres, while US dry gallon is defined as 4.405 litres.

A gallon of water weighs about 8.3 pounds. The imperial gallon of water is defined as 10.02 pounds at its maximum density while the weight of US dry gallon of water is defined as 9.71 pounds. However, the answer comes with a caveat. The weight per gallon of water fluctuates with temperature.
I always wondered what a dry gallon of water is, then I learnt that a dry gallon has nothing to do with water it was a measure of corn in British history ?

 

[drbitboy]

US gallon used to be 231in**3 exactly, although I forget which inch was used. With the introduction of the international yard (and inch) ca. 1950/1960s, it's off from exact starting several decimal places out.

 

[parky]

Yes I prefer to use mm when measuring, but for some reason they still put inches as well as mm on steel ruler tapes so I tend to forget & use mm & use feet & inches instead.
Getting back to the original post, I did assume that as both inverters were driven by a 4-20ma signal that they would set the flow rate via a set point on the HMI, that was my reason for using the flow rate setting rather than being fixed.

 

[drbitboy]

Getting back to the original post, I did assume that as both inverters were driven by a 4-20ma signal that they would set the flow rate via a set point on the HMI, that was my reason for using the flow rate setting rather than being fixed.

Ah.