Hello everyone, im currently in the middle of a project. We have to make an intelligent elevator with two cab that will choose respond in a intelligent way.
So far we've done this : the elevator's structure, with two cabs, 10 leds for each column. 10 call buttons for each cabs and 10 buttons for outside of the cabs. We have programmed the elevator but so far it can only respond to one call at a time, i dont know how to store multiple call and then having the elevator to answer them (once this is done i will try do research intelligent algorithm)
You could store 10 "button has been pressed" states in a bool array with 10 elements. Maybe you would have 4 arrays, one for each of: cab 1 internal buttons, cab 2 internal buttons, cab 1 external buttons, cab 2 external buttons.
After answering one call, look through the appropriate arrays and pick the next one to answer.
That will determine which call to pick to answer next when you are looking through the arrays
Will it be up collective or down collective at specific times of day? Will it have express mode again at different times of the day. If simulation is for very tall buildings, sometimes a return to middle mode is used.
Of course 50% or more of the circuitry is devoted to safety for a real elevator.
For a minimalistic version you need to use an array of boolean to hold the information if for a certain level a button is pressed.
bool buttonPressed[10];
initially these are to be set to false. If a button is pressed you make it true.
Then you only need to go through that array to see where to go.
The trick is to handle them all.
In an alternative version you use an array of timestamps.
uint32_t buttonPressed[10];
default set to zero, and if a button is pressed you check if there is a timestamp set for that level, if not set it to the current millis.
Then you search for the level with the oldest timestamp and go to it.
When arriving at that level reset the array element to zero again.
This way it is sure you handle all request.
Still there are ways to optimize this strategy.
(best way to learn is to ride an actual lift and see how it behaves in detail,
I know, I was trying to not scare him off.
If it isn't obvious a spent a short time in the elevator business, my friend did maintenance work and I often accompanied him. Lots of stories from standing on top of the cars and listening and occasionally seeing what folks get up to inside.
I suspect what their teacher was doing was using a (poor) example of one arduino controlling multiple 'things'. The choice of an elevator was poor in that in real life the vast majority of the electro-mechanical system is devoted to human safety.
A full simulation of the entire system would be a good graduate project especially since modern elevators use MCUs and MPUs. Becomes a bit meta real quick.
The elevator projects on The Forum that made it to the build stage were involved. Multi-floor, multi-call, arrival light/bell, door open, floor choice, door close, going-up/down indicator, stepper motors, servos, LEDs, OLEDs, buzzers, buttons. I can't find any that went beyond an idea with the search tool, but they exist (or existed if this is the age of purging at two years dormancy).
Most die on the vine.
Is this English?
I think @DaveX did a wokwi sim of multi-function elevator.
I don't think it was me & don't see mention of elevator in my Wokwi stuff. ISTR doing something like that that back in the 80s in a controls lab with a PLC.
Not me. Good thing too, because if it were, it would mean looking for the thing amongst the trash pile of wokwi simulations I have created or modified for these fora. I try to throw them away, but have been lazy, as well as reluctant to throw away something that's been linked here. Which is why I also try to post at least the code.
I do tanks and pumps as well as heating and cooling, neither perhaps conceptually that good as an analog elevator.
@arduinoelevator - usually there is an "up" button and a "down" button on each floor. This would be useful information when planning optimal operations.
@alto777’s suggestion makes this easier. Just storing the button-called state for each up and down button automatically stores that information for you. The lights on the elevator buttons are all there for more than informing the users that the elevator is on the way—they are integral to the planning: If you are going down and reach a floor with a lit down button, stop and service it.
You need to plan ahead for adaptability (state machines, non-blocking, millis() not delay), because adding in intelligence to a some bare minimum code will be difficult.
I have been using wokwi without logging-on to keep my account "clean" (ahahhhaha!). Wokwi allows me to store in-work sims with a URL and title when I am NOT logged-in. I can access the sim with the URL, but I can't edit the sim once I exit wokwi, and there is no "dashboard/projects". With these temporary sims, I post the sketch.ino and diagram.json on the forum using the <details> markup. For example, this is a "new" minimal sketch/sim that I now can not edit because my cookies are cleared when I exit my browser, but there is no author: minimal - Wokwi ESP32, STM32, Arduino Simulator
Warning: logging-off wokwi makes you log-in using email... so if you can not access your email, you are locked out of your wokwi account.
A 10 floor, 2 car elevator with the normal set of lights and buttons is a lot of IO: at least 40 leds+40 buttons, and that's before touching doors and motors.
