Is it possible to program this onto a Click PLC? If so, I need help anyway.

drbitboy said:

I can think of at least one good reason why @OkiePC did that in the PLC program instead of in the I/O menu: experience.

At some point there will be a calibration, or perhaps repeated calibrations over the life of the system. Or perhaps the characteristics of the pump and/or I-toi-P regulator will change over time.

By having HMI-accessible constants available to, and performing the calculations in, the PLC program, it enables creation of a calibration screen* in the HMI. So if any characteristics of the process change (e.g. degradation over time, or a replacement pump or I-to-P transducer), the program can be updated for the new conditions.

* probably write-protected from operators but available to the engineer,

Click to expand...

+1


It's REALLY annoying to come across code that uses "magic math" (a random scaling factor where the input is multiplied by 5.24838 with zero explanation! After encountering that a few times too many, I started doing all of the calculations in the PLC with the gear ratios, sprocket sizes, etc. all as tags in the PLC. Not all are presented on the HMI, but they're all explained and easy to edit later when maintenance changes a timing pulley with the wrong size that they happened to have laying around.

I changed the scaling of the PLC input for a couple of reasons. Using milliamps instead of percent and turning off the clamping allows for the raw signal to be displayed in the HMI in milliamps and allows the PLC to detect a signal that is out of range (bad sensor or wiring).

Then to get to engineering units (psi) from a 4 to 20mA signal you just subtract 4, divide by 16 and multiply by the sensor range which I also like to make an HMI setpoint. Months or years later after this system is running, the sensor will fail and you'll only have a 3000 psi sensor on hand. You swap the sensor, go to the HMI and change the sensor range...or get out the laptop and plug in and edit it with Click software.

I put the filter math in there, because I have found that to be so useful for most analog signals, that it is easier to do up front rather than after you find out you need it. I also copied that rung from one of my other click programs, so the effort was minimal. I inserted a rung that stuffs a 1 in the filter constant if it is equal to zero which effectively defeats the filtering.

I update the results on a 100ms rising edge which is usually plenty fast enough, but it might be possible your pressure changes faster than that. I have not looked up the response delay of that analog input but it might be faster than 100ms.

So if it seems the PLC is late detecting rapid pressure changes, you can take out that 100ms rising edge instruction and ensure the filter constant is 1.0.

I am sure there will be mistakes in my code and maybe in the HMI, so please go through them both with a fine toothed comb.

There are also things you'll want to add too.

Yeah, my bad I did mean 0 to what ever the scaled value not the raw, so if it is in psi & the max is 250 then the compare should be <250.0 just not thinking well at the moment, 35 Deg C here even at 8:00pm at night.

OkiePC said:

I changed the scaling of the PLC input for a couple of reasons. Using milliamps instead of percent and turning off the clamping allows for the raw signal to be displayed in the HMI in milliamps and allows the PLC to detect a signal that is out of range (bad sensor or wiring).

Then to get to engineering units (psi) from a 4 to 20mA signal you just subtract 4, divide by 16 and multiply by the sensor range which I also like to make an HMI setpoint. Months or years later after this system is running, the sensor will fail and you'll only have a 3000 psi sensor on hand. You swap the sensor, go to the HMI and change the sensor range...or get out the laptop and plug in and edit it with Click software.

I put the filter math in there, because I have found that to be so useful for most analog signals, that it is easier to do up front rather than after you find out you need it. I also copied that rung from one of my other click programs, so the effort was minimal. I inserted a rung that stuffs a 1 in the filter constant if it is equal to zero which effectively defeats the filtering.

I update the results on a 100ms rising edge which is usually plenty fast enough, but it might be possible your pressure changes faster than that. I have not looked up the response delay of that analog input but it might be faster than 100ms.

So if it seems the PLC is late detecting rapid pressure changes, you can take out that 100ms rising edge instruction and ensure the filter constant is 1.0.

I am sure there will be mistakes in my code and maybe in the HMI, so please go through them both with a fine toothed comb.

There are also things you'll want to add too.

Click to expand...

For rungs 3 and 4 on the test pressure, and pre test pressure subroutine I am not understanding why you are using these here. Why is there different pressure% for the ip transducer pre test and during the test. Is this part of the program where pumping to pressure begins? If that's not added in, then I will try to add it in. I am just not sure where in the program the actual pumping to pressure begins with the transducer.

