PLC Self-Extrication Mode

[RickL]

in prima facie

I'm in the early stages of laying out the design logic tree and required protocols for a dedicated "self-extrication" elevator PLC unit. 

This is companion project to my PLC based primary elevator controller. 

The normally idle,  stand alone, self-extrication PLC is will be in "hot-standby" mode with battery back-up operation. I'll need to establish a communication link between these two PLCs. 

I'll need more than just a "heart beat" failure indication of the main PLC controller, thinking to possibly emulate a "catch/throw" error paradigm with-in the main controller to the cause of the controller/peripheral  failure.  Here the extrication PLC  would weigh the best course of action.

 

 

 

 

[John_R]

Oh My...

And I know this is gonna send me to "forum purgatory",  but WTF are you talking about?

You keep delving into control logic that is outside the realm of typical PLC control.

This is why elevator manufacturers have dedicated (certified) controllers for these applications.

And why hack programmers (with any common sense) should steer clear of these projects (unless they have a big pocketbook to back up the liabilities involved).

👿

[RickL]

 

Hi John_R!        :  )

Thank-you for your welcomed input!

"And I know this is gonna send me to "forum purgatory",  but WTF are you talking about?"

I've been involved in the hotel/motel industry for many of years now. It has afforded me a great span of design challenges across many technical fields (HAVC, plumbing, electrical, EPABX phone systems, data networks, commercial washer/dryers, swimming pool filtration/de-humidification, etc ... and so much more!) 

This project is to address the motel guests being "trapped in the elevator" scenario.  This is often a terrible  experience for the guests and long waits for fire department rescue (extrication)......  when your "trapped" ....... minutes  seem to be hours!

The PLC is to be coded to access the nature of the fault, execute its plan to slowly step elevator  down to appropriate floor for release.

"Self-Extrication" PLC

[RickL]

 

"You keep delving into control logic that is outside the realm of typical PLC control"  - John_R

John,

They landed a spacecraft on the moon with little more than an Altair 8800 running a few kalman filters, what makes you think a  PLC can't control an hydraulic elevator?  .... that its "out-of-the-realm" of such control?

 

...........  from "Computer Lib" / "Dream Machines"

 

[Gabriel Franco]

I would move to a brand (not Unitronics) that have redundant controllers (and I/Os).

 

[RickL]

1 hour ago, Gabriel Franco said:

"I would move to a brand (not Unitronics) that have redundant controllers (and I/Os)".

 

Hi Gabriel!

I was in Long Island for factory training on a massive EPABX  (Central Office Tecom System) and it had "twin" CPU units for full operational redundancy. You could smoke a complete processor board and the "hot" stand-by CPU kicks in and not even loose a call!

But, my thoughts to addressing elevator faults (controller or peripheral) is NOT to continue its operation but to suspend it!  .... until  maintenance personal  evaluates "on-site" the fault condition. 

