search

withaspirit / Elevator-Simulation

Elevator System Simulation project
1 stars 1 forks source link

Trigger Door Faults via GUI #223

Closed julian-carleton closed 2 years ago

julian-carleton commented 2 years ago

Included Fault Injection using separate GUI with push buttons.

withaspirit commented 2 years ago

With #236, we can use the button to set the doorsMalfunctioning variable to true. If we send an ElevatorMonitor update after that, we'll be able to see the Door in the stuck state in the GUI

julian-carleton commented 2 years ago

With #236, we can use the button to set the doorsMalfunctioning variable to true. If we send an ElevatorMonitor update after that, we'll be able to see the Door in the stuck state in the GUI

Shoot! I just saw this message.

julian-carleton commented 2 years ago

Liam, I think the handling that I had was better. So that instead of locking the cart in the same floor waiting for the fault to disappear, it just leaves the door open and continues it's operation. This was the handlind that the TA mentioned in our last meeting.

withaspirit commented 2 years ago

I'm not sure what you mean. When the elevator is trying to open or close its doors, it shouldn't proceed until the fault is dealt with. The way I put it also allows the elevator to proceed as needed until it tries to open or close its doors again. I believe that's what I changed it to.

julian-carleton commented 2 years ago

No, so she mentioned that even if the fault persists, the elevator should be able to continue fulfilling the requests, just that with the doors opened.

withaspirit commented 2 years ago

The way I put it, is that the fault is disabled (set to NONE) after the fault is dealt with. That way, the elevator is able to keep fulfilling the requests. Also I don't think she meant for the Elevator to be moving with the doors opened.

julian-carleton commented 2 years ago

I still believe that it's better to leave the fault flag on, as the fault is still occurring so it's misleading to just clear it. And yes, I'm pretty sure that she meant that the doors remained opened while still in operation, because I challenged that to her and she still insisted.

withaspirit commented 2 years ago

I don't see how it's misleading. I believe the point of a transient fault is that once the fault has been dealt with, it's no longer occurring.

I believe there's a misunderstanding of what's going on, so I will clarify. When a fault button is pressed, the fault flag (doorsMalfunctioning) is set to true and the doors state is set to STUCK, but the fault property (fault) is not updated until the elevator attempts to open or close its doors. It should not read the fault flag until it tries to open or close its doors. Once it tries to open or close its doors, it sees that the fault flag is false, updates the fault field with DOORS_STUCK, and sets the fault flag to false. That is when the fault property appears in the GUI. The elevator tries to open or close its doors again, and it should do so successfully unless the fault flag has been triggered again. When it tries to open or close its doors again, its sets the fault property to NONE, and opens or closes its doors depending on the provided state in the changeDoorsState method.

(Identical for doors closing) (it shows that the doors state is set to STUCK if there's a malfunction, but that should have already occurred. It's shown here because there's no way yet of illustrating a button press in the State Machine Diagram) image

julian-carleton commented 2 years ago

Ok, I understand what you mean. But then the implementation is wrong, because unclicking the button triggers a malfunction again, which is not handled in your logic (I think).

julian-carleton commented 2 years ago

The way, I had it, is that if the button is pressed (activated) the fault is present, so it shows in the status of the system. And it's handled by leaving the doors opened. And when it's deactivated, it goes back to closing and opening the doors as normal.

withaspirit commented 2 years ago

That would require the Elevator to be updating the button, which we don't have time for. The button could instead be unselected in the actionPerformed method.

julian-carleton commented 2 years ago

Nope, it already works like that. Try testing it out.

withaspirit commented 2 years ago

If you read #236, you will know that the fault is shown by the door being STUCK in the GUI. The Fault state (i.e. FAULT enum) should not be present when the button is pressed because an Elevator Stuck fault could occur while the DoorsStuck fault is occurring, overriding the display of the DoorStuck fault. The Doors.STATE.STUCK is a far better indicator of the door stuck fault than Fault.DOOR_STUCK, which is why it was eliminated.

julian-carleton commented 2 years ago

I'm fine with Fault.DOOR_STUCK overriding DoorStuck since it's a hard fault over a soft fault, to me that's closer to the requirements. However, if you want to leave it as you have it, the unclicking of the button needs to be handled differently. Can you do that? I don't think I know how to.