A very difficult problem !!!

Go To Last Post
20 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi there,

I would like to ask your opinion and help about a specific problem.

I am working on an elevator door operator electronic pcb. During the real test I came across a problem that I have never imagined before during the hardware and firmware designing.

A few words about the product functionality: The automatic door operator is used to open and close elevator doors. It is separated in 2 parts: the electronic part and the mechanical part. Both two parts come together as a single product and it is assembled on the top of the lift cabin. So each elevator system has only one of the specific product (cabin door operator). When the cabin is in any floor level, the elevator main control panel sends a signal to the cabin door operator in order to open or close the specific landing door. When the mechanical part of cabin door operator moves, it takes with, the door panels mechanically. In order to have movement of door there is a motor assembled on the mechanical part. The motor gives a movement to a belt. In my case the motor is a brushed one, 24Vdc/50W and 100W with a gearbox to decrease rpm.

The electronic part is used to control the door movement using a PID controller with a periodical tick (compute) time of 10ms. The electronic part also takes measurements of the motor current (in Amps) and the motor velocity (in m/s) using a rotary encoder. Furthermore, the electronic part knows the actual position (in cm) of the cabin door operator, using the encoder counts. The electronic part outputs the PWM signal for the motor, using a full bridge FET driver ic.

In the beginning of first operation the technician runs (via a user interface) a function that is called "Learning". This function will give the electronic part all information about the door opening distance and the rotary encoder signalization. "Learning" function steps described below.

1. The technician presses the appropriate button to move the door in opening direction.
2. The operator sends a constant PWM signal for the motor to move to the opening direction with a stable velocity.
3. The electronic part realizes the opening terminal because of the motor current increase, and the motor stops
4. Now the cabin door operator is positioning the opening terminal.
5. Automatically the operator sends the appropriate motor PWM signal in order to run to closing direction.
6. When the cabin door operator will find the closing terminal, the electronic part knows everything about the total distance (rotary encoder counts) and the encoder signalization as well (A and B signals).

Now the product is ready to execute any open or close command, based on user parameterization.

In the next 3 diagrams you can see the 3 examples of the automatic door movement from one side to the other.

The user set the values of the parameters:

u1: start velocity (in m/s)
c2: the distance (in cm) which the velocity must equals to u1
a1: the acceleration (in %)
u2: the intermediate velocity (in m/s)
c2: the distance (in cm) which deceleration must start order to reach velocity u3
a2: the deceleration (in %)
u3: stop velocity (in m/s)

I have already tuned the PID controller and in order to change the acceleration and deceleration value, the user changes the ki, in a range of some decades (from 0.006 to 0.1). This gives a very good functionality.

Now I will try to explain you the real life problem.

As I said before the cabin door operator is assembled on the top of the cabin which travels from one floor to other. In each floor there are different types of door panels with individual mechanical characteristics (for example different weight of panels). The electronic part does not know in which floor the cabin is. Due to individual mechanical characteristics and the same parameterization, the movement has a very different behavior from one floor to other. As you can see when the cabin door operator works on door 1 (floor 1), the functionality seems to be OK. When the cabin door operator works on door 2 (floor 2) the functionality seems to be very critical, because the door reaches u3 in a distance which is very close to the end terminal. Moreover, when it works on door 3 (floor 3), the cabin door operator never reaches u3 and this is very bad, because door panels knock at the end terminal.

Please note that the parameterization never changed. This means that the electronic part always follows the same setup in any floor, so consider that the setup is the same in any of the 3 floors (diagrams).

I found another similar product in the market and after some tests and measurements I realized that the designer found a very intelligent method to solve the problem above. The functionality differs from my design and it seems to be like this you can see in example diagrams 1, 2 and 3.

The user set the values of the parameters:

u1: start velocity (in m/s)
c2: the distance (in cm) which the velocity must equals to u1
a1: the acceleration (in %)
u2: the central velocity (in m/s)
a2: the deceleration (in %)
u3: stop velocity (in m/s)
c2: the distance (in cm) which the velocity must equals to u3.

In every movement the electronic part pre-calculates the "j" distance (in cm) and automatically knows when it has to get in deceleration mode in order to have always a constant c2 distance (in cm).

Please note that the parameterization never changed. This means that the electronic part always follows the same setup in any floor, so consider that the setup is the same in any of the 3 example diagrams.

Can anybody realize what to do in order to pre-calculate the actual position, that I have to start decreasing u2 and to reach u3, in order to have a steady c2 distance?

Thanks in advance.

Attachment(s): 

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I betcha the computer can read the door position and therefore calculate door speed and therefore calculate door acceleration and therefore calculate door mass. Seach google for "PID for non PHDs" and start reading.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ultra thanks for the first reply !!!

Are you sure there is a way to calculate mass ???

And if I know the door mass how this could gime me the "j" distance ?

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PID or any other semi inteligent motion control algorithm is OK for responding to SETPOINT changes.

You need to issue setpoints to the algorithm in order to achieve what is required... COORDINATED MOTION .

RFID tag seems like a way to instruct the door motion controller about the door and load it has to cope with.