Dropping a phone call is one thing .........  dropping grandmom four stories is different!     :  (  

 

Your thoughts?

Thank-you!

 

So, my line of thinking is one PLC main controller with a second  PLC to operate in "Cripple Mode" only! ..... just like the CPU in your car does when it looses full control.

[Fernando Castro]

21 hours ago, RickL said:

I'll need more than just a "heart beat" failure indication of the main PLC controller, thinking to possibly emulate a "catch/throw" error paradigm with-in the main controller to the cause of the controller/peripheral  failure.  Here the extrication PLC  would weigh the best course of action.

Oh, we all agree on that. you need more than that:

the SIL assessment, the required performance level (PLr), the category of the SRP/CS, measures against CCF on multi-channel systems, the component MTTFd , and the average test quality of components.

But sorry I can't help you, has been a while since I took the "Functional safety in machine automation and risk assessment" training. I don't feel qualified enough to give advice on how to design the control system.

 

[RickL]

1 hour ago, Fernando Castro said:

Oh, we all agree on that. you need more than that:

the SIL assessment, the required performance level (PLr), the category of the SRP/CS, measures against CCF on multi-channel systems, the component MTTFd , and the average test quality of components.

But sorry I can't help you, has been a while since I took the "Functional safety in machine automation and risk assessment" training. I don't feel qualified enough to give advice on how to design the control system.

 

Thank -you Fernando!

Well aware of all that already!  Thanks! 

I've been working with a board member on  the ICC (lives 15 mins from me!) on my "invisible" ADA platform lift already. They are really receptive and supportive to new or mods to what's out there.

My primary desire right now is to prototype a working "proof of concept" machine.

[John_R]

12 hours ago, RickL said:

They landed a spacecraft on the moon with little more than an Altair 8800 running a few kalman filters, what makes you think a  PLC can't control an hydraulic elevator?  .... that its "out-of-the-realm" of such control?

So... here comes some more of my innate sarcasm... it was not an Altair 8800, but the original Atari 2600 that led us there.

So you are one of those people who think that the moon landing in 69 with Neil Armstrong and Buzz Aldrin was real?

Naw, that was all staged in the in the deserts of Arizona..

I was 12 years old, and my summer school teacher, Sister Mary Vagina gathered us all to the assembly hall to watch this hoax on TV...

Anyway, my point was not that a PLC is not capable of controlling an elevator, or some sort of extrication sub-routine, but merely that such operations need to be well documented and certified. also you state that your extrication protocol would "bring the elevator down to the next floor". In my childish mind, the elevator would have some sort of ratcheting pawl system (much like a roller coaster going up the first hill, click, click, click, if something should happen it holds you there), so I would take the disabled elevator UP to the next floor, going DOWN means you have to release said safety device and risk the elevator free falling to the bottom.

Again, Just because you can, doesn't mean you should....

Just my opinion....

16 hours ago, RickL said:

I've been involved in the hotel/motel industry for many of years now. It has afforded me a great span of design challenges across many technical fields (HAVC, plumbing, electrical, EPABX phone systems, data networks, commercial washer/dryers, swimming pool filtration/de-humidification, etc ... and so much more!) 

So, you are just a Hotel Handyman? And I suppose your Uncle Roy-Bob owns the joint, and has promised you a healthy bonus if you can find a way to circumvent the high-priced repairs needed to keep his hotel afloat??

How's that for sarcasm??   Learn it, Know it, Live it....🤓

JohnR

[RickL]

.............  Res ipsa loquitur!

 

 

[RickL]

 

"You keep delving into control logic that is outside the realm of typical PLC control"  - John_R

                                                

"Anyway, my point was not that a PLC is not capable of controlling an elevator, or some sort of extrication sub-routine, but merely that such operations need to be well documented and certified. "  John_R

 

.................  John,   you  (in your own words, as shown above)  attempt to retract and modify your own statements when caught!

You will never sell that "stuff" to me or any one else on here!

[RickL]

 "In my childish mind ...... "  John_R  

Agreed!

No!  ...... that is something a child would conjure up indeed!

Basically,

The way it works is there is a DC "Micro motor" that bleeds the high pressure hydraulic fluid from the lift cylinder. It a "fail-safe" poppet valve that small steps the car down to the next floor.

[2n2907]

RickL,

To start this I just to let you know my background so you know were this is coming from.

I have been programming PLCs for 9 years. I started with Unitronics and have used other brands. I also have experience with microcontrollers and other small electronics. So these comments are things that I have had to learn the hard way on jobs.

 

So let's start from the requirement that was listed:

 

"The normally idle,  stand alone, self-extrication PLC is will be in "hot-standby" mode with battery back-up operation. I'll need to establish a communication link between these two PLCs. 

 

I'll need more than just a "heart beat" failure indication of the main PLC controller, thinking to possibly emulate a "catch/throw" error paradigm with-in the main controller to the cause of the controller/peripheral  failure.  Here the extrication PLC  would weigh the best course of action."

 

That is an outline of an idea. There is not enough information to start trying to figure out what your question is. What are you asking/looking for from this thread?

 

Starting with the elephant in the thread, what is the difference between this and a set of manual control overrides after the main PLC fails? 

 

Now to the talk about the outline as if it was a good idea that I would have to help work on :

 

The communication between the two PLCs is a big part of the scope that was not talked about in detail.

 

How will the two PLCs communicate?

   The hardware Layer?

   The protocol Layer?

 

Are you going to write your own protocol or use one the PLC supports?

Have you looked at the different protocols that the PLC supports and picked which one that you are looking at using?

 

What data do you want to move?

ML,MB,DW,MI,MF

 

When you say "catch/throw" is that from the C or java error handling?

In PLCs you can only send integers or coils directly between the two PLCs. (there can be ascii text stored in the integers)

What are you thinking of sending that the second PLC needs to know from the first?

Are you looking to make the main PLC send a error to the second PLC or talk all the time?

 

How fast is the send/receive rate between the two PLCs? 

 

 

After talking about PLC communication now is the extrication PLC Hardware:

Have you looked at what goes into amusement park rides for PLC and IO?

They are dual PLC Processors, dual PLC IO cards, dual field sensors and dual outputs.

If your first thought is that an elevator is not that complicated as the ride, then as my PLC teacher hammered into me "The devil is in the details. You have to think it through".

 

So what is the second PLC going to get the data from? 

   Will it have its own PLC Inputs?

   Will it have safety rated inputs?

   Will it have its own secondary sensors? 

   Will it have its own Position Sensor? 

   Will it have its own outputs?

   Will it have override outputs to block the main PLC?

What keeps the second PLC from going bad?

Are the two different PLCs in the same cabinet? 

Do they have independent 24V power supplies? 

Are there sensors and IO from a different power supply?

Will it be connected to the fire alarm?

What to do for every different error that can happen?

How to display the errors when they do not agree?

Who will win between the two controllers?

 

The error checking:

The scariest thing that a customer can say to me is "Just have the PLC figure it out what is right". There is a ton of work going into error checking and knowing what is right to the process. 

Just to know if there is an error is hard even with two sensors, what sensor is right and what sensor is wrong.

Again who will win between the two controllers?

 

I can count on one hand the number of times the PLC stopped working on a machine that was not damaged by the operators or it's environment. The PLC hardware error that you are looking to fix will be small.

 

There is a lot of thought that has to go into what the error state is going to do..

How will this be displayed to the end user, staff? 

What advantage will there be over a set of manual controls? 

What about equipment failure for non PLC parts? 

What about Fire Service?

The posted description is confusing:

"hot-standby" 

"extrication PLC  would weigh the best course of action"

 

So the second PLC will not drive the elevator but to the safety floor, then it is more of a watchdog PLC not a hot-standby. 

 

If you think that I am trying to be dismissive just think what you have given in details in the topic.  This is what I would ask the customer if I was trying to make this work for real.

 

The simplest part of the project is getting the two PLCs to talk, the hard part is what to say. If you think that they are both simple and I am wrong then I go ahead and ignore what I had to say.

Have you looked at the enclouded example programs? They are a great way to learn about and see how the functions work. They may be on other PLCs but I have used them in the past to see how to make communication work.

 

The pump program you  are working on is a good way to start learning about PLCs. There is a place to get your hands dirty and just see what you  can do. 

If you are looking for someone to post a program for communication between two PLCs with error checking to help you getting started, then you should consider that this project is beyond the scope of what you can handle.  The people with knowledge gained by programming for years have suggested that this is beyond what a person's third project should be.  This is not gatekeeping, this is explaining what we have learned from our experience in programing. 

 

I know that by saying that you are going to take that as a challenge. That I can not help, I am just trying to give an objective answer to what you have posted.

 

When the other people on the forum are saying this is "outside the realm of typical PLC control" is because there are controllers that are specially built for the job.  They have been tested and are known to work and have been certified.  Anything with a dedicated controller can be run by a PLC, but would you want to use a sledgehammer to crack a walnut? 

 

As much as I enjoy talking about feeding mayonnaise to live tuna fish, there are some things that would be better spent programming time on.

[John_R]

2N2907, or can I call you PNP for short?

Seems you are a "long time listener, first time caller"....

I admire your tenacity to give such a long-winded response to this over-beaten topic, and like what you have to say...

but I have resolved to refrain from any further comment to the OP...

Welcome aboard.

JohnR

[RickL]

Hello 2N2907 !

Welcome to the PLC HELP Forum!

I look forward to explore with you your new ideas, projects your working on, technical questions, ect!

 

(I just walk in the door and saw your extensive list of questions,  let me get a glass of wine going, return a few phone calls, etc and I'll start popping the replies back to you shortly!)

While your waiting,  

I'm curious, You've been a member since 2013 (10 years ago)  ...... in all that time you've never posted anything???    :  (

I must say I feel quite  honored, that something I had posted,  inspired you to post your thoughts for the very first time!!

Awesome!!  .........   what was the motivation for this?

 

[RickL]

"That is an outline of an idea. There is not enough information to start trying to figure out what your question is. What are you asking/looking for from this thread?" - 2N2907

Correct!    It lays only the foundation of inquiry  .......  the  discussions and questions follows after this!

"Starting with the elephant in the thread, what is the difference between this and a set of manual control overrides after the main PLC fails?"   - 2N2907 

A "manual extrication" requires someone to "manually" in person, perform the extrication. 

A "self- extricating" PLC would do this without human intervention.  

I hope you can "ACE" the distinction!       :  )

"Now to the talk about the outline as if it was a good idea that I would have to help work on :"  - 2N2907

You will severally cut yourself short in life and knowledge if you state your conclusions before you even hear out the rational offered thru discussion and  peer review.  Is this your "normal"  way of thinking of things??   :  (

"The communication between the two PLCs is a big part of the scope that was not talked about in detail."  - 2N2907

We've started!  (Look my conversations above with Gabriel Franco and Fernando Castro)

....... your the  third  competent inquisitor to date!    I welcome your intelectual inquisition!   :  )

"How will the two PLCs communicate?

   The hardware Layer?

   The protocol Layer?

 

Are you going to write your own protocol or use one the PLC supports?

Have you looked at the different protocols that the PLC supports and picked which one that you are looking at using?

 

What data do you want to move?

ML,MB,DW,MI,MF

 

When you say "catch/throw" is that from the C or java error handling?

In PLCs you can only send integers or coils directly between the two PLCs. (there can be ascii text stored in the integers)

What are you thinking of sending that the second PLC needs to know from the first?

Are you looking to make the main PLC send a error to the second PLC or talk all the time?

 

How fast is the send/receive rate between the two PLCs?"   - 2N2907

These are all great and valid questions you pose!!  Thank-you!  ......  but the problem is .....  they were all  authored by you only! If you were to have had me in the "build" phase of  your questions, many of them you would have seen would not have even existed!

I'm in the early phase of concept  design and development only.  My proposed foundation is a two PLC solution.  One handling the normal elevator operations and the other functioning in "crippled" mode or "extrication" PLC. 

In re: "throw/catch" paradigm , I propose to emulate a "fuzzy logic" error handling for the cripple mode PLC to assess the best course of "extrication" available to it. (ie: in one failure scenario, lowering the elevator down to the next floor may be appropriate, but if the failure was from an indicated "shaft door not closed and locked" an alternate plan of extrication would be invoked.)

"So the second PLC will not drive the elevator but to the safety floor, then it is more of a watchdog PLC not a hot-standby." - 2N2907 

Correct!   ........ but as I just stated above, much more than just a "watchdog PLC"  but a decision making PLC (AI?) PLC.

"If you are looking for someone to post a program for communication between two PLCs with error checking to help you getting started, then you should consider that this project is beyond the scope of what you can handle." - 2N2907

LMAO !!!!!!!    :  )

