Pressure rate control PID loop

Kamenges - In post #9 above, you seem to say that I could use a PLC for this because I have some air entrapment. I don't want to put you on the spot but, with the information given, what confidence level do you have in that statement? At this point I'm leaning towards a PLC with about 80% confidence. Saying this alone may make me want to error on the side of overkill and go ahead with a motion controller. What do you think?
 
Kamenges - I really like your suggestion of not using the PID loop instruction and just implementing a proportional loop based on the error signal - pretty slick! As you can see though, the thing that's giving me headaches is trying to predict how much this entrapped air is going to help me. I will read up on the web sites you posted regarding the bulk modulus and hopefully afterwards I will have some more intelligent questions to ask. If you don't mind, please check this thread periodically - I will try to add some more info.
 
Are they related in any way to Delta Tau motion controls? If so, I will be running in another direction at top speed. I worked on a system with delta tau hardware over last summer and had nothing but trouble. Their hardware is awsome but, the development environment, setup software and manuals are ****.

No relation. I have used the Delta Tau as well and I know your pain. You should check out the links I gave you. The RMC Tools software is a free download and you can connect to one of thier ethernet controllers online. These RMC controller are made just for your type of application.

Peter is the Delta Computer guy on this forum. I know he has been on the road this week. I'm sure when he gets time to log in he will post something.

How much I/O do you have? You may be able to do it all in an RMC70
 
Last edited:
First of all, the Delta that CharlesM mentions is NOT Delta Tau Data Systems (the PMAC guys). Delta Computer Systems is a different company altogether. Peter Nachtwey, one of the principles of the company, is a valued and prolific contributor here. In addition Detla Computer Systems tend to specialize in hydralic applications. Transitioning between position and force control is one of the things they do very well.

Keep in mind that I have no specific experience with burst testing. I believe Dan Bentler and Peter Nachtwey used to ride around underwater in metal tubes so they probably know more than most about burst testing. Dan says that you don't want any air entrapment. If this is the case then you will very likely need to go with a motion controller unless your test volume is very large relative to your pump flowrate. It all comes down to rate of change and how accurate you need to be. If you are accurate with the 3 RPM = 100 PSI/sec number and you can live with a 10PSI or so variation you could most likely do this in a plc. Keep in mind you will be more rate limited than you think as plc analog inputs are pretty slow. This is another place that motion controllers tend to excel.

Some of this decision is also based on your available time. Do you have the time to switch to something else if a plc can't do what you want? If so, give it a shot and see what happens. If you need to have it right the first time, get all your information together and call Delta or wait and see if Peter responds.

How was that for a waffling answer!! :oops:

Keith
 
Kamenges
Thanks for complement. Learned a fair amount on submarines, true, but some from Dad who worked at Boeing Primary Standards doing calibrations using dead weight tester on high pressure guages and other components up to arould 10K psi.

The main reason (I was taught) to use water and to reduce air in a high pressure hydro application was that if anything failed, the small factor of water compressibility would not create a bomb type hazard. Air entrapment increases the hazard of flying parts if there is a rupture.

I am sure that since you are intentionally doing testing to failure (rupture) you have some method to ensure no hazard from flying parts.

I also think that if there is air it would be OK -- PROVIDED -- you could hold a pressure and allow air / water mix to stabalize - under your test parameters I think air will give you difficulty in getting good readings because you may not be able to get to a stable point. The one main advantage to having a small amount of air would be to dampen temperature changes in your system - with a "solid system" ie water, temperature changes will give you a large change in pressure.

Interesting challenge.
Dan Bentler
 
I agree with rootboy

I would just increase the pressure until it bursts. If the sample time is fast enough then the burst pressure will be know. For instance with a ramp rate of 100 psi/sec and a sample rate of 0.5 milliseconds the burst pressure can be determined to within 1/20 psi. Is that good enough? Even if the pressure rate was not exactly 100 psi/sec you should be able to get the burst pressure within a fraction of a psi.

The key here is speed. Ramp it up as fast as you want until you get close. It shouldn't make much difference what the exact speed is as long as the data can be sampled quickly. 0.5 millisecond real time graphs are easy.

One can go through all the trouble of computing exact ramp rates but does it really make any difference? As long as one can tell exactly when the failure occurred and the pressure rate is low ( 100 psi/sec is low ) you should be able to get accurate readings even if you used open loop control.

