RSlogix - Simple 2 level Elevator with Subroutine

[mitureg]

Thank you for your ELEVATOR.xls file. That looks interesting the way you did that simulation. Nice piece of history.

How do we play with the values to have this spreadsheet return something?

Cheers.

 

[Lancie1]

I do not understand what this is, could you explain it, is it a typo?
This is so no outputs ges stranded in ON state

Yes, it should say:
"This is so no outputs get stranded in ON state."

Because you wanted to simplify the elevator functions into 2 subroutines, you have to reuse the Door Close and the Door Open outputs in TWO different places (double coils). This can work only because each output duplicate is not in the same subroutine file, and only IF each output is NOT left ON in any subroutine. Otherwise the OTHER subroutine cannot turn ON that output at the proper time to open or close the door, because it is already ON. As you have been told before (see RSLogix SBR warning):

 

[Lancie1]

How do we play with the values to have this spreadsheet return something?

Place a "1" in an elevator call button (one of the 6 FLOOR or Corridor buttons (0's) as the schematic called them, or in the 6 CAR buttons (0's) inside the elevator, for a floor NOT where the elevator car is located).

Then press the red RUN button. You should see the door "close" (0's become X's), and the car should move up or down to the selected floor, then the door opens. Notice that you can select multiple floors, and the car will move until all requests have been handled (unlike your student version). It moves up until all the UP requests are handled, and down until all the down requests are handled, not changing directions in mid-stream, just as the real one did. See the "Notes" tab for more details on how the original elevator worked. I must have been a lot sharper mentally back in those days, because I look at those relay Boolean equations and wonder how I ever figured it out. It was a case of someone on the team having to figure it out or do without a valuable tool, because we could get no outside help due to the circumstances.

I had to add the RUN as an additional control that was not on the original 1956 Otis elevator, because there was no other way to allow the spreadsheet to enter and read more than one "button" (a 1) at a time. If I had caused it to go into RUN mode as soon as a floor buton was entered, then no other buttons could have been pressed while the MACRO commands were running. Other than that type of change, I tried to keep the logic identical to the old relay-logic schematics drawings. This old elevator was not nearly as good as modern elevators. It could be jammed up because it used only relays and relay-type devices.

That old elevator was about the last piece of equipment that we demolished in that building! It was just too useful for moving people and all their tools to the upper floors on hot days. The team were very appreciative that I found the problem, celebrating and buying me many beers at happy hour back at our hotel.

 

[mitureg]

Because you wanted to simplify the elevator functions into 2 subroutines, you have to reuse the Door Close and the Door Open outputs in TWO different places (double coils).

How many subroutine would you suggest in order to break down this program? Can it be easily done?

This can work only because each output is not in the same ladder file, and only IF each output is NOT left ON in any subroutine.

I understand that. I remember as well the double-coil syndrome.

Cheers

EDIT: I see only these additional: "Close Door"; "Open Door";

 

[mitureg]

