Egalware/webdoorcreator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update descrizione

Browse Source
This commit is contained in:
Samuele E. Locatelli (MBA)
2022-11-09 21:55:25 +01:00
parent 6f2cdbe4b5
commit 771de55740
1 changed files with 37 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Docs/General Architecture.md
+37 -10
View File
@@ -11,11 +11,7 @@ In particular those are expectec use case
This document aims to represent detailed information about system actual internals and functional implementation and is passible of revision with the actual software production phases (requirements, general develop, alpha testing, beta testing, staging and go-live).
<!-- TOC -->
<!-- /TOC -->
<!-- TOC -->autoauto- [WebDoor Creator](#webdoor-creator)auto - [Overall Functional Schema](#overall-functional-schema)auto - [Terminology](#terminology)auto - [(A) Public WebServer](#a-public-webserver)auto - [(B.1) Internal WebDoor Server](#b1-internal-webdoor-server)auto - [(B.2) Redis Server](#b2-redis-server)auto - [(B.3) Main DB](#b3-main-db)auto - [(B.4) EgwDoor Processor](#b4-egwdoor-processor)auto - [EgwProd (Multiax Machine)](#egwprod-multiax-machine)auto - [Hw specifications](#hw-specifications)auto - [Expected Use cases](#expected-use-cases)auto - [User registration / login](#user-registration--login)auto - [Document Revision](#document-revision)autoauto<!-- /TOC -->
<div style="page-break-after: always; visibility: hidden"></div>
@@ -41,7 +37,7 @@ Here a general introduction to terminology used for each component of the projec
| ERP | WorkFlow needs to be defined |
| EgwProd | Local APplication onc Multiax Machine for production execution |
| ProdCode | Generic unique code (with barcode/QRCode/DataMatrix) to be used from remote Machine to scan and execute automatic production |
| ...| ... |
| DDF | **Door Definition Format**, the base data-format to describe Doors (measures, attributes, hardware, ...) in order to generate CAD/CAM/3D/ISO program and each format requested for the solution |
@@ -111,6 +107,19 @@ The REDIS server vill act as a cache / high speed data layer for example for man
It is a RAM based server and must be kept secure in the "green zone" of the customer IT datacenter.
@startuml PERT
left to right direction
' Horizontal lines: -->, <--, <-->
' Vertical lines: ->, <-, <->
title WebDoorCreator: Internal WebDoor Server
collections REDIS as B.2
queue "EgwDoor Proc" AS B.4
[B.2] <-> [WebDoor Instance] : Session/Comm
[B.4] <--> [B.2]: RT Channel subscriptions
@enduml
## (B.3) Main DB
@@ -120,12 +129,22 @@ The Main DB server will be, as a first choice (and if not otherwise requested by
## (B.4) EgwDoor Processor
This component, based on **EgtCAM5** Kernel and libraries, is the main core of CAD/CAM/3D task execution.
This will be linked (with bot REST webservices + REDIS channels/cache) to the (B.1) WebDoor Server.
In particulare the WebDoor will send DDF online-generated file (derived from user -input via web-interface) to the EgwDoor Processor. This processor will generate in (near) realtime various output format upon request (base geomtry, 3D web based artifacts, simulated ISO path for CAM calculation, ...).
The produced 3D (javascript based) web artifacts will be presented to the user in order to evaluate the finale expected product during web-based door definition wizard.
<div style="page-break-after: always; visibility: hidden"></div>
## EgwProd (Multiax Machine)
For each Multiax machine put in place, there will be a local copy of the standard EgwProd software (enabled to read barcode/qrcode/datamatrix data) and a copy of DoorCreator software (enabling realtime part program generation based on DDF final-product specification with respect on current tools and unique machine setup).
The software, after recognizing the unique code for each signle door, will be able to call (B.1) WebDoor Server to receive DDF file corresponding to each unique door. A backup solution (eg taking into account the case of network connectivity problems/disconnection) can be put in place in the form of distribuited/replicated "approved DDF file storage" in order to replicate on each production facility the set of near term part production (to be defined in detail, for example next 2-7 days of scheduled production).
<div style="page-break-after: always; visibility: hidden"></div>
@@ -150,9 +169,17 @@ special notes:
<div style="page-break-after: always; visibility: hidden"></div>
## Expected Use cases
### User registration / login
### User registration / login
## Document Revision
| Date | Version | Note |
|------------|:-------:|-----------------:|
| 2022.11.09 | 0.2 | Draft completion |
| 2022.11.03 | 0.1 | Initial draft |
| Date | Edit | Version | Note |
|------------|---|:-------:|-----------------:|
| 2022.11.09 |S.E. Locatelli| 0.2 | Draft completion |
| 2022.11.03 |S.E. Locatelli| 0.1 | Initial draft |