As a little anecdotal evidence on remote UI - I've worked a little bit on remote operation of CNC's - sticking web cams in the environment. etc. I was able to run a tormach pretty successfully by VNC'ing in to it. I can see a future in which this is very useful to commercial users. I can see a future (at least for some shops), where you have data about a bank of machines that are running in a web app, and basically run a whole cell from one screen.
On Sun, May 3, 2020 at 8:40 AM Robert Murphy <robert.mur...@gmx.com> wrote: > > I agree, I never saw the sense in a remote UI, other than all the > "hipster\makers" want to control the world with their phones. > Machinekit, IMHO, seemed to be focused more towards the hobbyist who > wants bells and whistles rather than an industrial\commercial scene. > Don't take this as having a go, but just an observation. > > I think Andy (or someone we greater knowledge than myself)may have > mentioned that whilst the GUI buttons can made to reflect the state of a > hardware button, the reverse is not so simple. I'm not suggesting this > is what you have in mind. Whilst a "gui toggle switch" can reflect the > state of a hardware toggle switch, the reverse is not really possible. > Unless of course the hardware switches in that case were momentary with > a light to indicate the status, but would that not complicate hal & > physcial wiring. > > If the GUI was just info only, well that could be a way to make it possible. > > On 3/5/20 9:09 pm, Reinhard wrote: > > Hi Daniel, > > > >> It seems some developer at machinekit did some good work there. > >> ... > >> ... are the best features in machinekit that are missing in linuxcnc. > > Hm, I don't think, that a remote ui is something important, that linuxcnc is > > missing. And I don't take the nml-layer for bad so that it must be replaced. > > For me, nml-layer is a good piece of C-code, which was easy to adapt for > > java. > > The bad thing is the python addon, which can't be worse. > > > > So beside the remote accessibility I don't see any feature (in userworld) > > that > > machinekit has, which linuxcnc does not have. And replacing the middleware > > without benefit for the enduser is lot of time wasted (at least for me). > > > > For me, a machine is a local system. Some users would like to have an UI > > running on their mobile phone, but I can't take that for serious. May be > > acceptable as info board, but not for machining purpuse. And an infochannel > > is > > quite easy to workout as addon. > > > > That remote stuff could be "outsourced" to developers, that really want that > > stuff and like to spend their time to achive it. > > > > I believe, that the main purpose of linuxcnc is and should be the control of > > machines. In the sense of realtime responses, it is reasonable, to have all > > processes local to the machine controller (i.e. the pc that runs linuxcnc). > > > > What I really favor is a close coupling between backend and frontend. But > > that > > coupling must respect the realtime requirements of the backend. Frontend is > > always ok to be somewhat slow - as the human eyes are slow. > > So it does make no sense at all, have a UI which has an refreshrate higher > > than 24Hz. Nobody can see the difference. > > So coupling should relax the different timings. > > > > cheers Reinhard > > > > > > > > > > > > _______________________________________________ > > Emc-developers mailing list > > Emc-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
