Hackerspace News

Bestand:Msc-situation-code.png

🇳🇱 · MakerSpaceLeiden · Ference Nieuwkerk

Ference Nieuwkerk heeft Bestand:Msc-situation-code.png geüpload Nieuwe pagina A screenshot of what situations map to what descriptions

Machine Support Consoles

🇳🇱 · MakerSpaceLeiden · Tycho van den Heuvel

Message Scenarios ← Oudere versie Versie van 15 jul 2026 11:50 Regel 195: Regel 195: == Message Scenarios == == Message Scenarios == Workflow 1 - authorized user tags in to use the machine === Workflow 1 - authorized user tags in to use the machine === [[Bestand:MSC-Workflow-1-diagram.png|800px]] === Workflow 1 - authorized user tags in to use the machine === # User scans RFID-chip at authorization node # Authorization node makes a HTTP-GET request to CRM # Authorization node receives information it can use to decode that user is allowed to use machine & enables control node to have electricity (now machine is physically able to be turned on) # authorization node publishes to MQTT that the login event occurred along with the username & machine status # MSC backend listens to the authorization node on MQTT & hears that sth changed # MSC backend makes user interface refresh the page by using websockets # User interface/Frontend makes HTTP/GET-request to fetch updated page from backend # UI now displays similar home screen as initially before step 1) but now user is tagged in & username displayed on the page as well as machine status === Workflow 2 - Use startup checklist with sensor data as help === Workflow 1 - authorized user tags in to use the machine User scans RFID-chip at authorization node Authorization node makes a HTTP-GET request to CRM Authorization node receives information it can use to decode that user is allowed to use machine & enables control node to have electricity (now machine is physically able to be turned on) authorization node publishes to MQTT that the login event occurred along with the username & machine status MSC backend listens to the authorization node on MQTT & hears that sth changed MSC backend makes user interface refresh the page by using websockets User interface/Frontend makes HTTP/GET-request to fetch updated page from backend UI now displays similar home screen as initially before step 1) but now user is tagged in & username displayed on the page as well as machine status Workflow 2 - Use startup checklist with sensor data as help This workflow assumes workflow 1 has occurred before it. The checklists can also be used anonymously but since using machines like table saws requires tagging the authorization node with the RFID chip, it is most likely that users will be logged in since otherwise the steps cannot be completed alongside the checklist. This workflow assumes workflow 1 has occurred before it. The checklists can also be used anonymously but since using machines like table saws requires tagging the authorization node with the RFID chip, it is most likely that users will be logged in since otherwise the steps cannot be completed alongside the checklist. The workflow is almost the same for the shutdown checklist except that after this checklist a user has cleaned up and turned off the machine. fter the machine is off a time out occurs after a few seconds and the user is logged out. The workflow is almost the same for the shutdown checklist except that after this checklist a user has cleaned up and turned off the machine. fter the machine is off a time out occurs after a few seconds and the user is logged out. User opens start-up checklist on user interface # User opens start-up checklist on user interface UI sends an HTTP/GET request to the MSC-backend # UI sends an HTTP/GET request to the MSC-backend MSC-backend provides the UI with the page as a response to the HTTP/GET including current sensor data # MSC-backend provides the UI with the page as a response to the HTTP/GET including current sensor data User starts following the steps of checklist and turns on the machine correctly # User starts following the steps of checklist and turns on the machine correctly if a user changes sth that sensors are attached to that are used, the authorization node publishes this to MQTT # if a user changes sth that sensors are attached to that are used, the authorization node publishes this to MQTT Thus the MSC-Backend triggers a refresh of the checklist page to help the user by displaying current sensor status (e.g. machine on) # Thus the MSC-Backend triggers a refresh of the checklist page to help the user by displaying current sensor status (e.g. machine on) User submits the clicked checkboxes that they completed (but in this example at least 1 checkbox that is stored is not selected (for the sake of explaining)) # User submits the clicked checkboxes that they completed (but in this example at least 1 checkbox that is stored is not selected (for the sake of explaining)) HTTP/POST Request is made to the MSC-Backend to store specific checkboxes that were left unchecked, HTTP/GET made to return to the home page of the application # HTTP/POST Request is made to the MSC-Backend to store specific checkboxes that were left unchecked, HTTP/GET made to return to the home page of the application MSC-Backend if it received post request makes post request to the CRM to add the service log entry that was created (checklist log) and also responds with home-page to HTTP/GET # MSC-Backend if it received post request makes post request to the CRM to add the service log entry that was created (checklist log) and also responds with home-page to HTTP/GET User sees home page again and can use the successfully turned on machine for a project now # User sees home page again and can use the successfully turned on machine for a project now Workflow 2 - Use startup checklist with sensor data as help === Workflow 2 - Use startup checklist with sensor data as help === [[Bestand:MSC-Workflow-2.png|800px]] Workflow 4 - use static guide - no diagram === Workflow 4 - use static guide - no diagram === This workflow assumes workflow 1 has occurred before it. This may not be the case in some scenarios since it may be safer to maintain a machine without turning it on at first. Static guides are provided by the application irrelevant if a user is logged in or not. They simply display information. This workflow assumes workflow 1 has occurred before it. This may not be the case in some scenarios since it may be safer to maintain a machine without turning it on at first. Static guides are provided by the application irrelevant if a user is logged in or not. They simply display information. Static guides are maintenance guides & usage guides Static guides are maintenance guides & usage guides User opens maintenance or usage guide on user interface # User opens maintenance or usage guide on user interface UI sends an HTTP/GET request to the MSC-backend # UI sends an HTTP/GET request to the MSC-backend MSC-backend provides the UI with the page as a response to the HTTP/GET # MSC-backend provides the UI with the page as a response to the HTTP/GET User closes the guide again after reading it # User closes the guide again after reading it UI sends an HTTP/GET request to get the home page # UI sends an HTTP/GET request to get the home page MSC-backend provides the homepage # MSC-backend provides the homepage Workflow 5 - Create machine log entry - no diagram === Workflow 5 - Create machine log entry - no diagram === This example is similar to workflow 2 since checklist logs and machine logs are stored in the same way thus no diagram is provided. 2 examples of this workflow are take machine out of service or put a machine back in service but also reporting something e.g. a missing part This example is similar to workflow 2 since checklist logs and machine logs are stored in the same way thus no diagram is provided. 2 examples of this workflow are take machine out of service or put a machine back in service but also reporting something e.g. a missing part This workflow assumes workflow 1 has occurred before it. It is not necessary for a user to be logged in to the system to make a machine log but since to use a machine users need to be logged in for the machine to be able to be turned on, this will still often be the default. This workflow assumes workflow 1 has occurred before it. It is not necessary for a user to be logged in to the system to make a machine log but since to use a machine users need to be logged in for the machine to be able to be turned on, this will still often be the default. User opens machine logs in user interface # User opens machine logs in user interface UI sends HTTP/GET request for the page and MSC-backend provides the page # UI sends HTTP/GET request for the page and MSC-backend provides the page User creates a new machine log entry (UI makes HTTP/Post request to MSC backend) and HTTP/GET to get the home page # User creates a new machine log entry (UI makes HTTP/Post request to MSC backend) and HTTP/GET to get the home page MSC backend makes HTTP-Post request to CRM to store the machine log entry there and accurately reflect current state e.g. in/out of service # MSC backend makes HTTP-Post request to CRM to store the machine log entry there and accurately reflect current state e.g. in/out of service MSC provides UI with the home page which the user sees the reflected state on e.g. perhaps they took the machine out of service then the home page shows that now # MSC provides UI with the home page which the user sees the reflected state on e.g. perhaps they took the machine out of service then the home page shows that now Workflow 6 - Read machine log entries - no diagram === Workflow 6 - Read machine log entries - no diagram === This workflow assumes workflow 1 has occurred before it. But in principle it is not necessary for a user to be logged in to the system to read the log entries. This workflow assumes workflow 1 has occurred before it. But in principle it is not necessary for a user to be logged in to the system to read the log entries. User opens machine logs in user interface # User opens machine logs in user interface user reads machine logs and can click on read more to see a single entry in detail on the detail page: HTTP/GET is made to the corresponding page that displays this # user reads machine logs and can click on read more to see a single entry in detail on the detail page: HTTP/GET is made to the corresponding page that displays this MSC-Backend provides the UI with the detail page of the specific machine log that was clicked on # MSC-Backend provides the UI with the detail page of the specific machine log that was clicked on User can use the information they gained to debug the machine when brok # User can use the information they gained to debug the machine when broken == Logical data model == == Logical data model ==

Bestand:MSC-Workflow-1-diagram.png

🇳🇱 · MakerSpaceLeiden · Tycho van den Heuvel

Tycho van den Heuvel heeft Bestand:MSC-Workflow-1-diagram.png geüpload Nieuwe pagina A diagram of the workflow how users interact with different components and the components with each other

3d printer onderhoud

🇳🇱 · MakerSpaceLeiden · LucasV

← Oudere versie Versie van 15 jul 2026 09:54 Regel 59: Regel 59: | | |} |} = Handige test-modelletjes = * [[https://www.printables.com/model/548819-fast-edge-overunder-extrusion-test Over/under extrusion test ]] * Vul gerust aan! (Bridging? Retraction?) = Ultimaker fans = = Ultimaker fans =

Other

Bestand:Msc-situation-code.png

Machine Support Consoles

Bestand:MSC-Workflow-1-diagram.png

3d printer onderhoud

Machine Support Consoles

Bestand:MSC-Workflow-2.png

Bestand:Logical-data-model.png

Bestand:MSC-User-workflows.png

Bestand:MSC-Workflow-1-diagram.png

Machine Support Consoles