Recommendation - AB PLC for can filling with 4-20ma level probes.

Hi,

I am just exploring the options to replace an outdated filling valve controller for a can filler. It has 78 filling valves and runs at max speed of 300 CPM. Filling mostly 375ml cans by switching 8 solenoid valves based on a 4-20mA level float sensor. The filling happens roughly through 25% of the rotation window. So I have estimated about 4 seconds to fill the can and we have about 10.4 milliseconds per ml.

There is 78 level probes and 624 digital outputs. This has to be an Allen Bradley PLC to control this (site standard). What hardware would you guys suggest I look at?

I was looking at the using control logix and the 1756-IF16 in high speed mode (4 Channel) but it has to be on the local rack and that's about 20 cards just for the level probes. Then another 20 x 32bit output cards for the solenoids. Is there a better way to manage this sort of application?

Thanks,

For that amount of IO I would recommend EtherNet/IP, so you would not need a big rack.

What accuracy do you need to achieve?

How does the current filler control the fill valves?

Are you filling with a single fluid or multiple fluids? The numbers of valves you list is a bit confusing. Do you have a diagram or picture of the process?

Be careful on this one!

Everything controlled through PLC logic will have a minimum of a 1-scan timing discrepancy. If the scan is 10 milliseconds you will have 10 milliseconds of variation in anything that the processor does. Probably not a big deal by itself but you have to factor in other discrepancies - analog input times, I/O communication times, instrument update times, and so on. There is a reason why high speed counter cards have outputs - because some things in this world cannot be done through a CPU!

You may choose to dismiss this concern as coming from a 65 year old guy who started out dealing with 30 millisecond scan times on a Z-80 based Symax model 300 CPU. I'll grant that I'm behind the times and todays stuff is a lot faster - but you must grant me that the communications layers and other factors have made it much more complicated to figure out these timings.

And if I may be so rude as to mention the obvious - all the control stuff has to be DC. No AC.

The PLC class outline at corsairhmi.com talks about the 2/5/10 rule. 2 times is barely adequate, 5 times is good, and 10 times is ideal. The rule applies to instrument accuracy, timings, and all sorts of things. It means that if you have to fill to an accuracy of ## milliliters and that translates to a skew of 20 milliseconds then your total skew (instruments, PLC, and anything else) needs to be no more than 10 milliseconds. It's good to have it at 4 milliseconds and ideally at 2. We usually can't get the ideal.

These issues need to be examined and quantified before there is any discussion of PLC hardware. I don't mean to offend - but figure them out first!!

Dave, I find your post very enlightening. Thanks very much for taking the time to write this. I am sure many others will too. There are many mote things to consider in addition to the size of the local rack for the PLC, so my post was way too simple, I fully agree.

Alfredo, your post and my post were both just a start to approaching the problem. I'm learning to appreciate the value of a forum like this and how it brings many perspectives.

