You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is an anchor issue for information which should not have to be explained by the Machinekit project, but is meaningful to know about.
Following the discussion in this PR #216 as well as the points #117 and #103 I think we should define what we expect people to know when they start with Machinekit.
If we only say "this is not a linux course" then we'll never get traction in for example a more industrialised/manufacturing setting, where practically everything that engineers/service people do runs on Windows. And it is this environment which is so suited for Machinekit.
I think we should point to sources that are suited to read up to first, before getting into the cold and murky water (from a non-linux perspective).
After all, if we want to have a re-usable realtime motion system, there need to be users, and hopefully this project continues to grow.
[1]
We have the "user" who just wants to set up a machine. This can be a standard machine, like mill-xyz or 3D-printer-type-a. These users have certain hardware and a certain machine, so they will typically need to choose and start with a config, and change things like homing parameters, speeds etc. But also there needs to be able to use haltalk, when a remote GUI is needed.
[2]
There's a "user" who will want to make a custom hal configuration because of a custom (mechanical/electronical) hardware design. Meaning understanding of HAL components, netting etc. is needed. Building a HAL configuration from scratch. Do we think these people will want to use the python bindings to do so? These people will probably want to make custom UI's.
[3]
When [1] and [2] are not enough, and one of these users needs things that are available, this means programming. Writing components, etc
[4]
Programmers
What should be the prerequisits/tips so that we can point to and don't have to explain "scp" or "git" or "dmesg" but instead can point to other sources that will explain what's going on when that command is invoked.
Please add to this thread.
The text was updated successfully, but these errors were encountered:
This is an anchor issue for information which should not have to be explained by the Machinekit project, but is meaningful to know about.
Following the discussion in this PR #216 as well as the points #117 and #103 I think we should define what we expect people to know when they start with Machinekit.
If we only say "this is not a linux course" then we'll never get traction in for example a more industrialised/manufacturing setting, where practically everything that engineers/service people do runs on Windows. And it is this environment which is so suited for Machinekit.
I think we should point to sources that are suited to read up to first, before getting into the cold and murky water (from a non-linux perspective).
After all, if we want to have a re-usable realtime motion system, there need to be users, and hopefully this project continues to grow.
[1]
We have the "user" who just wants to set up a machine. This can be a standard machine, like mill-xyz or 3D-printer-type-a. These users have certain hardware and a certain machine, so they will typically need to choose and start with a config, and change things like homing parameters, speeds etc. But also there needs to be able to use haltalk, when a remote GUI is needed.
[2]
There's a "user" who will want to make a custom hal configuration because of a custom (mechanical/electronical) hardware design. Meaning understanding of HAL components, netting etc. is needed. Building a HAL configuration from scratch. Do we think these people will want to use the python bindings to do so? These people will probably want to make custom UI's.
[3]
When [1] and [2] are not enough, and one of these users needs things that are available, this means programming. Writing components, etc
[4]
Programmers
What should be the prerequisits/tips so that we can point to and don't have to explain "scp" or "git" or "dmesg" but instead can point to other sources that will explain what's going on when that command is invoked.
Please add to this thread.
The text was updated successfully, but these errors were encountered: