-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Documentation - add diagram "Architecture - Context diagram" #3781
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
Wrt spelling - I see PnCconf most often but would somewhat prefer PnCConf, StepConf. The Devs may also use command line variants as a HAL interface, which may also extend the GUI, so there could be lines drawn from the GUI (on the left) to the Text interface (also blue) on the right. Examples are linuxcncrsh or halcmd. For the sake of symmetry I would like to see that :-) |
I saw many variants. Here is my source:
|
|
Yes, like this. :-) Well done. I am uncertain about the semantics of dotted vs solid lines, and in analogy to the CNC machine operator, the arrows should be bidirectional. What I would also like to see is a longer caption of the image, like "The figure presents the components and players of the LinuxCNC ecosystem and how they interact. One a machine is set up, its operator will only use one of the many graphical user interfaces that LinuxCNC and external groups are providing. It is on an integrator to ensure that the LinuxCNC configuration matches the hardware setup both in the wiring and the protocols spoken on those wires. The LinuxCNC developers may be coming up with drivers for new hardware or other new features in the GUI and anything in between a mouse click and a motor turning. For testing, monitoring or possibly also the communication between multiple machines, also a text-based interface to LinuxCNC is available." |
|
Solid lines - signals and components MUST be used for using LCNC
Tell me which specific arrows you think should be bidirectional? I tried to give it logic. For example, unidirectional from INI to GUI has no feedback from GUI to INI. Developer sends codes to Github, but Github does not send codes to Developer. Wizards make configurations, but Wizard cannot read those configurations. ..... Thanks for text for manual I will use it. |
I suggest to add this description of the lines' semantics to the caption.
The interaction between the user interfaces and the core runtime should both be solid and bidirectional, I think. The interaction between the devs and the text interface is optional, indeed, but in analogy to using the GUI it is bidirectional. |
I will make it.
I dont understand. I dont have any "user interface" box.
I will change it. |
For me the GUI (graphical user interface) and the terminal/textual user interface are functionally equivalent. Just that the text-based one can be configured to run at the very same time as the graphical one. That is why I think that the lines to/from the blue UI-representing boxes should be of the same kind. |
|
I'd suggest you work hard to make it top down rather then spaghetti. Control panel ui/gui But to be frank I can't decide what information are you trying to get across? If you need a chapter of text to follow the diagram something is wrong. |
|
I know it may seem I'm being negative on your work. |
|
To Chris:
The only meaning of this diagram is to show how developers, integrators and operators are involved in the project. That's all.
We have 3 main "player" => developers, integrators and operators. That is why I use spaghetti.
I appreciate any feedback. If you have any more questions, don't hesitate to ask. |
|
"top-bottom" I think meant that the roles of users (all three of them) would be nice to see at the upper part of the diagram. But I think this is already the case - the integrator just cares more about the lower levels that are closer to the hardware. I think I would have the roles as white lengthy boxes on the very right, bottom and left. But then again - you can spend your time only once and for me it is fine as a start. The purpose of this top-level view I think is to let readers become familiar with these kinds of diagrams and to present some terms early in a very easy way. The more interesting (to me) diagrams I am hoping to see later :-) |
I am working on C3 diagram here, but my knowledge (LCNC motion) is not enough for finish yet.
|
|
I guess - not ultimately confident that it is to be preferred, though :-) I consider it a non-issue for now. The HAL bits may be trickier. Like, you have not mentioned HAL as a whole anywhere. |
No (my opinion). Your drawing shows a general diagram of some CNC control system. I want to make a diagram that will explain to a beginner why LCNC is amazing and unique. The first amazing thing about LCNC is that LCNC can be configured manually using INI + HAL files, but also using a Wizard. The important thing that LCNC has is that the core LCNC communicates with HAL. A beginner will not know what HAL is. He will have to study it. When a beginner looks at your picture, he will find out that the motor is controlled by physic IO. He will think that LCNC cannot control EtherCAT drivers. For example. You are right that Developers maintain all the code. But I wanted to point out only the components that require developer skills. It is amazing that LCNC has the role of an integrator who does not have to have developer skills, but is able to configure LCNC for many many CNC machines. I often communicate with people who know that LCNC exists, they know that it is amazing. That is all the information they have. They ask me if it is suitable for them, if they can use it, if they can integrate it. |
|
And I do not mind to explicitly read this selling proposition in the documentation, maybe next to the image. |
I dont understand what do you mean. My english is bad. What do you mean "selling proposition"? |
Your description why LinuxCNC is special. |





More information: #3738