NO!   :  )      .... I can handle it well I assure you!    LMAO !!!!!   :   )    You must be very young!    

"The people with knowledge gained by programming for years have suggested that this is beyond what a person's third project should be.  This is not gatekeeping, this is explaining what we have learned from our experience in programing." - 2N2907

LMAO !!!!!!!!!!!!!     Who are these "people" ??  you know them I take it?   quote or show cause their supporting facts that you your self hold true to please.   (I 'll be waiting for this one! )   :  ) 

"When the other people on the forum are saying this is "outside the realm of typical PLC control" is because there are controllers that are specially built for the job.  They have been tested and are known to work and have been certified".  - 2N2907

What Nonsense!!!    

 My PLC is controlling an elevator, it was not "specially built" to control an elevator!  yet it does it very well!  

..... actually, the PLC itself doesn't know if im controlling an elevator or feeding chickens! .... it doesnt care!  It can easily do both!

 

Thank-you for your post !   

..... your thoughts?

 

 

 

 

 

 

 

 

 

 

[RickL]

...... cont.   (sorry!  missed some of your statements and assertions)

"So these comments are things that I have had to learn the hard way on jobs".  - 2N2907

Are your trying to validate  your "comments" here by offering the supporting fact you had a "hard work experience" ?? 

Well,    ..... I never worked "hard" in my work!  I've always have worked "easy"!     Since the time of the cavemen, some smart guy thought up the idea to make a wheel to carry home the buffalo  ..... he "worked easy"   :  )

You,  in this day and age of incredible machines and technology that make our work days so easy ...... have toiled "hard" in your lifetime of work?  ....   I would say you missed the boat here!  Working "hard" to me is someone who lacks insight and creativity to an "easy" way of intelligent life style.