Coordinated motion relies on precalculated setpoints ( motion profile). PID is there to ensure the profile is adhered to.

EDIT: Control console inside the cabin knows floor number... may be no need for RFID

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My Old Buddy Isaac told me f=ma. I know the f of the motor, I measure the a of the door, all I need to do is find someone that knows how to solve for m.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
all I need to do is find someone that knows how to solve for m.

That seems to be a problem these days.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Along with the estimate of m You need to know S the distance in order to be able to apply

S= v*t +0.5 a*t*t and shut the case

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Guys,

The electronic part measures (knows):

- door velocity u(m/sec)
- door position s(cm)
- time t(ms)
- motor current I(A)

So I can calculate a(m/s^2).

How do I know motor Force (F) in order to calculate door mass? Finally, how all these calculations could give me the unknown "j" distance (for "j" please see the diagrams at the start of this thread). ???

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you have a mechanical brake to stop the door or do You rely on motor to slow the door down.
May be You can use regenerative braking to slow down the door and then use motor to bring it to a halt gently.

In any case set maximum door velocity.

Accelerate the door till max velocity reached or door half opened record distance.
Maintain velocity till distance leftover same as inital acceleration distance.

Apply brake/ deceleration and coast door to end of travel.

No need for any other calculations.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There in no need of mechanical motor braking. The motor velocity is totaly controlled by the electronic circuit. Althought there is no mechanical brake, any mechanical brake would be a bad idea, because any abrupt change of the motor velocity would make the door panels to oscillate. If you can feel this ???

Furthermore, setting the velocities and accelerations have no effect in real life, because the final user will change them for sure.

I am working on newton's F=ma. But I need more help.

Quote:
The electronic part measures (knows):

- door velocity u(m/sec)
- door position s(cm)
- time t(ms)
- motor current I(A)

So I can calculate a(m/s^2).

How do I know motor Force (F) in order to calculate door mass? Finally, how all these calculations could give me the unknown "j" distance (for "j" please see the diagrams at the start of this thread). ???

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the motor volts, current rpm rating? (nameplate data). Watts is torque*omega (in radians per sec). Force has to do with the radius of the pulley on the motor I guess?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had the fortune of getting to tinker with one of the earliest Otis automatic elevators (~1926) in a building scheduled for demolition. The doors were operated by a simple resistor-ballasted 3-phase motor equipped with a snail cam that controlled the rate of movement. The motor simply opened and closed the doors against mechanical stops. I thought the setup was quite elegant and it was very smooth in action.

edit:

I forgot to say that it is amazing how complex we can make some things, but in doing so, do we really make them better?

Tom Pappano
Tulsa, Oklahoma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When I went to the dept store with Mom (in the 50s?) there was an operator.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
When I went to the dept store with Mom (in the 50s?) there was an operator.

Same here! Supposedly, part of the impetus behind developing automatic systems in the early '20s was that operator strikes had crippled operations in several large buildings.

Ooh, and AFAIK, we're paying substantial salaries to operators in the Capital. Our congress critters apparently to busy or not skilled enough to push a button. (that's not too political, is it?)

Tom Pappano
Tulsa, Oklahoma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just how uncomplicated is a snail cam and resistor balast ( consider characterisation of the 3 phase motor and embedded program in the cam)?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

icarus1 wrote:
Guys,

The electronic part measures (knows):

- door velocity u(m/sec)
- door position s(cm)
- time t(ms)
- motor current I(A)

So I can calculate a(m/s^2).

How do I know motor Force (F) in order to calculate door mass?

I don't think you need to bother with mass, just check the position and decelerate slope as the door moves, and live-adjust the decelerate as needed to reach the slow-speed region, far enough before the stop.

ie you are really entering a velocity profile polygon, and then adjusting the control to nominally track that.

Basic Too-Fast => Brake harder, and Too-slow => More Volts.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Just how uncomplicated is a snail cam and resistor balast ( consider characterisation of the 3 phase motor and embedded program in the cam)?

I wasn't quite clear enough in my description 8) The cam did not control the motor itself, the cam just translated a partial revolution of the motor shaft to the horizontal motion of the doors. The motor was just powered with full line voltage through the resistors, either forward or reverse, more or less just acting as a source of constant torque.

Tom Pappano
Tulsa, Oklahoma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Personally I have never seen an elevator that has different doors on each level. The doors usually are doubled on elevators here, and have separate electronics and mechanics. One set of doors on the lift cabin, another blocking the entrance to the elevator shaft in the corridor.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The same as here, but there are cases, hotels for example, that use to vave different themes on each floor. Metallic doors, Glass Doors e.t.c.

Michael.

User of:
IAR Embedded Workbench C/C++ Compiler
Altium Designer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't think it's a good idea to use a PID controller like this. You intentionally make it heavily overdamped to create an acceleration profile.

I believe the normal way to do motion control is to have a current (torque) control loop that controls the motor, that in turn is controlled by a position regulator, and as ignoramus already mentioned, a setpoint generator that controls this positioning regulator. Not all loops have to run at the same frequency, probably something like a ratio of 1:2:4.

Acceleration usually isn't changed abruptly either, change of acceleration over time is called jerk.