OkiePC's code is fine however, for such a small project & for a starter it is far too complex.
I think most of us would do most programs this way i.e. split it up but I think this is just overwhelming the OP.
First scan just use the first scan bit & set or rest what you need, 4-20ma on the screen no good for the operator, he will probably want to see a number thar reflects what he sets it to on the manusal air set.
Alarms only probably 3 or 4, probably do not need an alarm page just overlay them at the top of the screen & use visibility, I too like the idea of not even scaling the raw at all on the analogs just leave it at 0-32767 or what ever it is then do the scaling in the PLC & have these on the engineering page. i.e. min raw in, max raw in, min scaled, max scaled.
I suggest keep it simple, then when it works look at building a structured project by using other programs/subroutines etc.
What I do reccomend is if this system is to be tested off line then as there is no simulator for the click model & HMI then use the hardware, put temporary DF's in the analogs, create one other program (Subroutine) to simulate the values increasing & decreasing, run it, simple delete the sim routine, put the correct DF registers back in on the Analog I/O & that is it.
The OP's comment about incrementing the pressure to the pump is valid (I think) but only in the respect is that is how it is currently controlled to stop it going over pressure, in reality the operator does this because if turned up too high or too fast then either it over pressurises or a sudden increase of pressure could cause some sort of shock to the part being tested resulting in failure if not in testing but in future.
So perhaps increase the pressure over time but this may increase the test time (as far as the company is concerned time is money), find out exactlywhat the operator does & why is the first step (it could be because "thats the way I have always done it")Technically, it could be a matter of having a starft point perhaps 50 psi, then incrementing it every x seconds by y amount. We can only speculate on that one.
When I replaced the controls on our vacuum test rigs, I watched how the existing system seemed to control it, turned out it was as simple as about 80% full vacuum with a sudden stop at 2% before setpoint. I had Q&A to verify the process was correct using their test packs. The reason for replacing the existing controls was they were bespoke to the OEM & failed frequently & were costly for us to have them repaired.

Aljubovic said:

For rungs 3 and 4 on the test pressure, and pre test pressure subroutine I am not understanding why you are using these here. Why is there different pressure% for the ip transducer pre test and during the test. Is this part of the program where pumping to pressure begins? If that's not added in, then I will try to add it in. I am just not sure where in the program the actual pumping to pressure begins with the transducer.

Click to expand...

I was looking at your program which had a pre-test pressure to build up pressure to a lower setpoint before running the full pressure test and made a separate state for that. During that step, the I/P transducer is activated and given a command that is determined by multiplying the Pre-Test Scale factor (DF10) by the Pressure Setpoint minus the Inflight or Pre Test Offset pressure.

So you set the test pressure setpoint and then set the Pre-Test Offset to a value that represents in psi how close you need to be to the full test pressure before that step begins.

So say your test is 500 psi, and the pre-test offset is 100 psi. The pre-test pressure command attempts to hit 400 psi before the test pressure step begins.

I think the idea is that the pre-test offset might not change that often for different test pressures. Once this is all working, for different test pressures, the Test Pressure setpoint should ideally be the only value that will need to change.

The other important settings will be the scale factors which might end up being the same for pre-test and test pressure. You may find out after getting this debugged and running, that you can eliminate one of them, but I left separate scale factors just in case they do need to be different.

There's nothing in the program that calculates those scale factors. Those values are going to need to be adjusted or calculated and entered at least once by the engineer or skilled operator.

I still don't understand the system function of the I/P transducer and I have asked before. Does it act as a pressure command directly controlling the vessel pressure or does it act as a pressure adder, constantly increasing the pressure at a rate proportional to its command?

In either case the program should work, but if the latter is true, then the Test Scale Factor HMI entry probably needs to be much lower than the Pre-Test Scale Factor.

parky said:

OkiePC's code is fine however, for such a small project & for a starter it is far too complex.
I think most of us would do most programs this way i.e. split it up but I think this is just overwhelming the OP.
First scan just use the first scan bit & set or rest what you need, 4-20ma on the screen no good for the operator, he will probably want to see a number thar reflects what he sets it to on the manusal air set.

Click to expand...

I agree, but I also want to show a structure that some of use in real world applications. The first scan routine in this case only does one thing which could be cut from that file and inserted with the first scan bit into the States program.

I did intend to display the I/P command on the main screen and forgot. Good catch.

While fixing that omission, I found two glaring errors in my program. I was writing to the wrong analog output and I was unconditionally zeroing it. v002 fixes those mistakes and adds the command pressure to the main screen scaled in %. It might be better scaled in psi if you know the scaling of that command in psi, it should be easy enough to fix.