Note, the speed for the pressure rate can be easily calculated but we don't know the volume of water being compressed.
 
While its not going to really be an issue in this application with this particular hydraulic generator, entrained air is the enemy in precision hydraulics - I've had no end of headaches with servo valves and entrained air.

It usually happens like this: Bubba replaces the seal on a very large horizontal cylinder, so naturally it's full of air. Then he decides that the fastest way get rid of the air is to stroke the cylinder, and a giant bubble of air returns to the tank, turning 900 gallons of oil into mayonaise. He's done so he hands the machine back to production. Fifteen minues later I get a call because position and force control has gone to hell (jet pipe servos don't like entrained air) - inevitably we end up waiting for all the air bubbles to work their way out of the oil.
 
Originally posted by Peter Nachtwey:

0.5 millisecond real time graphs are easy.

You shouldn't infer, Peter. I'm pretty sure mcafone doesn't know.

The thing Peter didn't include on the end of the above sentence is "...for a motion controller or other high speed dedicated computer." That kind of response is out of the realm of possibility in your run-of-the-mill PLC. Granted, there are some out there that can do that. The MicroLogix family isn't among them.

You also need to ask what kind of resolution are you capable of, both at the sensor and at the analog input to whatever controller you choose. In Peter's example above he gave you a response rate that will get you 1/20 PSI accuracy. If your resolution is 10 PSI that kind of speed isn't going to help you much. With 10 PSI resolution in Peter's example you will just read the same pressure 200 times in a row and then it will jump up 10 PSI.

Keith

Keith
 
OK, I will be more blunt.

kamenges said:
You shouldn't infer, Peter. I'm pretty sure mcafone doesn't know.
What you need is:
1. Is a very fast sample time. The faster the better. 0.5 milliseconds is easy.
What you need is to record the maximum pressure your test gets to. The pressure will build and when the item ruptures the pressure will quickly drop. If the pressure readings can be logged every 0.5 millisecond then it should be easy to find the peak pressure.

2. The analog response should be fast, much faster than PLC analog reading. PLC analog inputs are good for slower temperature controls. Our controller does an 8 times over sampling. That means we do 8 A to D conversions every 0.5 milliseconds. That is 62.5 microseconds per sample. We then average the 8 analog. This effectively extends the resolution by the sqrt(8) bits. It also means the all the averaging is done within the sample time, not over multiples sample times which would cause phase delay.

3. High resolution. We have a 16 bit A to D converter. This allows us 0-32767 counts in uni-polar mode or -32767 to +32767 in bipolar mode. One must use wiring tricks to bias the system in bi-polar mode so I will assume the uni-polar mode is used.

Now for the calculations:
Given the pressure range is 0 to 10000 psi

(10000 psi/32767 counts)*(1 count/0.5 millisecond)=610 psi/second.

What this means is that at 1 count per 0.5 milliseconds the minimum detectable rate is 610 psi per second. One can try increasing the pressure at slower rates but that would mean the controller would not see a change in counts each scan. This is just wasted time. The situation for the slow PLCs is much worse. I know you can miss a whole pressure transient with the scan of a PLC.

Conclusion.
1 The real resolution is 10000/32767 or about 1/3 psi per count.
Not the 1/20 psi I mentioned before.
2. A PID is not required. What would the set point be? You don't know the pressure where the parts will fail. Just use an open loop control output so the pressure increases somewhere around 600 psi/second and then wait for the pressure to drop. The pressure drop occurs when the item bursts or fails. It is easy to test whether the new pressure is less than the previous pressure. This can be done every 0.5 milliseconds.
3. The peak value is the burst pressure.
4. Upload the graph of the test data and save it on the disk. Do this using Ethernet.

The RMC70 can do all of this easily because is was designed to do hydraulic position/pressure/force control. No PLC required.
 
More Information

Looks like I've been holding my cards a little too close... Let me give you guys a sense of scale here... The hydraulic generator I'm using will generate a maximum of 30,000psi in a length of 0.083 I.D. tubing (around 2.5ft in length), connected to a Parker quick coupler fitting (HP006-0-HM4). The operator mounts a burst disk in a custom fixture, which is then covered with a screw cap that is tightened with a torque wrench to specified torque and then connects it to the quick coupler via the mating fitting. When the cycle is started, the system drives the generator screw at a fixed rate unit a holding pressure is reached. The pressure is then held for 10-15 seconds to check for leaks. The pressure is then ramped at a fixed rate until a burst is acheived. The application requires a 100 psi/sec ramp rate to the final burst pressure. The burst disks are around 0.5" to 1" in diameter and around 0.010" to 0.030" in thickness. As you can tell, the nature of the operation is to intentionally have some air in the system because any water in the removable fixture drains out when the operator mounts the next disk for testing. I'm starting to think that because of the intentional air entrapment, I probably could do this with a PLC but, the question I really need to answer at this point is "How accurate do I need to be?". This may yet dictate the need for a motion controller. I hope the RMC70 can communicate with an off the shelf SCADA package. I really don't want to write a custom HMI for this project.
 
mcafone said:
The application requires a 100 psi/sec ramp rate to the final burst pressure.
OK, the target pressure can be ramped at that rate. The goal will be to keep the actual pressure close to the target pressure. You must realize that the feedback will change only once every few milliseconds because even with out fine resolution it is not enough. Ideally one wants to have very fine feedback resolution. Since we do a lot of pressure applications we even have a pressure rate feed forward to minimize lag.

There must also be very fine control over the pump. Hopefully it isn't a piston pump. Any kind of pressure ripple from the pump will be a killer.

The formula for the rate of pressure change is

PressureRate=BulkModulusOfWater*FlowRate/Volume.

You can see the flow rate must be constant if the pressure rate is to be constant. None of this happens magically. The system must be designed right first. The bulk modulus of water is about 312000 psi which means even a small change in flow will cause a big change in the pressure rate. The air bubble may actually help with smoothing out the pump pressure ripple.

I hope the RMC70 can communicate with an off the shelf SCADA package. I really don't want to write a custom HMI for this project.
The RMC70 supports many PLC Ethernet protocols. Ethernet/IP or Modbus/TCP are the ones most likely supported by your scada. A lot of people just use the setup software that comes with the controller because it does everything they want to do.
 
Pressure Generator

The pressure generator I'm using is basically a screw-driven syringe so, the pressure change should be pretty smooth.

I've haven't used ethernet/ip as of yet. How hard is that to set up as far as handling analog values? Is there any special software needed for commisioning the network?
 
Peter, I sent you a private message with my contact information. Please give me a call or pass it on to the local Delta representative.

Thanks.
 
mcafone said:
The pressure generator I'm using is basically a screw-driven syringe so, the pressure change should be pretty smooth.
Good.

I've haven't used ethernet/ip as of yet. How hard is that to set up as far as handling analog values?
We have excellent step by step pictures showing how to configure a Control Logix but you said you are using a scada. I don't know anything about the scada you are using so I can't tell you what it will take from their side. Perhaps Modbus/TCP would be easier. However, we usually are transferring 32 bit floats so analog values are not a problem.

Is there any special software needed for commisioning the network?
Our controller requires RMCTools to setup RMC75 but that is free. You just need to set up the IP address on our controller so it will be on your Ethernet net work. Our motion controller will look like a PLC to the scada system. The scada must be able to support one of the PLCs that we support. If you use Ethernet/IP well will look like a SLC500 with a lot of F registers. AB, Modicon, Mitsubishi Q, Omron FINS, AD, Siemens fetch/write. The RMC75 will automatically detect which PLC protocol you are using ( the application layer ).

I like Ethernet/IP because it has the ability to access the largest data space. Some protocols like Modbus/TCP can only access 32768 floats.
 

Similar Topics

I'm trying to work through a question I have about using a PLC, plus separate temperature and pressure controllers on a plastic extruder rebuild...
Replies
9
Views
2,980
How to calculate flow Rate of water and Steam ton per hour with pressure differential.
Replies
9
Views
32,112
I just realized that the three new horizontal tanks tanks we're installing this weekend will need a CPT and some in order to allow the provided...
Replies
10
Views
4,201
I had posted an earlier thread about a scale w/parameters issue. Turns out it may not be the issue. Since, I do not have much PLC experience, nor...
Replies
23
Views
7,001
Does anyone have experience wiring this type of analog pressure transmitter up? It's 4 wires. 3 blacks and 1 green which I assume is earth...
Replies
9
Views
253
Back
Top Bottom