Batch Correction with Discrete (on/off) valve

[AD-PLC]

Hi Everyone,
Thought I had it figured out but I came to the conclusion it would not work. Here is what I'm working with...

1. 1769-L30ER
2. Flow Meter with pulse output (100:1)
3. Batching process (Great info on this site that helped me build this!!!)(Though for a small program I did was fine I'm going to work on SFC or SQI SQO)

The goal is just mixing two ingredients. There is a preset that needs to be met. Accuracy is not that key.
I'm going to chase pulses. As the meter is counting pulses and gets to its desired goal it will shut the valve and do a batch correction because it will overshoot "X" gallons on first run. I wanted the PLC to correct this for every new batch being made.

At first I calculated the pulses, for example, 100 gallons was needed thus be 10000 pulses. (Math in background does this for V/V% of the calculated amounts per ingredient).
My calculation was (TargetPulses - TargetOS) = TargetConfirmed (target the valve should close ahead of time to meet the target required).

When stored pulse count reached target it will close the valve. The valve takes about 3 seconds to close. So I set a timer for 5 seconds.

PulseCount - TargetPulses for the overshoot. Then i moved that result to TargetOS. In my mind if it equalled ZERO as every batch it corrected itself. Example: 1000 pulses counted and it was 1000 pulses targeted. (1000 pulses - 1000 target = 0 overshoot). Overshoot moves to 0 thus restarting the whole cycle over and it will be off by a good amount after "x" amount of batches that passed.
Code:


Is there something I'm missing? I tried to look for batch controller code or examples but everyone uses a PID loop with control valve.

 

[drbitboy]

Is there any logic to the left of the rung in the second image? because if not, then that RTO be constantly reset on every scan cycle.

Also, I do not think the process has been adequately described yet.

 

[AD-PLC]

@drbitboy
It is a program used to batch two liquids together. It will be ingredient 1 and ingredient 2. They will be introduced at different areas of the sequence. After the user has selected their finished product batch amount wanted it will first batch over ingredient 1. After that is finished it will batch over ingredient 2. Then there is a tank mixer that will mix them for "x" amount of time. Its a simple process.

Yes, I do have code on the left. I did not know the RTO would reset on every scan if no code there. It is a first working with PLCs but I get the idea of a lot of the functions. Maybe the RTO went over my head. I was reading and my interpretation was it will retain it's value when true and would not reset without the RES command.
Also some background for below. When the batch to make is confirmed it will move a 1 into BatchSeq and this would start this ingredient one batching to the tank.
(I know this is not the best way to go about a sequence and I am learning the other ways next. I just read / watch recommendations that this is ok as long it is short and you know what your doing, I see how it can be messy)

 

[AD-PLC]

OH! I see what you meant now!!! Yes it would reset every scan! Don't worry I have the batchseq EQU before that line. My apologies.

 

[drbitboy]

Actually it will only reset the RTO when the .ACCumulator time reaches 3500ms or more, and the reset will reset the accumulator (so the ONS is not necessary).

Also, I don't think you want an RTO there; TON might be better. With an RTO if you abort an operation, the .ACCumulator time will not be reset.

Also, you do not need to compare the .ACCumulator time to e.g. 3500ms; you can set the timer .PREset to be 3500ms and use the .DN bit of the timer structure to detect when 3.5s have passed.

I think I see what you are doing now: you are counting flowmeter pulses for 3.5s after the start of the command to close the valve, and using that to estimate the "overshoot*" delivery of material that occurs during the process of closing the valve, and using that estimate to adjust how "early**" to start closing the valve on the next cycle to try to reach the target amount exactly once the valve is closed.

* also called "In-Flight"
** i.e. before the actual target number of flowmeter pulse counts

 

[parky]

Done many batching processes, one thing that really works is to put a butterfly valve in the line with say a 20mm hole in it ( I called it the trickle valve), the process is as follows.
The trickle valve is normally closed, open both the main & trickle valve, count the pulses, when quantity reaches setpoint minus x volume close the trickle valve this effectively gives you a slowdown so it is much closer to the required setpoint, I also used to capture the over/under dosing levels & add/subtract a portion of this to the required setpoint but within limits. you could also put a small bore valve in parallel with the main valve but in our case due to physical position could not fit it. The biggest problem was the water, when other equipment was using it the pressure changed so in-flight would be variable so this seemed to be the best solution.

 

[AD-PLC]

@drbitboy
First most, thank you for explanations. I'm also gauging how I should be responding with enough information. Excuse the ignorance. Extra information below...

1. I don't have the PLC or a prototype set up that is why I'm currently working in theory. Running the process in my head.
2. There is a cancel batch button I integrated that will reset the timer/s.
3. There is a pause feature integrated as well. If and when the system is in "PAUSE STATE" my intention was to keep the stored timing.
4. Your comment about using the DN bit. I see that now. That does make more sense to do.
5. Correct, I read (can't find the thread anymore) someone said that when you reach your desired pulses the valve will close but when it closes use an RTO to time how many pulses PAST your desired pulses and substract that from your pulses on the next batch. "in-flight" thank you for the terminology that is super helpful for my knowledge growing. It takes 3 seconds (based off OEM) to close. During those 3 seconds I'm "seeing" how many pulses accumulated during that time interval.
6. Based off point 4, trying to run the situation in my head and that's where it lead me to believe if I reached the EXACT pulses from what was desired the scenario would be: MATH ---> [Desired Pulses] - [TargetPulses] = [TargetOS] which would be zero. On nth batch I would overshoot again.
7. I think what I need to do is update a value than MOV the value calculated.
8. Example for 7, if the first batch run I calculated OS by 10gallons. That value is stored for the next batch. On the next run the OS is 1 Gal but I should substract a gallon worth in pulses so it is now 9gallons it closes beforehand. Then the next batch is 0 gallons OS which I add to the 9 gallons (in pulses) which should produce the same result. If it undershoots then keep the same logic so next batch gets me as close to the target pulses

 

[AD-PLC]

Done many batching processes, one thing that really works is to put a butterfly valve in the line with say a 20mm hole in it ( I called it the trickle valve), the process is as follows.
The trickle valve is normally closed, open both the main & trickle valve, count the pulses, when quantity reaches setpoint minus x volume close the trickle valve this effectively gives you a slowdown so it is much closer to the required setpoint, I also used to capture the over/under dosing levels & add/subtract a portion of this to the required setpoint but within limits. you could also put a small bore valve in parallel with the main valve but in our case due to physical position could not fit it. The biggest problem was the water, when other equipment was using it the pressure changed so in-flight would be variable so this seemed to be the best solution.

I like this idea. That make sense. So you introduce a two-stage shutdown valve. The trickle valve with the butterfly valve (to me) it thinking outside the box! My instinct would be to do the parallel version you mentioned.
Hmmm, just reading what you mentioned about the limits. Is this the route to go if accuracy was not a concern? If yes why choose this route instead of letting the PLC constantly update the correction factor?

 

[drbitboy]

You could make the In-Flight measurement with a counter that reset when the valve is open and starts counting pulses when the command to close the valve occurs, and keeps counting as long as another pulse is received within a short time period (say 500ms) using a TOF. When the TOF expires (500ms passed with valve commanded closed and no pulse - the pulse restarts the TOF), the number of pulses in the counter is the In-Flight measurement, and which then gets subtracted from the next target measurement to determine when to command the valve closed.

 

[parky]

Originally, we only had the over/under dosing correction but the biggest problem was if it under dosed then the next setpoint was increased, however, if the pressure rose due to very few other vessels using supply then it would overdose so that was the reason for the trickle valve, I left the correction factor in but reduced the amount it would correct by.

 

[AD-PLC]

You could make the In-Flight measurement with a counter that reset when the valve is open and starts counting pulses when the command to close the valve occurs, and keeps counting as long as another pulse is received within a short time period (say 500ms) using a TOF. When the TOF expires (500ms passed with valve commanded closed and no pulse - the pulse restarts the TOF), the number of pulses in the counter is the In-Flight measurement, and which then gets subtracted from the next target measurement to determine when to command the valve closed.

This makes sense. I do have a high speed counter card. Would a counter not be the way to go since there might be issues where the pulses would not catch?

 

[parky]

Usually valves do not vary much in closing/opening times (unless your supply air or other control action is varying or the valve is not upto it), so it's probably down to dosing supply varying if you go Brian's method, keep the max deviation you can add/subtract from the target or it could run away by quite a bit.

 

[AD-PLC]

Usually valves do not vary much in closing/opening times (unless your supply air or other control action is varying or the valve is not upto it), so it's probably down to dosing supply varying if you go Brian's method, keep the max deviation you can add/subtract from the target or it could run away by quite a bit.

Yeah, the process valve is electric. It does come down to the dosing supply as you mentioned. I was trying to mimic a batch controller. The max deviation does make sense. I'm not shooting for accuracy. But if I could get it where it is "self learning" the accuracy is just icing.
I had no luck finding code examples of a batch controller or seeing it in computer code where maybe I could get some ideas

 

[parky]

But if the dosing supply varies you could end up even worse, for example assume it overdosed by 20 counts so you could sub say 10 to the setpoint, but if the supply then slowed it could conceivably underdose by let's say 30 or vice versa if your in-light range adjustment was too high this would accumulate even more & could be even worse this is what I found that was the reason for the trickle feed, it reduced the errors that could possibly occur. Generally batch controllers are either just high speed counters or they control the flow with a PID loop so the flow is constant then they have a built in adjustable in-flight. PID controlled valves are the only real way of controlling a varying flow, however, I found that drilling a hole in an additional valve worked a treat, even though the pressure changes expotentially with the smaller apperture, the total flow rate bottoms out so becomes easier to control plus as it can only dose at a lower rate it is more likely to give better results.

 

[drbitboy]

I think your method might be better i.e subtract final total count from valve-off counts to get the offset to use.

The attached PDF has my method (count pulses after valve off until stop to estimate in-flight); I had to add a fudge factor of 1 count when using that estimate. Also, this seems way to complex.

LAD 3 models a flowmeter pulse for a (C_v)-fast-opening valve that takes about 4s (4k scan cycles) to go between full open to full closed in either direction.