Alarms only probably 3 or 4, probably do not need an alarm page just overlay them at the top of the screen & use visibility, I too like the idea of not even scaling the raw at all on the analogs just leave it at 0-32767 or what ever it is then do the scaling in the PLC & have these on the engineering page. i.e. min raw in, max raw in, min scaled, max scaled.
I suggest keep it simple, then when it works look at building a structured project by using other programs/subroutines etc.

Click to expand...

The click requires you set up fixed scaling at the card using floating point numbers. The default is percent, which is fine, but less useful for real life calibration. There are no raw counts, although you could degrade it to that by plugging in arbitrary numbers. I chose milliamps over percent at the card level because those are not writable at runtime and then the rest of the scaling starts from milliamps rather than percent and does like you say above.

What I do reccomend is if this system is to be tested off line then as there is no simulator for the click model & HMI then use the hardware, put temporary DF's in the analogs, create one other program (Subroutine) to simulate the values increasing & decreasing, run it, simple delete the sim routine, put the correct DF registers back in on the Analog I/O & that is it.
The OP's comment about incrementing the pressure to the pump is valid (I think) but only in the respect is that is how it is currently controlled to stop it going over pressure, in reality the operator does this because if turned up too high or too fast then either it over pressurises or a sudden increase of pressure could cause some sort of shock to the part being tested resulting in failure if not in testing but in future.
So perhaps increase the pressure over time but this may increase the test time (as far as the company is concerned time is money), find out exactlywhat the operator does & why is the first step (it could be because "thats the way I have always done it")Technically, it could be a matter of having a starft point perhaps 50 psi, then incrementing it every x seconds by y amount. We can only speculate on that one.
When I replaced the controls on our vacuum test rigs, I watched how the existing system seemed to control it, turned out it was as simple as about 80% full vacuum with a sudden stop at 2% before setpoint. I had Q&A to verify the process was correct using their test packs. The reason for replacing the existing controls was they were bespoke to the OEM & failed frequently & were costly for us to have them repaired.

Click to expand...

Great advice here and I concur. It is so much easier when you can go out on the floor and watch a manually controlled process, then hop back in the shop and hammer out a program.

New programs with two mistakes and one HMI omission fixed. I promise you there are more errors in that program. I have only written two programs that just worked first time right out of the gate. So my first try success rate is about 2/1500.

OkiePC said:

I was looking at your program which had a pre-test pressure to build up pressure to a lower setpoint before running the full pressure test and made a separate state for that. During that step, the I/P transducer is activated and given a command that is determined by multiplying the Pre-Test Scale factor (DF10) by the Pressure Setpoint minus the Inflight or Pre Test Offset pressure.

So you set the test pressure setpoint and then set the Pre-Test Offset to a value that represents in psi how close you need to be to the full test pressure before that step begins.

So say your test is 500 psi, and the pre-test offset is 100 psi. The pre-test pressure command attempts to hit 400 psi before the test pressure step begins.

I think the idea is that the pre-test offset might not change that often for different test pressures. Once this is all working, for different test pressures, the Test Pressure setpoint should ideally be the only value that will need to change.

The other important settings will be the scale factors which might end up being the same for pre-test and test pressure. You may find out after getting this debugged and running, that you can eliminate one of them, but I left separate scale factors just in case they do need to be different.

There's nothing in the program that calculates those scale factors. Those values are going to need to be adjusted or calculated and entered at least once by the engineer or skilled operator.

I still don't understand the system function of the I/P transducer and I have asked before. Does it act as a pressure command directly controlling the vessel pressure or does it act as a pressure adder, constantly increasing the pressure at a rate proportional to its command?

In either case the program should work, but if the latter is true, then the Test Scale Factor HMI entry probably needs to be much lower than the Pre-Test Scale Factor.

Click to expand...

The transducer acts as a pressure regulator/reducer, all it does it take in air from one side and the other side pressurizes it at a constant value. There is 140psi of pneumatic air going in on one side of the transducer the other side is closed at first. Once you give it a current, say 20mA, the transducer opens and lets the max air pressure it can handle, 120psi and holds it there constantly. How this works is the transducer is controlling how much pressure is going into the pump, and the air is being boosted because of the pressure ration 1:16, 120 psi of air gives us 1920 psi output in the pump. If the pressure is constant, then there will eventually be a stall in the pump. So all the transducer needs to do is stay open at a constant pressure to stop the pump at the pressure setpoint.

