Concerns of new aspiring LinuxCNC users that the home page should address

[smoe]

Sorry for stealing all your time with this. I hope this is somehow returned by new contributors who find LinuxCNC because of these changes. If I do not write this down now then I will have forgotten about all the questions I had :)

Suggestions:

• Adoption of the longer description by @andypugh in Update control.top.in linuxcnc#1288 (comment), but I do not know what it should substitute or if this is just a new section.
• Multiple graphics
  a) schematic overview of different components/modules of LinuxCNC and preferably some mouse-over explaining details and providing links to the documentation/Wiki - I like what https://www.machinekit.io/ has come up with - as a basis of a discussion
  b) steps to go for installing your own machine
  c) ...?
• Anti-FUD:
  • A series of nice YouTube videos that praise LinuxCNC
  • Show that the control panels are nice and that they can be modified
  • Reference small software companies or freelancers that would be available to help
• Explain
  • why real-time interaction is important
    • parallel port
    • mesa cards
      • PCI
      • Ethernet - why does this work with the extra latency
    • USB and machinekit.io
  • how to get towards working setups
    • you do not need any hardware to contribute because you can run FreeCAD to generate the G-code and monitor what happens - pointer to tutorial would be nice
    • Examples for minimal DIY kit that can be controlled with LinuxCNC
    • Examples for retrofits
    • Examples for what is minimally required for what precision with what dimensions
• List of ongoing projects (maybe even organize these in github (https://github.com/LinuxCNC/linuxcnc/projects)
• Series of small projects for noobs to ask to be mentored for. This would help attracting new users and also prepare for the next Google Summer of Code.

As always, you know more than me about your project. Please point me to something incremental you would like to see the first PR for.

[SebKuzminsky]

We could definitely do a better job documenting what we are and what we are not... We have some old but still mostly accurate architecture docs hidden here:

• http://linuxcnc.org/docs/2.8/html/code/code-notes.html#_architecture_overview
• http://linuxcnc.org/docs/2.8/html/code/code-notes.html#_motion_controller_introduction

The wording there predates our current "realtime in userspace" work, so it talks about "realtime" and "kernel" as synonyms, and "non-realtime" and "userspace" as synonyms. This was accurate back when LinuxCNC ran only on RTAI (where all realtime code was in-kernel, and all non-realtime code was in userspace). But now LinuxCNC can use Preempt-RT for realtime (thanks to @jepler) and all those words need to change...

[smoe]

I had a look at those graphics and liked them. But it is not what should be on a home page. For the latter I think we need something that looks more like it was scribbled on the napkin and that explains the very, very basics while at the same time reminding every contributor why they are investing their time in this project. Sometimes you wish that Github could do what Google Docs can do wrt joint painting.

[smoe]

I eventually found the Wikipedia entry and like that, too: https://en.wikipedia.org/wiki/LinuxCNC

[andypugh]

I was answering a forum post and found this issue. Is it still live?

[smoe]

Hm. I just compared LinuxCNC.org with www.machinekit.io again and prefer the latter.

[silopolis]

Le lun. 26 sept. 2022 à 15:34, andypugh ***@***.***> a écrit :

I was answering a forum post and found this issue. Is it still live?

Live, like TODO ?

[andypugh]

Yes, it's still an open issue, so I was wondering what need to be done to close it.

[smoe]

That is a tough one. Such web pages you can sink all your energy in. And until we have decided for whom that web page is meant to be, we cannot do decide anything. Funnily enough, I have in the meantime answered most of above questions myself and am not sure that I would still want to be nagged with that info every time I open the LinuxCNC.org page - not that I look at it too often, anyway.

[smoe]

Not a better project start page, but some very persuasive eye candy: https://www.qtpyvcp.com/showcase/mill_vcps.html
I have only looked at some 60% of our documentation now - but we are not mentioning that effort anywhere, are we?

[silopolis]

Le mer. 12 oct. 2022 à 02:06, Steffen Möller ***@***.***> a écrit :

Not a better project start page, but some very persuasive eye candy: https://www.qtpyvcp.com/showcase/mill_vcps.html I have only looked at some 60% of our documentation now - but we are not mentioning that effort anywhere, are we?

Nope, sadly, like we don't mention the Remora project I believe. I hope this is more for historical reasons than anything else...

[andypugh]

I wonder where we could mention them? A section for "partner projects" maybe? (Possibly STMBL in there too, if this chip shortage ever ends)

[silopolis]

Le mer. 12 oct. 2022 à 14:10, andypugh ***@***.***> a écrit :

I wonder where we could mention them? A section for "partner projects" maybe? (Possibly STMBL in there too, if this chip shortage ever ends)

AFAIC, I hope we could pull them in ! Couldn't Remora be merged with LinuxCNC ? Are there technical issues for this ? Is this just a matter of personal choice/preference ? @scottalford75 would very much like your input about this please 🙏 Couldn't QtPyVCP be offered to join the LinuxCNC organisation, of course keeping its own repository and release cycle ? @hazzy, @TurBoss ? I hope this could help join forces to work on VCP frameworks common ground. Waiting for this, I think STMBL could have a dedicated page targeted at integrators documenting their configuration in various use cases (axis, spindle, ...). For QtPyVCP and Remora, they've already done good documentation work so linking looks like a better option. Remora should be mentioned early at budget, machine specification and hardware selection stage. QtPyVCP should appear aside of the other VCP frameworks. Finally, Probe Basic, Monokrom, etc should be listed as alternatives to, say, respectively, QtDragon and QtPlasmaC. Maybe we could work more closely together on the common/shared part of the documentation to ensure users can use them easily side by side ?