Oil rig drawworks

[Ryan Carlyle]

I was offshore on an oil rig most of last month, and we ran into an interesting potential failure mode on the drawworks. That's the massive wire & pulley system that hoists the block up and down in the derrick. (You know, to lift a million pounds of drillpipe in and out of the hole.) This particular rig's drawworks is an "active heave compensating" model, meaning it senses the motion of the floating drilling rig and actively pays in / pays out on the wire to maintain constant drillpipe tension/position.

So it's basically a giant Z-stage. 

The drawworks has a 16-fall block and tackle arrangement that looks roughly like this:

It has a big drum that spools up the wire on the "fast line" side, a "dead line" that is clamped to a weight indicator at rig floor level, a stationary "crown block" at the top of the derrick, and a travelling block. The drawworks motor and drum unit is roughly the size of a trailer home:

Yep! It's just a giant spool drive, using a 2" thick wire rope:

Anyway, this thing uses accelerometers and feedback controllers to pay in and out as needed to keep the drillpipe stationary despite the floating rig/derrick heaving up and down due to waves. It runs on a ridiculously large VFD drive, which at low speeds operates very similarly to our stepper motor controls. (An AC motor on a VFD drive is theoretically equivalent to a stepper motor operating at very high microstepping levels.) You could build a pretty simple analog to this in a 3d printer for a Z stage. 

The potential issue we ran into was a hypothetical over-speed failure mode. (It happened to another rig in the past and we were worried about it happening to us.) Specifically, it was a software issue where the normal rig heave motion (maybe 1 ft/s for extreme weather) stacks up with the feedback loop's position correction adjustment, and together the two effects add up to attempt to accelerate the system faster than the overall mechanics will allow.

Here's the really interesting part: the problem only occurs during downward acceleration. High speed is no problem, and upward acceleration is no problem. The physics of the system limit downward acceleration and nothing else. Why? Because you can't push a rope. 

This hoisting system can pay in wire at great force to lift the load. But to lower the load, it can only pay out and provide slack wire. The weight of the load must pull the wire through the pulley sheave wheels. And these are extremely large, heavy sheave wheels, operating at high speed. As I said, it's a 16-fall block, meaning the fast line must move 16x faster than the load. And there are about 10 extremely large, heavy sheave wheels that must be accelerated/decelerated to accelerate/decelerate the block. 

Here's a picture of a small crown block for a sense of how heavy these things are:

The critical thing to realize is that the inertia of these spinning pulley sheave wheels is actually a large fraction of the total system inertia. Gravity is not just pulling down on the load -- the load's weight must provide the force to accelerate all the attached components in the pulley system. If you don't have very much weight on the travelling block, you don't have sufficient force to accelerate all the wheels at high rates during downward acceleration and upward deceleration. And if you can't accelerate the wheels very fast, the block can't fall fast enough to take up all the wire that the drawworks drum is paying out. 

End result: slack wire on the fast line between the drum and the first sheave wheel. That causes the (very stiff) wire to jump out of the sheave and probably backlash the wire drum. That is a Bad Thing. The last time this happened, the weight of the block ended up dropping and shock-loading the drillpipe so bad it snapped in half. And that's a pipe rated for over a million pounds of tension. It's roughly equivalent to dropping a two-story house on something.

I found this whole issue extremely interesting because it's a hoisting system (Z stage) failure mode that isn't based on high speeds or high loads. It only occurs with low hanging loads for a single acceleration direction. Once the sheave wheels are up to speed, you're fine. When you're accelerating upwards, you're fine. When a human being is (cautiously) operating the joystick, you're fine. The issue could only arise when the active heave compensation code commanded an extremely fast acceleration during a specific type of weather. But that's how it usually is -- complicated systems fail in complicated ways.

[Jetguy]

Ryan, I can give a real world example.

Not exactly the same but is the same on the feedback loop observation.