Also, I changed my mind in the way I wanted to actually pump the system. I assumed that the transducer kept increasing pressure when you give it a constant current, but now that I found out it just gives you a constant pressure at one end, we can calculate how much current to send to the transducer to get the wanted pressure output in the pump. We can do this by taking the HMI pressure setpoint and dividing it by 16, which should give us the theoretical pressure that the transducer needs to output to achieve that pressure. Know I know what to do, by executing it is a different task.

Since giving current to the transducer almost instantly increases the pressure at the other end. I would need to find a way how to slowly increase the pressure in the transducer untill it gets to the right pressure to stall the pump. So I will need to implement some sort of 1 second counter that increases the transducer by 0.5 or 1 psi a second. I will not forget that I will need to watch the operator do it manually to know exactly how fast the transducer needs to go or what the limit of the pump is.

OkiePC said:

I promise you there are more errors in that program.

Click to expand...

I didn't want to be that guy; but now that the ice is broken:

• Subroutine 30 Discrete Valves
  • Rung 2
    • Branched (ORed) compares will always evaluate to True
    • Compares should be in series (ANDed), I think
  • Rung 3
    • Final branch contact (C20 No Faults) should be N.O. not N.C., I think
• Subroutine 50 Test Pressure
  • Rungs 2,3,4
    • Not an error per se
    • DF70 is calculated here but never used elsewhere
      • I think @OkiePC explained this in an earlier post i.e. that the details needed to be fleshed out a bit more for the two-stage approach to the test pressure

Aljubovic said:

The transducer acts as a pressure regulator/reducer,...

Click to expand...

The penny drops .

One thing to remember is that a pressure regulator can only add to the pressure; lowering the setpoint (current signal to the I/P transducer) will not correct any overshoot in the system (assuming the system is closed i.e. pump is stalled).

Aljubovic said:

Also, I changed my mind in the way I wanted to actually pump the system. ... we can calculate how much current to send to the transducer to get the wanted pressure output in the pump. We can do this by taking the HMI pressure setpoint and dividing it by 16, which should give us the theoretical pressure that the transducer needs to output to achieve that pressure.

Click to expand...