IF IF IF there is a speed issue on this one (there probably isn't) there are ways to approach it that remove control system speeds from shutting off the fill valves. We can discuss later if needed.

I'm guessing that the level measurement devices are in use with the existing system so it is known that they are fast enough for the accuracy that it has been getting. As long as the PLC is as fast or faster than the existing hardware it's full speed ahead to finding a workable I/O configuration as you've suggested.

I tend to be the worrying old man that sometimes overthinks things and needs to shut up but occasionally I've stopped a trainwreck before it happens. I must admit I've also caused a few trainwrecks.

Wild late-night speculation

Does this thing really need 78 PLC analog inputs? Or does it need 8 PLC analog outputs feeding into 8 hardware comparators? The discrete I/O switches the sensor analog signals into the comparators. The comparator outputs feed both into the solenoids and into discrete inputs.

This might make the can-full solenoid-close signal independent of PLC scan time for maximum accuracy.

The discrete I/O requirement may not be any more than what is already being considered. Ndzied is right - need more info.

Probably want the level probes to be 0-10 volts instead of 4-20 milliamps for this option. I suspect the cable lengths are short so that is not a problem.

Corsair said:

I tend to be the worrying old man that sometimes overthinks things and needs to shut up but occasionally I've stopped a trainwreck before it happens. I must admit I've also caused a few trainwrecks.

Click to expand...

You are right of course. There is not much more embarrassing than putting a system together and realising on site that it is not able to meet requirements. Take the half day to do some basic ballpark calculations.

10ms/mL, is that when all 8 valves are open? Presumably it slows down as it reaches full and you close some of the valves. But it could be each valve delivers a different ingredient. How many mL can you under/overflow by? You will then arrive at a maximum delay from analog reading through PLC scan to valve closing.

In fact, you could even do the reverse, quote for several different IO systems, tell the customer what accuracy they can expect for each price point, and let them decide.

General Statement

Sometimes you have to figure out a hardware configuration that is not dependent on scan and communications because you're out of luck before you start with speed and resolution issues on the instrumentation.

In lots of situations the key to the thinking is that one side (in this case turn-on of the solenoids) is not time critical and it can stand being skewed by processor delays. The other side (turn-off of the solenoids) may not be able to stand the variation.

When I reexamine the OP it looks like to me that maybe there can be as many as 8 ingredients going into the can. As usual, well-meaning advisors on this website (including me) are doing too much speculation based upon too little information. Such is life.

Hi everyone.

Some answers to your questions.

- Yes the 4-20ma probes are existing and known to work.

- The 8 solenoid valves are for various things but only 1 is for the ingredient. There is CO2 rinsing and sniffing etc and the others I would have to check the documentation but there is 1 main ingredient fill valve.

- I need to confirm the maximum acceptable error in volume. But the target would be say 375ml and as close to that as possible.

- Now I am currently looking at the compact logix 5069 series and the IF8 cards for the analog inputs.

- Its a rotary filler that lifts cans onto the carousel and then at a certain angle will start the filling procedure.

Thanks,

I would look at WAGO or Beckhoff for that amount of 4-20mA inputs. Cost on Allen Bradley or Siemens would be quite high due to cost of I/O

Hi mad4x4 yeah the customer has a site standard and has specifically specified AB.

Looking at document 5069-TD001, the update rate is a bit hard to interpret. It looks to me, a fully loaded 5069-IF8 has a max update rate of 10ms. So your program may take 20ms to 'see' the set level being reached.* I imagine then the outputs would take a negligible amount of variance to deactivate. Maybe you could do some predictions around "I am 0.5mL away from setpoint, I should deactivate the output in 5ms".


The code for that predicition gets complicated.


If you could find a controller and I/O combination, which offers faster update rate, for example Beckhoff PLC with EL3024 terminals, which can have a 500us update rate with the controller, You could reduce the variance caused by that 20ms delay (2mL) down to 0.1mL. Sure there will be other variances throughout the system, but it depends what 2mL per can is worth to the client.


* The input sampling is multiplexed, so the 1st input would be held at 0ms after reporting, and then sampled for 625us. The next reporting happens 10ms later. If the correct fill level occured just after the hold, it will take 10ms before it is sampled again, and then another 10ms before that is reported.


I did not find a faster combination of IO with Rockwell. Even the 1756-IF16 high speed mode is 5ms.

Delay vs Skew - more old man worrying

It's correct to be thinking about analog input speed in this case but remember that it's only one part of the equation. The speed of the sensor needs to be figured, probably even before you examine the analog ins.

The thing that we have to keep in mind is that a fixed delay is different than a time skew. A fixed delay can be compensated for by shutting the valve off ahead of time. This 'compensation amount' allows for some product to be in the tube downstream from the solenoid. Keeping the solenoid close to the end of the pipe reduces the amount of compensation. Compensation can vary with things like supply pressure, fluid viscosity (temperature), and so on. There will be some compensation in this system. Usually an experimentally-determined fixed compensation will work.

The other issue is time skew. A skew is a range of system response time variations encountered with different scans. It's a combination of PLC scan time, I/O system update times, and other factors.

If you have a 10 millisecond scan time with a 20 millisecond requested packet interval on the I/O one can may someday have a can with the perfect situation. The analog level could hit right before the comms sends it to the processor. The processor does the scan and the comms sends the signal back to the discrete output immediately after the scan is done. In this rare situation you may get from analog to valve is 20 milliseconds.

The very next can has the analog level hit right after the comms happens. It takes 20 milliseconds for the next comms update to get the full level to the CPU. It hits the cpu at the worse possible time with respect to the scan cycle. If the worse possible timing then happens with the comms back to the valve you may end up with 50 milliseconds analog to valve for filling that can.

This 20-50 millisecond range represents a 30-millisecond skew that you cannot allow for with a fixed compensation. If the sensing instrument accuracy, sensing instrument lag time, and the skew is greater than the customers required filling accuracy the system will not work and no amount of clever programming can fix it.

PLC analog cards are typically not meant to be the fastest available technology. Part of this is for cost and part of it may be filtering for stability. Faster analog hardware located in the same backplane as the CPU is a good thing. If that can't get you where you need to go my wild idea about using a hardware comparator may not be totally nuts. It would have some other headaches but it may eliminate analog input points.

This long-winded lecture may be pointless if you continue to research how fast your sensor works and the customers required accuracy. Don't let old guys like me scare you about how to do the system. We respect people that do their homework. And we roll our eyes and mutter to ourselves when people don't.

Corsair said:

It's correct to be thinking about analog input speed in this case but remember that it's only one part of the equation.

Click to expand...

Nice summary. Here is a related topic from the realm of statistical process control: https://www.isixsigma.com/dictionary/common-cause-variation/; for me, the best part is this:All that to say the same thing as @Corsair: the physical process has a capability; once all special cause variation has been removed, the common cause variation defines what the process can do, and any further improvement will require a process change.

In this thread, the scan time of the PLC and its input modules, as described by @Corsair, are part of common cause variation. If the time when the PLC detects that a certain fill has been reached can vary ±15ms (i.e. over a 30ms range) at 1ml/10ms, then the way to ensure there are a minimum of e.g. 375ml in every bottle is to target 1.5ml overfill (15ms * 1ml/10ms), and the mean fill will be 376.5ml. This is the way almost all industrial process work e.g. years ago Exxon had the "worst" gas because they had the best control and could run closer to the minimum octane rating spec; all other companies had to "give away" octane rating because their common variation was larger.

To improve the process (reduce common variation) requires a change to the process; as an example, which may not be possible here, reducing the fill rate i.e. that ml/10ms slope, perhaps near the end of the fill, would lessen the effect of the variation in PLC and analog input module timing.