Place a "1" in an elevator call button (one of the 6 FLOOR buttons or the 6 CAR buttons inside the elevator,...

Thank. We'll have a try.

The team were very appreciative that I found the problem,...

They sure must have been! Good one.

 

[Lancie1]

How many subroutine would you suggest in order to break down this program? Can it be easily done?

EDIT: I see only these additional: "Close Door"; "Open Door";

Yes, only for this crippled 2-floor version that automaticaly returns to the 1st floor, then I think if you added a Close Door and a Open Door subroutine, then you could avoid the double-coil problem and not have to worry about leaving an output ON, because each output should finish its job within its own subroutine (as now already happens for the Motor Up and Motor Down in the Going Up and Going Down subroutines). If you do add these two subroutines, then you will probably need to call them from within the Going Up and Going down Subroutines at the time that the door needs to close or open, not from the Main Lad 2 file. Otherwise you would have to add even more subroutines such as Open Door Going Up, Open Door Going Down, Close Door Going Up, and Close Door Going Down and that would get you back to the double-coil problem. An option would be to use a Flag or Step relay in the Going Up and Going Down subroutines, that in turn could be used to call the Door Open and Door Closed routines from the Main Lad 2 program.

EDIT: For a multi-floor elevator with multiple call buttons, you still would be better off using subroutines as in the LogixPro elevator problem.

I tested the last version of your RSLogix elevator logic using LogixPro, and it did work okay, using the timer DN bits to make sure some outputs were off before leaving the subroutine. Before I added those DN bits, and did not open and close the input sensors in the correct order, the Door Open or Door Close output could get left in the ON state, causing the program to lock up and the elevator to quit working.

 

[mitureg]

OK Lancie, almost there... I added the subroutines with CLOSE DOOR; and OPEN DOOR;

I also edited comments, added a few B3 relays and some RET just to make sure everything is clear.

Have a look,
Much appreciated.

Cheers

EDIT: I am not too sure if a "subroutine of a subroutine" returns to where it was called after it's execution. I assumed it does.

 

[daba]

EDIT: I am not too sure if a "subroutine of a subroutine" returns to where it was called after it's execution. I assumed it does.

You assumed correctly, execution continues at the point on the rung immediately after the subroutine call (JSR).

It does not continue at the start of the next rung as Rockwell documentation will have you believe.

 

[Lancie1]

I looked at your 6/26/2013 version briefly. I will try to enter it into LogixPro for a test. I don't expect it to work very well.

You allow the "focus" or PLC scan to jump out of the Close Door back to the Going Up, without any flag relay or RET condition to wait until the door is actually closed. That will allow the PLC to look at stuff that it shouldn't see and do, until the door is actually closed. Remember that the door will not close as soon as you energize the Door Open output. It will take some finite time, 3 or 4 seconds and several thousand PLC scans. During that time, what other mischief will the PLC get into?

This same applies to the Open Door subroutine. I think you need to add conditions in front of the RET in both Sub 5 and Sub 6. In Sub 5, prevent the RET until the door is closed. In Sub 6, prevent a RET until the door is open.

In addition to the above, you now have your door actions out-of-sequence.

Your instructions say (summarized): On Level 1, first close the door, go to Level 2, short pause, open the door, wait a short period, close door, wait until closed, then return to Level 1, short pause, then open the door.

OPTION 1:
The elevator is called from level 2 by the external call button IP0 being pressed. The elevator doors should then close via OP3, then once closed, IP5 (doors closed sensor) should energise. ...

Go back and read your instructions again, or go to the nearest elevator and watch how it works. Understanding the task is key to being able to solve it. I think your current "elevator" will go to Level 2 WITH THE DOOR OPEN, then try to close it! Let me know which building your elevator is going to be installed into, so I can be sure to use the stairs!

When using subroutines, organization and division of the tasks is important. Then you must strictly control WHEN each subroutine is activated and deactivated.

Looking at these subroutines, possibly you should go back to your 19062013 version. At least that one will work with the two subroutines. Is your goal to see how many subroutines you can use, or to get a working version? If the last, then you have had that already for a week or so.

 

[Lancie1]

I tested it with LogixPro, and made the fewest adjustments I could think of in order to make it work as organized into the 4 subroutines. It is still messy, but that is expected when you stuff 6 basic elevator steps into 4 subroutines.

 

[mitureg]

Hi Lancie, will have a look during the day...

What could be the 2 other subroutines that could be added given the actual I/O?

Check DOORS (open and close if obstruction, or alarm);
Check CAR POSITION (without simulation, possible?);

Cheers.

 

[mitureg]

It is still messy, but that is expected when you stuff 6 basic elevator steps into 4 subroutines.

My last post relates to this quote...
Cheers

 

[mitureg]

Is your goal to see how many subroutines you can use, or to get a working version?

My Goal is to get familiar with subroutines and learn other useful stuff along the way.

Cheers.

 

[Lancie1]

What could be the 2 other subroutines that could be added given the actual I/O?

By "actual I/O", do you mean the actual I/O for simulating a real elevator? If so, I can think of 3 or 4 functions that would be needed, such as First-Scan Initiallization (where you reset all outputs, flags, and timers to make sure that some did not get left on the last time the program ran, and then place the elevator at a starting position, such as the 1st floor), Catch Floor Requests (where you look at ALL floor pushbuttons and seal in the valid requests from either the Floor or the Car call buttons- which allows call buttons to be pressed and recorded EVEN WHEN the elevator is in motion from a previous request), Do Next Request (where your rung logic figures out the next floor to go to even if some requests call for going up and some call for going down), Track Car Movement (where you look at the elevator encoder value and determine when it reaches its next floor), Simulated Encoder (where you set up a timer and counter to simulate the movement of the elevator with a numeric value for the floor positions from 0 to 20 for a 2-floor elevator). If you want to learn useful stuff, then the above new subroutines should give you plenty of opportunities.

If you want to find the easiest solution given your exact student problem, then use one of the two working programs you already have.

For the alarm, you might should do an interlock on each subroutine RET, so that the RET cannot be activated until the alarm output is OFF. Otherwise, if some sneaky instructor held his finger on the alarm button while your program exited any of the subroutines, the alarm output would get left ON (unless you have an alarm output copy in the Main and ALL subroutines so that the alarm output immediatley gets evaluated again with the alarm button now OFF).

 

[mitureg]

By "actual I/O", do you mean the actual I/O for simulating a real elevator?

I mean the actual I/O that comes with this student elevator problem.

The list of inputs and outputs are as follows.

IP0 External Elevator call button
IP1 Elevator on level 2 sensor
IP2 Elevator on level 1 sensor
IP3 Internal Elevator button
IP4 Door obstruction sensor
IP5 Lift door closed sensor
IP6 Lift stuck alarm button

OP0 Elevator motor UP
OP1 Elevator motor DOWN
OP2 Elevator door motor OPEN
OP3 Elevator door motor CLOSE
OP4 Alarm