The actual ratio at stall will be lower. There is also the psig-to-psia conversion (you want to test at a pump discharge setpoint in psig, but the ratio is pump-discharge-psia/air-psig. So if you want 145.3psig at the pump discharge, and calculate 10psig (=160psia/16 = (145.3 + 14.7)psia / 16) - 5.333mA as the I/P transducer setpoint, the pump will actually stall below that target discharge pressure. So you may need to run it up to that pressure, wait for it to settle, then increase the transducer signal gradually.

Aljubovic said:

[Now] I know what to do, [but] executing it is a different task.

Click to expand...

This is a linear process and you are a second-year engineering student: everything can be reduced to multiplying by unity i.e. multiplying by 1.

The Click PLC has bit, SC7, that cycles at 1Hz, probably with a 50% duty cycle, so 500ms on, 500ms off. You can use the edge* of that bit to trigger any instruction(s)** to both execute on one scan in each second, and to not execute on any other scans of each second.

* look for the Edge Contact instruction
** e.g. increase I/P analog output by the equivalent of 1psi of pump discharge

Aljubovic said:

Since giving current to the transducer almost instantly increases the pressure at the other end. I would need to find a way how to slowly increase the pressure in the transducer ...

Click to expand...

Initially sending a fixed signal equivalent to [Pump discharge target, psia]/16 to the I/P transducer will always stall below the target, as noted above; I don't think there is any reason to go slow initially.

Once that initial stall occurs***, then you want to increment the I/P signal the equivalent of a fraction a psi per second e.g. 0.0625psi/s. The actual value is irrelevant because the program will be monitoring the pump discharge pressure via the pressure sensor's analog input, and choosing when to stop based on that.

If we scale the analog output to be 0-1920psi, then we can actually work in units of discharge pressure for the analog output to the I/P.

*** detecting the stall is another matter but not overly complex, even a 30-50s timer may be good enough; the detection of that initial stall also initiates a new sequence step.

drbitboy said:

I didn't want to be that guy; but now that the ice is broken:

• Subroutine 30 Discrete Valves
  • Rung 2
    • Branched (ORed) compares will always evaluate to True
    • Compares should be in series (ANDed), I think

Click to expand...

Yes, good catch. Thank you. PLEASE be that guy. I need proofreading and thrive on criticism. Don't hold back.

[*]Rung 3

• Final branch contact (C20 No Faults) should be N.O. not N.C., I think

Click to expand...

I think Rung 3 is okay. If we are outside the pressure steps or there is "not no faults" (meaning there is a fault) energize the dump valve.

I still don't know if the dump valve is NC or NO, so that whole rung could be backerdz. I would have the dump valve normally open and have to energize to NOT dump. I went on the assumption that the dump valve is energized to open to relieve pressure. I'd do it the other way around (more failsafe).

[*]Subroutine 50 Test Pressure

• Rungs 2,3,4
  • Not an error per se
  • DF70 is calculated here but never used elsewhere

Click to expand...

Yes, another good find. DF70 is supposed to be the source in file 99 rung 6 and those two compares also need to be in series.

This is why I leave 3 digits in my revision numbering system. I am usually up to the 6th or 7th version by the time I start commissioning.

v003 attached.

OkiePC said:

I think Rung 3 is okay. If we are outside the pressure steps or there is "not no faults" ...

Click to expand...

Oh dear, moving too fast and caught by a double negative (again). I see it now, thanks.

OkiePC said:

This is why I leave 3 digits in my revision numbering system ...

Click to expand...

A reliable convention, to be sure.

P.S. and you are not the only one

I have just re-read the OP's post on the pump, It does appear to be the type I have used, these contain two diaphragms & two non return valves, these will pulse so depending on the size of the pump each time the pump pulses a given quantity of fulid is despensed, this happenes twice per cycle as it pumps so effectively a flipflop, the speed (although not exactly supposed to be a speed control) is varied by the air pressure at very low pressure it probably will not flip or flop the pump, as the pressure increases it flip/flops faster it is a bit crude wasy of metering fluid, I have no idea though if the back pressure of the water used for the test will affect the pumpsd ability to pump with low air pressure so that is probably the reason the operator adjusts it to overcome the pressure of the water. however, this post is getting a bit long so I cannot remember if the operator increases the pressure or decreases it as the pressure goes up perhaps that could be clarified I think we have assumed that as the water pressure increases the operator turns the air down to slow the pump perhaps it;s the opposite.

Another mistake on my part: the 16:1 nominal area ratio can be applied to psig values for the ratio of pump discharge pressure to regulated air pressure; the magnitude of absolute atmospheric pressure is effectively on both sides of the piston and cancels ().

So the analog output to the I/P transducer can be configured with a Scaled Range maximum value of 1920psig (=120*16) @ 20mA and a minimum value of 0psig @ 4mA.

To get up to pressure, I suggest initially writing the target pressure to the I/P transducer analog output pressure (DF105, in @OkiePC's program), followed by three sequence steps:

• Wait to ensure the pump is running:
  • If the measured discharge pump pressure is some delta above 0, then transition to the next step
• Wait for the pump to stall as indicated by the settling of the measured pump discharge pressure:
  • Save the maximum measured pump discharge pressure while the SC7 _1s_Clock bit is 1, and
  • Save another maximum pump discharge pressure while the _1s_Clock bit is 0, and
  • Set a one-shot bit, _1s_Edge on the rising edge (-|^|- instruction) of the _1s_Clock bit
  • On any single scan when _1s_Edge is 1, if the latter maximum does not exceed the former maximum (plus a small delta?), then transition to the next step
  • This could be extended to longer time periods, depending on the character of the system.
• Wait for the pressure to be consistently above the target pressure:
  • Feed a TON (Timer ON-delay) timer, with a preset of 500-900 milliseconds, with a compare [measured pump discharge pressure >= target pressure], ANDed (in series) with a NC Contact on that _1s_Edge bit
    • So the TON is reset
      • EITHER if a measured pressure is below the target
      • OR every second on the rising edge of the _1s_Clock bit
  • If the timer expires, transition to the timed Test Pressure step
    • Because the pressure has been above the target for at least a 500-900ms
  • If the timer has not expired when _1s_Edge is 1, then increment the I/P analog output signal by 8.333µA i.e. the equivalent of 1psi of pump discharge pressure.
  • There is probably a cleaner way to do this without a TON and instead with only the _1s_Clock bit using the State Coil pattern (see here).

Note that the evaluations of the last two steps could be done continuously during all steps, but the results will only effect transitions when the process is in those specific steps.

@OkiePC: I just noticed that Sequence Step 30 doesn't do anything other than immediately transition to step 40. I am going to use it to ensure the dump valve stays open and the pump does not run unless the discharge pressure is below 1psi, even though that should be true anyway for the 10=>20 transition, but this is belt and suspenders.


Same for step 20?


Maybe I can use 20/30/40 as my three steps.