Take cruise control in a car. While on one hand, it tries to regulate a steady speed and most do OK on flat level ground. Introduce some hills and now it lags, then overshoots, then gets really weird as the transmission downshifts. There is just the common problem that the PID is tuned for one condition, but outside forces can imbalance that and cause severe oscillation and overshoot undershoot.

You as a human take so many other factors into consideration. You know you want to maintain a certain speed so you apply a minimum threshold (basically you self limit the basic range of throttle). You know you need some throttle ALL the time, and won't completely let off unless you are really about to hit something. You do slow gradual increase and wait for the trans to shift, then rate limit at a safe throttle position.

Basically, your brain understands MORE than just target speed VS actual speed. You know it's a hill, you know you need more throttle. You know the transmission may downshift and you account for that. You know as you crest the hill to let up before you ever pick up speed over the target speed. You hold the throttle in fixed and steady positions- even when there is minor over or underspeed condition as you are watching the longer trend over over time, not instant error.

In your example, you related that a human knew the slack cable problem and thus a differential PID loop was applied on a per direction basis. But you also showed that  human taking more input that the sensors of the controller can predict problems and will apply dampening, and smarter control than the machine.

Not sure how to best describe it, but I guess I see the issue as having not enough sensors and a simple active feedback loop with a rather simple control program. Humans take much more data in (Sight, sound, even intertial measurements (inner ear), previous predictions, and smart logic and apply a constantly varying set of rules to control.

It's literally why sometimes, you cannot take the human out of the loop.

[Ryan Carlyle]

It's all about model-based control vs feedback control. Pure feedback loops can only react to error and thus cannot have perfect performance. The best control schemes add some "brains" in a predictive model, and then use the feedback component to correct model errors. 

In this specific case of the drawworks, the system was programmed to know its own limits, but the integral component of the PID output was being added after the limits were checked. So vessel motion action alone was properly regulated, but after a long period of sustained error (due to the system respecting other limits, such as hoisting power or braking capacity) the PID integral term accumulated a big correction factor and tacked on additional acceleration that wasn't being checked against the system limits.

[Jetguy]

Yep, that "I term can really be very problematic in many PID loops.

[Joseph Chiu]

I take it that it's the upside-down version of trying to maintain a balloon's elevation?

--
You received this message because you are subscribed to the Google Groups "3DP Ideas" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 3dp-ideas+...@googlegroups.com.
To post to this group, send email to 3dp-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/3dp-ideas/a4551d85-7653-4e54-80d1-3cd6f01509e2%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ryan Carlyle]

Heh, kind of, yeah.

To unsubscribe from this group and stop receiving emails from it, send an email to 3dp-ideas+unsubscribe@googlegroups.com.

To post to this group, send email to 3dp-...@googlegroups.com.

[Jetguy]

I think that is a good example. The typical balloon does have a fixed rate of rise due to reaching terminal velocity (kinda funny when you think about it) And, that also gives the idea of slack cable as well.

To unsubscribe from this group and stop receiving emails from it, send an email to 3dp-ideas+unsubscribe@googlegroups.com.

To post to this group, send email to 3dp-...@googlegroups.com.

[Ryan Carlyle]

By the way, here's a pretty awesome video (from my Australian compatriots) showing how we rig up and use compensating systems on the rig. Not strictly relevant to this discussion but it does kind of show how these heave compensating systems fit with the equipment. 

https://www.youtube.com/watch?v=xZtBEu-KyzY

Designing and writing procedures/storyboards for this sort of equipment & rig operation is a large part of what I do professionally, but we don't usually get nice animations done like this. (Our equipment in the Gulf of Mexico is generally simpler to handle because our weather is much milder than northwest Australia offshore.)

[ji...@mad.scientist.com]

from what you just said, it sounds like someone left out a software check- - - limit check that is.

Jim P

[Ryan Carlyle]

Yeah, I think they applied the limit at the wrong place in the code.