Pressure control in hydrostatic propel circuit

[kcj]

This is similar to my other post about force control circuit. I think the fundamental control concepts are the same in both cases, and I am equally baffled in each case. My drawback is that I am not a controls person, and don’t understand how plc approximates the old ancient analog closed loop amplifier cards, and how they differ.

Application: Hydrostatic control of a propel circuit for medium sized railroad maintenance machine. Weight about 800,000 lbm, and 1000 drive hp. One power car with up to 8 hydrostatic pumps drives 4 axles, (8 motors) underneath it, and pulls several assorted functional cars behind it. Long runs are welded pipe, with about 6 ft of 1 to 1.25 inch hose at each end at each pump and motor.

Pumps have 4-20 ma drive from plc directly to on board electronics.

Machine natural frequency of the drive is about 2 seconds period (1/2 hz) from test data. I would think the control circuit should have no problems controlling pressure on this circuit, as a good operator can do it manually.

Control loop is plc, 3 to 5 ms scan time I am told, with P & I gains only, no D term. (Red flag?)

Stick command is speed setting mph (pump/motor displacement). First half of stick motion strokes pumps, the second half of arc destrokes the variable motors.

Outer control loop is the speed command, next inner loop is maximum pressure limiting, and last inner loop is rate of pressure rise. Rate of rise may not be feasible due to noise, and is disabled at the moment.

In braking, the motors are first commanded to increase displacement to reduce speed and increase braking torque. Motor control is limited such that braking pressure should not exceed a table value so pumps (now acting as motors) do not overspeed the diesel and drop off the the generators due to overfrequency. This braking pressure may be 1500 psi at full pump displacements, increasing to maybe 4000 psi as pumps destroke, then decreasing again for a soft stop.

Another version of this circuit uses (2) systems in a master/slave situation. Second unit slaves its pressure on pressure of the first unit.

We are trying to mimic a good operator: bring the stick on stroke just enough to smoothly bring pressure up, limit pressure to say 4500 psi during acceleration to speed setting, say 40 mph, at which point pressure drops off. I have seen it commonly done before, but never involved with controls logic to know how the basic PID loop was done.


When acceleratiing, or braking, the plc output appears to move in steps, pause, move again, pause, etc. It does not seem symmetrical or stable. It appears to not move in the oppostie direction for corrections, only to pause and wait if the correctiin was too much. Pressure surges accordingly. Playing with gains does not resolve it.

As explained to me, the plc is not really ‘closed loop’ but is time based, open loop control with increments and steps that vary according to pressure. I think this is why the output tends to step in one direction only, then pause. How is this plc concept different from true closed loop, can I get it behave as more truly closed loop?


kcj

 

[swn1]

OK, kcj, give up on PIDs. Absolutely the only thing they have going for them is they are easy to purchase.

The multiple control regimes here (accelrating, crusing, braking) and the multiplicity of loops (prime mover speed control, generator field control, pump motor drives, pump and motor displacement control) call for a very sophisticated control system design.

As far as tripping the generator off due to overfrequency goes, you should be able to avoid that unless it is delivering a significant fraction of rated current while operating off-frequency. At very light loads a syncronous generator can operate off-frequency without damage. You might have to have a different protection package put on it to provide enough flexibility to deal with the situation, though.

Are the electic motors driving the pumps speed controlled?

Is there any other significant load on the generator?

 

[kcj]

*****Back on the board. Tks for response.

The multiple control regimes here (accelrating, crusing, braking) and the multiplicity of loops (prime mover speed control, generator field control, pump motor drives, pump and motor displacement control) call for a very sophisticated control system design.

*****I should clarify, the engine speed control is done by the Cummins controls, the gen control done by the gen or SCR mfr controls. This portion controls only pumps and motors. Yes, I am seeing the system required to mimic a ‘simple’ human operator is complex!


As far as tripping the generator off due to overfrequency goes, you should be able to avoid that unless it is delivering a significant fraction of rated current while operating off-frequency. At very light loads a syncronous generator can operate off-frequency without damage.

Are the electic motors driving the pumps speed controlled?
Is there any other significant load on the generator?


******HST pumps are not electric motor driven, but from engine mounted pump drives. Typically there are one or two multiple gear drives, through shafted from engine, with shaft continuing to the generator. Usually, the generator load is heaviest in Work mode, when most of the pumps are diverted to run work functions but operating at lower pressures and not at full flow. Two pumps remain on propel system. In Travel mode, most pumps switch into the common travel pressure ‘bus’ piping. Gen load is maybe 25% or less in that case.
The problem with overspeed is not generator damage per se. When in braking, the axles act as pumps, the engine gearbox mounted devices we used to call pumps now act as motors, and they bring the diesel engine speed up. Overfrequency protection required for the computers, controls, etc. etc. trips the gen off line, or may totally dark the machine but dumping the engine, above a certain engine speed. Thus, we can use full 5000 psi when in acceleration, but only about 1000-1500 psi when in braking. If that does balance the grade, the machine either picks up speed or is held by air brake train line system. As the pumps go to smaller displacement (less stroke, decreasing machine speed) the torque to the diesel decreases and system pressure theoretically could rise without overspeeding the diesel. For the moment, we just limit all the braking to about 1500 psi.

k

 

[swn1]

I was going to ask about the braking problem again, thanks.

The energy has to go somewhere, and the I.C. engine isn't going to turn it back into dinosaur juice.

Have you considered pumping up a receiver or a flywheel? Make a green machine out of it?

In any case, your braking problem is an energy flow problem and not (primarily) a controls design problem. You can't ask the diesel to dissipate the braking energy, any more than you can use negative supply pressure for braking. Once the HP from braking exceeds the HP of the remaining load and losses, the machine will inevitably speed up. Adding an engine brake might help, but even with them highway trucks still use their air brakes.

The control program should probably be organized around the energy flow concept. You mentioned raising the system pressure to accellerate and letting if fall for cruise. If the program knows more-or-less explicitly how much power it is trying to deliver (or absorb) it should be able to "plan" a pressure profile to achieve it.

Doesn't have to be a big AI platform to do that, ladder logic can accomodate it.

Let me tell you a story. Friend of mine was at a bakery. They have "proofing rooms" where the bread rises at a controlled temperature and humidity. There was a sump full of water with a steam pipe in it and a makeup air duct with an electric heater in it.

They had two PID controllers, one for temperature and one for humidity. Hooked up the temperature controller to the heater and the humidity controller to the steam valve - admitting more steam makes the water in the sump evaporate faster, etc.

Only problem is, it didn't work. If you work out the thermodynamics it is pretty obvious, really. The steam valve raises both the temperature and the moisture content of the room, leaving relative humidity more or less unaffected and swamping any authority the heater had over temperature. Reversing the controls made the steam valve the temperature control actuator for the room. The humidity controller drove the makeup air heater, controlling the relative humidity indirectly by modulating the demand for steam. Works great.


Sometimes, the right control laws are not the obvious ones. I suspect your system would work better if the control philosoply was reworked to be "supply side" rather than "demand side" driven. Try making the pump displacements respond to engine RPMs and the motor displacements respond to pressure when in acceleration mode. Then your acceleration demand input feeds in as the setpoint on the pump control loop. Offset to high RPMS and the pressure drops, offset low and it rises. Pressure rise triggers load demand increase, but only as fast as the prime mover can accept it.

Details left as an exercise. A bias input to the engine controller would be a handy thing to have, but if you don't have it you'll have to make do without it. How did the human operators "goose" the engine when they needed power?