Re: [Emc-developers] Third-Party GUIs

[Jared McLaughlin]

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  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

Re: [Emc-developers] Third-Party GUIs

[Damian Wrobel]

  On Mon, 04 May 2020 17:32:37 +0200 Jon Elson  
wrote 
 > On 05/04/2020 09:01 AM, Sebastian Kuzminsky wrote:
 > >
 > > Last time I checked, which was very, very long ago, Machinekit had not
 > > replaced the NML system used to communicate between the LinuxCNC GUIs and
 > > the machine controller, they had just wrapped it in a new software layer.
 > >
 > > Did they get rid of NML and make their new wrapper be the whole thing?
 > >
 > They replaced MANY of the functions with 0mq, but last I 
 > heard (also quite a while ago) it
 > was not complete, so some of NML was still there.  The 
 > MachineKit web site has certainly
 > been updated recently.  Also, there is some traffic on their 
 > forum. The Github is marked as
 > "archived" and no pull requests will be accepted.  That is a 
 > pretty bad sign, unless they
 > have moved development somewhere else.

They split the main https://github.com/machinekit/machinekit repo  into:
 - https://github.com/machinekit/machinekit-hal,
 - https://github.com/machinekit/machinekit-cnc.

Damian

 > 
 > Jon
 > 
 > 
 > ___
 > 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

Re: [Emc-developers] Third-Party GUIs

[Damian Wrobel]

  On Mon, 04 May 2020 17:32:37 +0200 Jon Elson  
wrote 
 > On 05/04/2020 09:01 AM, Sebastian Kuzminsky wrote:
 > >
 > > Last time I checked, which was very, very long ago, Machinekit had not
 > > replaced the NML system used to communicate between the LinuxCNC GUIs and
 > > the machine controller, they had just wrapped it in a new software layer.
 > >
 > > Did they get rid of NML and make their new wrapper be the whole thing?
 > >
 > They replaced MANY of the functions with 0mq, but last I 
 > heard (also quite a while ago) it
 > was not complete, so some of NML was still there.  The 
 > MachineKit web site has certainly
 > been updated recently.  Also, there is some traffic on their 
 > forum. The Github is marked as
 > "archived" and no pull requests will be accepted.  That is a 
 > pretty bad sign, unless they
 > have moved development somewhere else.

They split the main https://github.com/machinekit/machinekit repo into:
- https://github.com/machinekit/machinekit-hal,
- https://github.com/machinekit/machinekit-cnc.

Damian 

 > 
 > Jon
 > 
 > 
 > ___
 > 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

Re: [Emc-developers] Third-Party GUIs

[Jon Elson]

On 05/04/2020 09:01 AM, Sebastian Kuzminsky wrote:


Last time I checked, which was very, very long ago, Machinekit had not
replaced the NML system used to communicate between the LinuxCNC GUIs and
the machine controller, they had just wrapped it in a new software layer.

Did they get rid of NML and make their new wrapper be the whole thing?

They replaced MANY of the functions with 0mq, but last I 
heard (also quite a while ago) it
was not complete, so some of NML was still there.  The 
MachineKit web site has certainly
been updated recently.  Also, there is some traffic on their 
forum. The Github is marked as
"archived" and no pull requests will be accepted.  That is a 
pretty bad sign, unless they

have moved development somewhere else.

Jon


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[Reinhard]

On Montag, 4. Mai 2020, 13:43:53 CEST andy pugh wrote:
> I do think that MK perhaps got too caught-up in fixing the archaic and
> weird LinuxCNC software architecture rather than considering the
> question:
> "How does this make the software make better parts"

Yes, Andy - that's exactly what I thought, when I tried out machinekit.

When I read in the forum, that machinekit does so many things better than 
linuxcnc, I started to scratch for machinekit.
There's a lot to read about what is bad in linuxcnc and you can read a lot of 
propaganda, what machinekit wants to make different ...
But you can read next to nothing about what machinekit already has done.

>From all the proposals, I agreed in may be one or tho points, but when I 
installed machinekit, I got disappointed a lot.

Frontend is axis and while axis from linuxcnc ships with an intelligent 
sample, where you can learn a lot about coding GCode for linuxcnc, machinekit 
provides a dumb cam-output.
Axis works the same as in linuxcnc, so as a user I can't see any benefit.

Same is true for the youtube-lessons, which covered only trivial points, that 
every programmer should know, who dedicates itself to cnc ...
For me - just wasting my time :(

> And that is the danger, LinuxCNC is a machine controller. There is
> limited value to the user-base in making large changes to the
> underlying software implementation that they never see.

Sure - I believe, if architecture gets cleaned up, the goal should be users 
benefit in the sense of working out existing issues. Some issues seem to be 
impossible to solve with current architecture.
So that's the staff gauge.

I feel so sad about opencn - they seem to have reached real improvements. But 
they did a fork, which is not usable with the provided instructions. 
That improvement could have enriched linuxcnc - and now it looks like it will 
get lost.


cheers Reinhard





___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[Sebastian Kuzminsky]

On Mon, May 4, 2020, 07:33 andy pugh  wrote:

> On Sun, 3 May 2020 at 13:40, Robert Murphy  wrote:
>
> > Machinekit, IMHO, seemed to be focused more towards the hobbyist who
> > wants bells and whistles rather than an industrial\commercial scene.
>
> I do think that MK perhaps got too caught-up in fixing the archaic and
> weird LinuxCNC software architecture rather than considering the
> question:
> "How does this make the software make better parts"
>

Last time I checked, which was very, very long ago, Machinekit had not
replaced the NML system used to communicate between the LinuxCNC GUIs and
the machine controller, they had just wrapped it in a new software layer.

Did they get rid of NML and make their new wrapper be the whole thing?

>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[andy pugh]

On Sun, 3 May 2020 at 13:40, Robert Murphy  wrote:

> Machinekit, IMHO, seemed to be focused more towards the hobbyist who
> wants bells and whistles rather than an industrial\commercial scene.

I do think that MK perhaps got too caught-up in fixing the archaic and
weird LinuxCNC software architecture rather than considering the
question:
"How does this make the software make better parts"

And that is the danger, LinuxCNC is a machine controller. There is
limited value to the user-base in making large changes to the
underlying software implementation that they never see.

It's like when MS went to an XML format for all the Office files. 99%
of users just saw it as an inconvenience, and gained no benefit.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[Reinhard]

On Montag, 4. Mai 2020, 04:13:00 CEST Robert Murphy wrote:
> I did come to realise that yes remote GUI would have a place in an
> industrial setting.

May be I'm too simple minded. Could you please explain the conditions, where 
it makes sense to you?

> I would imagine if the protocol was simple enough and with tcp a mid to
> hi end microcontroller with a simple display could be put into use for
> use in a hobby workshop. Could it be that it could function as an
> extension of the GUI on the Linuxcnc machine, a "smart pendant" for lack
> of a better way to describe it ?

Although I don't see the sense of network connection between backend and 
frontend in hobby workshops, I would like to hear more from you.
I'm always willing to learn.

Here's a protocoll of someone trying network connection with linuxcnc and his 
failure ( - well, not his failure, but the failure by network concept ;) ):
https://forum.linuxcnc.org/41-guis/36920-labview-ui-project-for-linuxcnc

I believe, that putting a file into the ramdisk (which exists by default debian 
installations) is the fastest and easiest way for communication - even from 
realtimesystem to rest of the world.
Any network communication could read from those files and do the conversion 
stuff - and for so, the extra time for conversion does not harm execution of 
backend (/realtime) processes.
For me, that's flexible and performant at the same time.

cheers Reinhard




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[Robert Murphy]

I realised my opinion would come to bite me in the foot as I was
diagnosing the linuxcncrsh-tcp test.

I did come to realise that yes remote GUI would have a place in an
industrial setting.

I would imagine if the protocol was simple enough and with tcp a mid to
hi end microcontroller with a simple display could be put into use for
use in a hobby workshop. Could it be that it could function as an
extension of the GUI on the Linuxcnc machine, a "smart pendant" for lack
of a better way to describe it ?

My apologies if I seemed to making light of the effort gone into MK in
that area.

Cheers

Rob M

On 4/5/20 1:18 am, Jon Elson wrote:

On 05/03/2020 07:26 AM, Robert Murphy wrote:


Machinekit, IMHO, seemed to be focused more towards the hobbyist who
wants bells and whistles rather than an industrial\commercial scene.

Well, no.  A major focus was to support multiple instances of
Machinekit working in the same
physical space, without interference.  Think of workcells with part
loaders, part unloaders and
machining centers all moving through the same volume without anything
hitting other machines.

Or, multiple machines like robots that each do a specific job, like
welding and drilling holes at the
same time.

Jon


___
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

Re: [Emc-developers] Third-Party GUIs

[Reinhard]

Hi,

my answer was rejected yesterday, so I try to resend it ...

On Sonntag, 3. Mai 2020, 16:17:46 CEST Johannes Fassotte wrote:
> The name remote UI should be considered to mean that it is interfaced to
> LinuxCNC using a network connection. This connection for most individuals
> would likely be via local host but it can be used remotely if desired from
> other suitable devices.  Such a interface adds flexibility and would
> provide universal interface.

Flexibility? 

With nml-layer its possible for multiple clients read the status area. 
Command-channel is single-user, but works for multiple clients.
... and error channel - well, could be better 

With network you can't have multiple clients use the same port. Only if you 
give up security. That's no choice for risky environments, where a failure may 
result in human damage 
And cnc is a very risky environment. Don't underestimate that.


... and at what cost?

By convention network data format is big endian, whereas pc-dataformat is 
little endian. So using internal network for flexibility is some kind of stupid 
- especially in realtime environments.

Look at the billions of update calls in linuxcnc. They are cut out on nml-
layer. That's the fastest way: memory access for reader and writer - without 
any conversion.

So network usage needs to be well calculated. Don't ever use it without any 
need.
... and that means, that I don't estimate all design changes of machinekit.

Reinhard




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[Johannes Fassotte]

The slow update rate is likely a method issue and not an issue with network 
speed itself. Most networks can handle speeds of GB per second rates which is 
much much faster than actually required. Networks are used to stream all sorts 
of data these days.  Lagging behind can indicate a buffer overflow condition 
due to the receiving process running to slow to to keep up with the data being 
sent for display. Old code and speed restrictions are likely not designed to 
overcome that. New methods do require new code to be developed in order to 
provide excellent results.

Johannes P. Fassotte
Automation Assist
217 Sunny Hills Drive
Fairbanks, AK 99712

> On May 3, 2020, at 7:06 AM, Gene Heskett  wrote:
> 
>> On Sunday 03 May 2020 10:17:46 Johannes Fassotte wrote:
>> 
>> The name remote UI should be considered to mean that it is interfaced
>> to LinuxCNC using a network connection. This connection for most
>> individuals would likely be via local host but it can be used remotely
>> if desired from other suitable devices.  Such a interface adds
>> flexibility and would provide universal interface.
>> 
>> There is little difference between controlling a machine with say an
>> Ethernet interfaced Mesa FPGA board or using a Ethernet connected UI.
>> Both of these can be considered to be remote. How a user decides to
>> use it is totally up to the user since such an interface offers
>> tremendous flexibility.
>> 
>> Johannes P. Fassotte
>> Automation Assist
>> 217 Sunny Hills Drive
>> Fairbanks, AK 99712
>> 
> Haveing had some experience trying to run linuxcnc over an ssh -Y connection 
> I can say that it works BUT the backplot display I was looking at was also 
> running very close to a full second behind the machine. This was very 
> disconcerting and IMO a huge safety consideration in that there is no way one 
> could see an impending crash and broken tooling in time to stop it.  Same for 
> someone else walking up to the machine and getting in its way. Build it in if 
> you want to, but its not anything I'd ever try again.
> 
>>> On May 3, 2020, at 4:26 AM, Robert Murphy 
>>> 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 

Re: [Emc-developers] Third-Party GUIs

[Gene Heskett]

On Sunday 03 May 2020 10:17:46 Johannes Fassotte wrote:

> The name remote UI should be considered to mean that it is interfaced
> to LinuxCNC using a network connection. This connection for most
> individuals would likely be via local host but it can be used remotely
> if desired from other suitable devices.  Such a interface adds
> flexibility and would provide universal interface.
>
> There is little difference between controlling a machine with say an
> Ethernet interfaced Mesa FPGA board or using a Ethernet connected UI.
> Both of these can be considered to be remote. How a user decides to
> use it is totally up to the user since such an interface offers
> tremendous flexibility.
>
> Johannes P. Fassotte
> Automation Assist
> 217 Sunny Hills Drive
> Fairbanks, AK 99712
>
Haveing had some experience trying to run linuxcnc over an ssh -Y connection I 
can say that it works BUT the backplot display I was looking at was also 
running very close to a full second behind the machine. This was very 
disconcerting and IMO a huge safety consideration in that there is no way one 
could see an impending crash and broken tooling in time to stop it.  Same for 
someone else walking up to the machine and getting in its way. Build it in if 
you want to, but its not anything I'd ever try again.

> > On May 3, 2020, at 4:26 AM, Robert Murphy 
> > 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


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that 

Re: [Emc-developers] Third-Party GUIs

[Jon Elson]

On 05/03/2020 07:26 AM, Robert Murphy wrote:


Machinekit, IMHO, seemed to be focused more towards the 
hobbyist who
wants bells and whistles rather than an 
industrial\commercial scene.
Well, no.  A major focus was to support multiple instances 
of Machinekit working in the same
physical space, without interference.  Think of workcells 
with part loaders, part unloaders and
machining centers all moving through the same volume without 
anything hitting other machines.


Or, multiple machines like robots that each do a specific 
job, like welding and drilling holes at the

same time.

Jon


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[Nicklas Karlsson]

> Hi,
> 
> On Sonntag, 3. Mai 2020, 10:43:12 CEST N wrote:
> > Reading manual. "motion -- accepts  NML motion commands" so I guees you want
> > some of these commands to come from your hardware buttons?
> 
> Well, my idea is to have hardware buttons for every command, so that the UI 
> is 
> just an infoboard.
> Don't know, whether it is possible, but I'm working on it.
> 
> cheers Reinhard

Machine I am working with now have real buttons on the old control system and 
are certain it is good this possibility is available in Linuxcnc. With inputs 
for digital and if needed analog signals it should be no problem get signal 
into Linuxcnc and also the other direction if needed.

Looking into the development manual for 2.9.0 the figure on page 4 is an 
overview over the arhictecture. Manual for motion state "motion -- accepts NML 
motion command" and it is possible to connect pins using .hal file but motion 
commands are hardwire to NML.

Not sure to which "component/block" buttons in GUI is connected but guess the 
most obvious would be to make them these pins available in .hal file so they 
could be connected just as any other pins.

It is already possible to add custom panels or similar with gtk hal widgets 
which show up as gladevcp.pinName in my configuration file.


Regards Nicklas Karlsson


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[Johannes Fassotte]

The name remote UI should be considered to mean that it is interfaced to 
LinuxCNC using a network connection. This connection for most individuals would 
likely be via local host but it can be used remotely if desired from other 
suitable devices.  Such a interface adds flexibility and would provide 
universal interface.

There is little difference between controlling a machine with say an Ethernet 
interfaced Mesa FPGA board or using a Ethernet connected UI. Both of these can 
be considered to be remote. How a user decides to use it is totally up to the 
user since such an interface offers tremendous flexibility.

Johannes P. Fassotte
Automation Assist
217 Sunny Hills Drive
Fairbanks, AK 99712

> On May 3, 2020, at 4:26 AM, Robert Murphy  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

Re: [Emc-developers] Third-Party GUIs

[Robert Murphy]

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

Re: [Emc-developers] Third-Party GUIs

[Reinhard]

Hi,

On Sonntag, 3. Mai 2020, 10:43:12 CEST N wrote:
> Reading manual. "motion -- accepts  NML motion commands" so I guees you want
> some of these commands to come from your hardware buttons?

Well, my idea is to have hardware buttons for every command, so that the UI is 
just an infoboard.
Don't know, whether it is possible, but I'm working on it.

cheers Reinhard




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[Reinhard]

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

Re: [Emc-developers] Third-Party GUIs

[N]

> On Sonntag, 3. Mai 2020, 09:13:22 CEST N wrote:
> > That said it might still make sense to have some kind of
> > communication in between GUI and hal ...
> 
> Yes!
> 
> I'd like to implement my buttons in hardware, together with some potis and 
> currently I don't know, how to get rid of it from my gui.
> I know, that halui handles all this, but I can't access halpins from outside 
> of realtime.

Reading manual. "motion -- accepts  NML motion commands" so I guees you want 
some of these commands to come from your hardware buttons?

For example jog buttons, adjustment of jog speed.


Nicklas Karlsson


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[Daniel Scheeren]

Hi from Brazil!

It seems some developer at machinekit did some good work there. I tested
this:.
https://machinekoder.com/extending-machineface-with-hal-remote-to-control-smart-plugs/
 years ago, and that worked pretty well.
IMHO  haltalk and machinetalk:
https://machinekoder.com/machinetalk-explained-part-1-introduction/
 are the best features in machinekit that are missing in linuxcnc.

Regards

Daniel




Em dom, 3 de mai de 2020 04:26, Reinhard 
escreveu:

> On Sonntag, 3. Mai 2020, 09:13:22 CEST N wrote:
> > That said it might still make sense to have some kind of
> > communication in between GUI and hal ...
>
> Yes!
>
> I'd like to implement my buttons in hardware, together with some potis and
> currently I don't know, how to get rid of it from my gui.
> I know, that halui handles all this, but I can't access halpins from
> outside
> of realtime.
> I know, that i can create a component, that can be started by "loaduser",
> which then is not a realtime task (and I already succeeded in doing so),
> but I
> don't know, how to communicate with processes started by halcmd from my
> app.
>
> Shared memory without nml-handshake would be nice.
> Then clients would not slow down halui - although I don't know about the
> impact of nml-handshake.
>
> 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

Re: [Emc-developers] Third-Party GUIs

[Reinhard]

On Sonntag, 3. Mai 2020, 09:13:22 CEST N wrote:
> That said it might still make sense to have some kind of
> communication in between GUI and hal ...

Yes!

I'd like to implement my buttons in hardware, together with some potis and 
currently I don't know, how to get rid of it from my gui.
I know, that halui handles all this, but I can't access halpins from outside 
of realtime.
I know, that i can create a component, that can be started by "loaduser", 
which then is not a realtime task (and I already succeeded in doing so), but I 
don't know, how to communicate with processes started by halcmd from my app.

Shared memory without nml-handshake would be nice. 
Then clients would not slow down halui - although I don't know about the 
impact of nml-handshake.

Reinhard




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[N]

> Please don't ditch Axis. It's nice, clean & simple and I found it quite
> intuitive to use. It works well for my hobby class 3 axis mill.

Guess it do exactly what it should but have no other experience with other GUI 
for CNC machine.

> I like the fact that there is a GUI included with Linuxcnc, one less
> thing to install.

Without doubt. That said it might still make sense to have some kind of 
communication in between GUI and hal and there is in form of NML.


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[Robert Murphy]

Please don't ditch Axis. It's nice, clean & simple and I found it quite
intuitive to use. It works well for my hobby class 3 axis mill.

I like the fact that there is a GUI included with Linuxcnc, one less
thing to install.

If I was a new user I'd be a little confused if I had to install a GUI
separately, and which one to choose ?

On 3/5/20 9:18 am, Sebastian Kuzminsky wrote:

On 5/2/20 8:06 AM, andy pugh wrote:

On Sat, 2 May 2020 at 14:33, Juergen Gnoss  wrote:


I'm with the folks that like to have lcnc and gui's separated.
It's a much cleaner way for maintenance.


I think it's a daft idea from a user support point of view.

Take the example of where issues would be reported. Would you expect
users to have to search through github to find the right repository to
raise an issue on the right GUI?


Good point about debugging, Andy.

I object to moving the GUIs out of our repo for a different reason: I
worry that the work of building and distributing packages would not
get done by all the GUI developers, and as a result these out-of-repo
GUIs would be harder for our users to access.

That said, I sure am sympathetic to the extra work of maintaining all
these GUIs in our repo.

Perhaps some kind of packaging-as-a-service scheme could help here,
but it would still require proper dependency tracking and release
management to be done by the GUI devs.





___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[Sebastian Kuzminsky]

On 5/2/20 8:06 AM, andy pugh wrote:

On Sat, 2 May 2020 at 14:33, Juergen Gnoss  wrote:


I'm with the folks that like to have lcnc and gui's separated.
It's a much cleaner way for maintenance.


I think it's a daft idea from a user support point of view.

Take the example of where issues would be reported. Would you expect
users to have to search through github to find the right repository to
raise an issue on the right GUI?


Good point about debugging, Andy.

I object to moving the GUIs out of our repo for a different reason: I 
worry that the work of building and distributing packages would not get 
done by all the GUI developers, and as a result these out-of-repo GUIs 
would be harder for our users to access.


That said, I sure am sympathetic to the extra work of maintaining all 
these GUIs in our repo.


Perhaps some kind of packaging-as-a-service scheme could help here, but 
it would still require proper dependency tracking and release management 
to be done by the GUI devs.



--
Sebastian Kuzminsky


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[mydani]

+1 for focussing on quality over quantity.

1 UI is minimum due to having a reference implementation for the interfaces
as well as being able to test the overall complete SW system once before it
goes into release. Axis could be this reference UI. Then put the one fancy
most promising UI with big fanbase and most maintainers into the pot as
well.

Just my 2 cents.

Am Sa., 2. Mai 2020 um 18:29 Uhr schrieb Jon Elson :

> On 05/02/2020 05:13 AM, andy pugh wrote:
> > On Sat, 2 May 2020 at 10:15, Phill Carter 
> wrote:
> >
> >> I really don't see a problem with having the UI's as part of LinuxCNC
> > Many folk already complain that LinuxCNC is too difficult to set up. I
> > think that we would lose a lot of new users at the point that they
> > finished installing LinuxCNC and then found that they had to then go
> > off and find and install a user interface.
> >
> Yes, and another thing would be when something doesn't
> work.  If we maintain a "standard"
> GUI, such as Axis, we could always tell them to try the same
> program or operation with Axis
> and see if you get a similar error.
>
> Jon
>
>
> ___
> 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

Re: [Emc-developers] Third-Party GUIs

[Jon Elson]

On 05/02/2020 05:13 AM, andy pugh wrote:

On Sat, 2 May 2020 at 10:15, Phill Carter  wrote:


I really don't see a problem with having the UI's as part of LinuxCNC

Many folk already complain that LinuxCNC is too difficult to set up. I
think that we would lose a lot of new users at the point that they
finished installing LinuxCNC and then found that they had to then go
off and find and install a user interface.

Yes, and another thing would be when something doesn't 
work.  If we maintain a "standard"
GUI, such as Axis, we could always tell them to try the same 
program or operation with Axis

and see if you get a similar error.

Jon


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[andy pugh]

On Sat, 2 May 2020 at 14:33, Juergen Gnoss  wrote:

> I'm with the folks that like to have lcnc and gui's separated.
> It's a much cleaner way for maintenance.

I think it's a daft idea from a user support point of view.

Take the example of where issues would be reported. Would you expect
users to have to search through github to find the right repository to
raise an issue on the right GUI?

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[Ed]

On 5/2/20 8:32 AM, Juergen Gnoss wrote:

I'm with the folks that like to have lcnc and gui's separated.
It's a much cleaner way for maintenance.

Since new users and installation is a valid point, we should check
if it is possible to make a tasksel like LinuxCNC install routine.

Ju

YES!! Make it easy to set up for the newbee. I have been running since 
the days of the BDI installs and grown to like Axis as an interface as 
it can be run mostly from the keyboard which makes it fast to use, no 
grabbing for a mouse.



Ed.




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs.

[N]

On Sat, 2 May 2020 17:42:17 +1000
Rod Webster  wrote:

> Whilst I am a competent programmer with C and struggle to code in Python, I
> think enforcing C++ on GUI users would be a disaster. An interpreted
> language is much easier to work with and to add the overhead  of
> compilation to a quick GUI tweak will leave users out in the cold. ...

I also struggle with python then I use, C is somewhat primitive in som cases 
but I could get things done. It's a little bit hard to enforce something on 
anyone here as they do not have to write anything if they do not want.

> Only using C++ would basically stop the customisation of this wonderful
> software in its tracks and force users to continue to use an archaic GUI
> called Axis.

You happen to know how GUI look in modern CNC machines?


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[N]

> > Another problem is, that neither pyqt, nor gscreen runs on my desktop box. 
> > I 
> > don't know enuf of python to solve that problems on my own and it does not 
> > help, if others state, that they don't have problems.
> > So I started with java, where I know to solve my own problems.
> > Startup may be too slow, but response time of the running app is fast enuf 
> > for 
> > anything.
> 
> I imagine I would have the same issues with a Java UI if it didn't run.

Used Eclipse based development environment today, it is written in Java, have 
to wait half a second or so then switching break point and in general many 
cases have slow response but editor have fast response and it is really good 
software.

My experience with Java it is have often a little bit slow response, things do 
not happen immediately as then using an editor to write text which might be a 
little bit annoying. Maybe Java is at it's best then used on Internet inside 
.html or similar.

Learned to program some Java at University but have since then preferred other 
programming languages like C/C++ and ADA which I also encountered at University 
or Matlab/Octave, static types is one reason but there are in some cases also 
others. If I remember correct Java however had a strong point polymorphism 
worked well, think there are some difference for C++ but are a little bit 
uncertain for the others.


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[N]

I say it make sense and there are already NML communication which may also be 
used over TCP/IP network. I think however someone said it is currently not 
working condition for everything, might have been the hal scope. Tried and it 
might be the real time end worked but axis did not, think however old TK should.


> I'm with the folks that like to have lcnc and gui's separated.
> It's a much cleaner way for maintenance.
> 
> Since new users and installation is a valid point, we should check
> if it is possible to make a tasksel like LinuxCNC install routine.
> 
> Ju
> 
> ___
> 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

Re: [Emc-developers] Third-Party GUIs

[Juergen Gnoss]

I'm with the folks that like to have lcnc and gui's separated.
It's a much cleaner way for maintenance.

Since new users and installation is a valid point, we should check
if it is possible to make a tasksel like LinuxCNC install routine.

Ju

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs.

[Thomas J Powderly]

re the original post:



From: andy pugh 
Sent: May 1, 2020 12:17 PM
To: EMC developers 
Subject: [Emc-developers] Third-Party GUIs.

I wonder if the docs should mention the GUIs that are made for
LinuxCNC but are not part of LinuxCNC?

I am thinking of
http://www.qtpyvcp.com/showcase/mill_vcps.html
And
https://github.com/DjangoReinhard/JCNCScreen

And maybe also PathPilot.

--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


after reading several comments

i would include in the docs

one url to a description of the communication between a ui and linuxcnc

and one more url on the wiki where the many interfaces could be listed ( 
user maintained )


I'd hope the wiki would keep dates of last update.

Small and simple, 2 urls, no advocacy, no discussion,  just 
possibilities for the reader to investigate.


tomp




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[Phill Carter]

> On 2 May 2020, at 8:13 pm, andy pugh  wrote:
> 
> On Sat, 2 May 2020 at 10:15, Phill Carter  wrote:
> 
>> I really don't see a problem with having the UI's as part of LinuxCNC
> 
> Many folk already complain that LinuxCNC is too difficult to set up. I
> think that we would lose a lot of new users at the point that they
> finished installing LinuxCNC and then found that they had to then go
> off and find and install a user interface.

I agree. I also think that because Axis is suitable for a such wide variety of 
configurations it should still be the default even though it may be "archaic". 
It seems to mostly do what needs to be done and is easier on the eye (well at 
least for me) than a christmas tree.

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[Gene Heskett]

On Saturday 02 May 2020 04:46:52 Phill Carter wrote:

> > On 2 May 2020, at 5:32 pm, Reinhard 
> > wrote:
> >
> > On Samstag, 2. Mai 2020, 08:22:05 CEST Jared McLaughlin wrote:
> >> In my opinion, linuxcnc should be more like a distro that
> >> you install packages on. The UI's should be packages that are not
> >> maintained by the main development team.
> >
> > That makes sense
>
> I really don't see a problem with having the UI's as part of LinuxCNC
>
> >> I also agree with the idea that a cleaned up "new version" should
> >> be considered for the next major release.
> >
> > Would be nice!
> >
> >> I have used PathPilot and it seems a lot better than the other
> >> LinuxCNC UI's I poked at before. That said, I feel like even
> >> PathPilot has a long way to go ...
> >
> > Well, I'm the creator of JCNCScreen.
> >
> > The reason, why I started with such a big time-consuming work was,
> > that none of the existing UIs was really usable for me (including
> > PathPilot and others).
> >
> > I'm bit outdated, so I can't read axis and the like, that don't
> > respect proposals of window manager (i.e. like fontsize). Even on my
> > desktop pc I need glasses and put my nose onto the screen to be able
> > to read axis …
>
> It is relatively easy to change the font size in Axis.
>
> > For me, it is important, that I'm able to recognize the most
> > important states of the machine at a glance. Even from a distance of
> > about 4-5 meters. None of the UI offers this. Most if not all are
> > too noisy - and you need several seconds to find out, what is
> > relevant and what is just high-polishing for non-machinists - and
> > even then: not every important state is visible. Of cause, that does
> > not mean, that I want to read gcode from that distance, but
> > important machine states should be recognizable.
>
> Kind of a catch 22, the more states displayed the noisier it becomes.
>
> > Another problem is, that neither pyqt, nor gscreen runs on my
> > desktop box. I don't know enuf of python to solve that problems on
> > my own and it does not help, if others state, that they don't have
> > problems.
> > So I started with java, where I know to solve my own problems.
> > Startup may be too slow, but response time of the running app is
> > fast enuf for anything.
>
> I imagine I would have the same issues with a Java UI if it didn't
> run.
>
> > I don't really need my own UI - if another UI would offer, what I'm
> > looking for, it would be just fine.
>
> I don't think there will ever be a GUI that suits more than a few.
>
This is true. I still use axis although I have looked at some of the 
others, its seems like I always come back to axis, primarily because 
with pyvcp, I can bend it to do what I want. No two of my axis setups 
look alike. But I also get the impression that some of whats currently 
available no longer have a support person to answer setup questions, and 
those s/b reduced to honerable mentions. 

My biggest squawk about our gui's in general is the microscopic halmeter. 
It needs about a 4x magnification so it can be read from 3 meters away 
on a 22" screen when troubleshooting a home switch or whatever its set 
to watch.

> Cheers, Phill
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs.

[Rod Webster]

Yes, I know what axis is written in. And yes there is plenty to choose from
but the suggestion was to use C++ which made no sense
Rod Webster
*1300 896 832*
+61 435 765 611
VMN®
www.vmn.com.au



On Sat, 2 May 2020 at 20:20, andy pugh  wrote:

> On Sat, 2 May 2020 at 10:41, Rod Webster  wrote:
>
> > Only using C++ would basically stop the customisation of this wonderful
> > software in its tracks and force users to continue to use an archaic GUI
> > called Axis.
>
> Axis is written in Python. (and Tcl)
>
> > Once Python 3.0 is upgraded the next major body of work should be to
> > release a new, modern GUI as the Linuxcnc default.
>
> Why not an existing modern GUI? There are several. LinuxCNC includes
> TkLinuxCNC, Axis, Touchy, Gmoccapy, Gscreen (with several themes) and
> Silverdragon.
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> ___
> 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

Re: [Emc-developers] Third-Party GUIs

[andy pugh]

On Sat, 2 May 2020 at 10:15, Phill Carter  wrote:

> I really don't see a problem with having the UI's as part of LinuxCNC

Many folk already complain that LinuxCNC is too difficult to set up. I
think that we would lose a lot of new users at the point that they
finished installing LinuxCNC and then found that they had to then go
off and find and install a user interface.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs.

[andy pugh]

On Sat, 2 May 2020 at 10:41, Rod Webster  wrote:

> Only using C++ would basically stop the customisation of this wonderful
> software in its tracks and force users to continue to use an archaic GUI
> called Axis.

Axis is written in Python. (and Tcl)

> Once Python 3.0 is upgraded the next major body of work should be to
> release a new, modern GUI as the Linuxcnc default.

Why not an existing modern GUI? There are several. LinuxCNC includes
TkLinuxCNC, Axis, Touchy, Gmoccapy, Gscreen (with several themes) and
Silverdragon.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs.

[Rod Webster]

Whilst I am a competent programmer with C and struggle to code in Python, I
think enforcing C++ on GUI users would be a disaster. An interpreted
language is much easier to work with and to add the overhead  of
compilation to a quick GUI tweak will leave users out in the cold. I
persevere with Python because I know that I can  solve problems in Python
in 100 lines of code that would take 1000+  lines in C.  Heck we write
whole ERP systems in Python (Have a look at Odoo ERP previously Open ERP),
so to string a few lines together for a GUI is a walk in the park for
Python.

Only using C++ would basically stop the customisation of this wonderful
software in its tracks and force users to continue to use an archaic GUI
called Axis. It might be good from a programmer's perspective but its just
too far out of date in terms of where software development and user
expectations are today. I personally think that we need to adopt
Python3 ASAP and yes I just got dragged kicking and screaming from Python
2.7 to 3.0 but I did it.

Once Python 3.0 is upgraded the next major body of work should be to
release a new, modern GUI as the Linuxcnc default. Keeping the
current third party developers would be a a smart option because some of
them have done an amazing job and have kept their work in Git repositories
so it is sitting there ready to be pushed into Master branch of LinuxCNC
which is bound to save an enormous amount of work for the developer team.

So not to do what Andy has suggested would really be a bad move in my view.

Rod Webster
*1300 896 832*
+61 435 765 611
VMN®
www.vmn.com.au



On Sat, 2 May 2020 at 17:14, Nicklas Karlsson 
wrote:

> Use this gtk interface and it works but must install older version of
> glade.
>
> Still consider C++ a better option than python and I used both but if
> someone wrote in python I am of course a grateful user. Main reason for
> rather soft real time like GUI is static types so compiler could check
> pieces fit together before program is run.
>
>
> > Actually I would just link to the QtPyVCP web site qtpyvcp.com
> >
> > JT
> >
> > On 5/1/2020 4:28 PM, Gene Heskett wrote:
> > > On Friday 01 May 2020 16:38:01 John Thornton wrote:
> > >
> > >> Sounds like a good idea to me.
> > >>
> > >> JT
> > > I think so too John, but verifying that all those extras are alive and
> > > well is more than I'll ask our limited manpower to do, so just the
> > > mention of something google should find s/b more than enough.
> > >> On 5/1/2020 7:17 AM, andy pugh wrote:
> > >>> I wonder if the docs should mention the GUIs that are made for
> > >>> LinuxCNC but are not part of LinuxCNC?
> > >>>
> > >>> I am thinking of
> > >>> http://www.qtpyvcp.com/showcase/mill_vcps.html
> > >>> And
> > >>> https://github.com/DjangoReinhard/JCNCScreen
> > >>>
> > >>> And maybe also PathPilot.
> > >> ___
> > >> Emc-developers mailing list
> > >> Emc-developers@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/emc-developers
> > >
> > > Cheers, Gene Heskett
> >
> >
> > ___
> > 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

Re: [Emc-developers] Third-Party GUIs

[Phill Carter]

> On 2 May 2020, at 5:32 pm, Reinhard  wrote:
> 
> On Samstag, 2. Mai 2020, 08:22:05 CEST Jared McLaughlin wrote:
>> In my opinion, linuxcnc should be more like a distro that
>> you install packages on. The UI's should be packages that are not
>> maintained by the main development team.
> 
> That makes sense

I really don't see a problem with having the UI's as part of LinuxCNC

>> I also agree with the idea that a cleaned up "new version" should be
>> considered for the next major release.
> 
> Would be nice!
> 
>> I have used PathPilot and it seems a lot better than the other
>> LinuxCNC UI's I poked at before. That said, I feel like even PathPilot
>> has a long way to go ...
> 
> Well, I'm the creator of JCNCScreen.
> 
> The reason, why I started with such a big time-consuming work was, that none 
> of the existing UIs was really usable for me (including PathPilot and others).
> 
> I'm bit outdated, so I can't read axis and the like, that don't respect 
> proposals of window manager (i.e. like fontsize). Even on my desktop pc I 
> need 
> glasses and put my nose onto the screen to be able to read axis …

It is relatively easy to change the font size in Axis.

> For me, it is important, that I'm able to recognize the most important states 
> of the machine at a glance. Even from a distance of about 4-5 meters. 
> None of the UI offers this. Most if not all are too noisy - and you need 
> several seconds to find out, what is relevant and what is just high-polishing 
> for non-machinists - and even then: not every important state is visible.
> Of cause, that does not mean, that I want to read gcode from that distance, 
> but important machine states should be recognizable.

Kind of a catch 22, the more states displayed the noisier it becomes.

> Another problem is, that neither pyqt, nor gscreen runs on my desktop box. I 
> don't know enuf of python to solve that problems on my own and it does not 
> help, if others state, that they don't have problems.
> So I started with java, where I know to solve my own problems.
> Startup may be too slow, but response time of the running app is fast enuf 
> for 
> anything.

I imagine I would have the same issues with a Java UI if it didn't run.

> 
> I don't really need my own UI - if another UI would offer, what I'm looking 
> for, it would be just fine.

I don't think there will ever be a GUI that suits more than a few.

Cheers, Phill

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs.

[Nicklas Karlsson]

Have been working on a missing piece, mostly hardware for a few years but 
finally start to reach a point there it is good enough.

> I think so too.
> 
> > On 2 May 2020, at 4:29 am, Chris Morley  wrote:
> > 
> > I think we should just worry about/concentrate on, linuxcnc rather then 
> > other projects.
> > 
> > 
> > From: andy pugh 
> > Sent: May 1, 2020 12:17 PM
> > To: EMC developers 
> > Subject: [Emc-developers] Third-Party GUIs.
> > 
> > I wonder if the docs should mention the GUIs that are made for
> > LinuxCNC but are not part of LinuxCNC?
> > 
> > I am thinking of
> > http://www.qtpyvcp.com/showcase/mill_vcps.html
> > And
> > https://github.com/DjangoReinhard/JCNCScreen
> > 
> > And maybe also PathPilot.
> > 
> > --
> > atp
> > "A motorcycle is a bicycle with a pandemonium attachment and is
> > designed for the especial use of mechanical geniuses, daredevils and
> > lunatics."
> > — George Fitch, Atlanta Constitution Newspaper, 1912
> > 
> > 
> > ___
> > 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


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[Rod Webster]

Reinhard, I'm on your side, I rest my case. Thanks for summarising all the
failings of the current default GUI.

Rod Webster
*1300 896 832*
+61 435 765 611
VMN®
www.vmn.com.au



On Sat, 2 May 2020 at 17:33, Reinhard 
wrote:

> On Samstag, 2. Mai 2020, 08:22:05 CEST Jared McLaughlin wrote:
> > In my opinion, linuxcnc should be more like a distro that
> > you install packages on. The UI's should be packages that are not
> > maintained by the main development team.
>
> That makes sense
>
> > I also agree with the idea that a cleaned up "new version" should be
> > considered for the next major release.
>
> Would be nice!
>
> > I have used PathPilot and it seems a lot better than the other
> > LinuxCNC UI's I poked at before. That said, I feel like even PathPilot
> > has a long way to go ...
>
> Well, I'm the creator of JCNCScreen.
>
> The reason, why I started with such a big time-consuming work was, that
> none
> of the existing UIs was really usable for me (including PathPilot and
> others).
>
> I'm bit outdated, so I can't read axis and the like, that don't respect
> proposals of window manager (i.e. like fontsize). Even on my desktop pc I
> need
> glasses and put my nose onto the screen to be able to read axis ...
>
> For me, it is important, that I'm able to recognize the most important
> states
> of the machine at a glance. Even from a distance of about 4-5 meters.
> None of the UI offers this. Most if not all are too noisy - and you need
> several seconds to find out, what is relevant and what is just
> high-polishing
> for non-machinists - and even then: not every important state is visible.
> Of cause, that does not mean, that I want to read gcode from that
> distance,
> but important machine states should be recognizable.
>
> Another problem is, that neither pyqt, nor gscreen runs on my desktop box.
> I
> don't know enuf of python to solve that problems on my own and it does not
> help, if others state, that they don't have problems.
> So I started with java, where I know to solve my own problems.
> Startup may be too slow, but response time of the running app is fast enuf
> for
> anything.
>
> I don't really need my own UI - if another UI would offer, what I'm
> looking
> for, it would be just fine.
>
> 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

Re: [Emc-developers] Third-Party GUIs

[Reinhard]

On Samstag, 2. Mai 2020, 08:22:05 CEST Jared McLaughlin wrote:
> In my opinion, linuxcnc should be more like a distro that
> you install packages on. The UI's should be packages that are not
> maintained by the main development team.

That makes sense

> I also agree with the idea that a cleaned up "new version" should be
> considered for the next major release.

Would be nice!

> I have used PathPilot and it seems a lot better than the other
> LinuxCNC UI's I poked at before. That said, I feel like even PathPilot
> has a long way to go ...

Well, I'm the creator of JCNCScreen.

The reason, why I started with such a big time-consuming work was, that none 
of the existing UIs was really usable for me (including PathPilot and others).

I'm bit outdated, so I can't read axis and the like, that don't respect 
proposals of window manager (i.e. like fontsize). Even on my desktop pc I need 
glasses and put my nose onto the screen to be able to read axis ...

For me, it is important, that I'm able to recognize the most important states 
of the machine at a glance. Even from a distance of about 4-5 meters. 
None of the UI offers this. Most if not all are too noisy - and you need 
several seconds to find out, what is relevant and what is just high-polishing 
for non-machinists - and even then: not every important state is visible.
Of cause, that does not mean, that I want to read gcode from that distance, 
but important machine states should be recognizable.

Another problem is, that neither pyqt, nor gscreen runs on my desktop box. I 
don't know enuf of python to solve that problems on my own and it does not 
help, if others state, that they don't have problems.
So I started with java, where I know to solve my own problems.
Startup may be too slow, but response time of the running app is fast enuf for 
anything.

I don't really need my own UI - if another UI would offer, what I'm looking 
for, it would be just fine.

cheers Reinhard




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs.

[Nicklas Karlsson]

Use this gtk interface and it works but must install older version of glade.

Still consider C++ a better option than python and I used both but if someone 
wrote in python I am of course a grateful user. Main reason for rather soft 
real time like GUI is static types so compiler could check pieces fit together 
before program is run.


> Actually I would just link to the QtPyVCP web site qtpyvcp.com
> 
> JT
> 
> On 5/1/2020 4:28 PM, Gene Heskett wrote:
> > On Friday 01 May 2020 16:38:01 John Thornton wrote:
> >
> >> Sounds like a good idea to me.
> >>
> >> JT
> > I think so too John, but verifying that all those extras are alive and
> > well is more than I'll ask our limited manpower to do, so just the
> > mention of something google should find s/b more than enough.
> >> On 5/1/2020 7:17 AM, andy pugh wrote:
> >>> I wonder if the docs should mention the GUIs that are made for
> >>> LinuxCNC but are not part of LinuxCNC?
> >>>
> >>> I am thinking of
> >>> http://www.qtpyvcp.com/showcase/mill_vcps.html
> >>> And
> >>> https://github.com/DjangoReinhard/JCNCScreen
> >>>
> >>> And maybe also PathPilot.
> >> ___
> >> Emc-developers mailing list
> >> Emc-developers@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> > Cheers, Gene Heskett
> 
> 
> ___
> 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

Re: [Emc-developers] Third-Party GUIs

[Jared McLaughlin]

I'm still getting up to speed on some things, but I agree with this
sentiment. In my opinion, linuxcnc should be more like a distro that
you install packages on. The UI's should be packages that are not
maintained by the main development team. I also agree with the idea
that a cleaned up "new version" should be considered for the next
major release.

I have used PathPilot and it seems a lot better than the other
LinuxCNC UI's I poked at before. That said, I feel like even PathPilot
has a long way to go, but at least it looks like they are iterating
quickly.

On Fri, May 1, 2020 at 11:43 AM Johannes Fassotte
 wrote:
>
> Here are my thoughts on user interfaces.
>
> Frankly I think that just a mention that users can make their own user 
> interface would be enough and how to do that using a universal user interface 
> method.  In my opinion all user interfaces should be removed from LinuxCnc 
> proper which will greatly reduce maintenance and upgrade problems.
>
> As a example we’re still using Python 2.7 even though there has been talk 
> about upgrading it for years. Perhaps a totally new version of LinuxCnc 
> should be considered instead of adding more and more to the old. It does look 
> to me that Qtpyvcp will be the winner in user interfaces.
>
> Johannes P. Fassotte
> Automation Assist
> 217 Sunny Hills Drive
> Fairbanks, AK 99712
>
> > On May 1, 2020, at 4:17 AM, andy pugh  wrote:
> >
> > I wonder if the docs should mention the GUIs that are made for
> > LinuxCNC but are not part of LinuxCNC?
> >
> > I am thinking of
> > http://www.qtpyvcp.com/showcase/mill_vcps.html
> > And
> > https://github.com/DjangoReinhard/JCNCScreen
> >
> > And maybe also PathPilot.
> >
> > --
> > atp
> > "A motorcycle is a bicycle with a pandemonium attachment and is
> > designed for the especial use of mechanical geniuses, daredevils and
> > lunatics."
> > — George Fitch, Atlanta Constitution Newspaper, 1912
> >
> >
> > ___
> > 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

Re: [Emc-developers] Third-Party GUIs.

[Rod Webster]

That sounds awesome Phill
Rod Webster
*1300 896 832*
+61 435 765 611
VMN®
www.vmn.com.au



On Sat, 2 May 2020 at 10:24, Phill Carter  wrote:

>
>
> > On 2 May 2020, at 9:38 am, andy pugh  wrote:
> >
> > On Sat, 2 May 2020 at 00:32, Phill Carter 
> wrote:
> >
> >> If we link to one site then we may as well link to every known site
> that has a LinuxCNC compatible GUI
> >
> > That is what I am proposing, yes.
> >
> > (It's not like there are hundreds)
>
> So something like a "Third Party GIUs" page at the bottom of the "User
> Interfaces" section with alist of links.
>
> ___
> 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

Re: [Emc-developers] Third-Party GUIs.

[Phill Carter]

> On 2 May 2020, at 9:38 am, andy pugh  wrote:
> 
> On Sat, 2 May 2020 at 00:32, Phill Carter  wrote:
> 
>> If we link to one site then we may as well link to every known site that has 
>> a LinuxCNC compatible GUI
> 
> That is what I am proposing, yes.
> 
> (It's not like there are hundreds)

So something like a "Third Party GIUs" page at the bottom of the "User 
Interfaces" section with alist of links.

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs.

[andy pugh]

On Sat, 2 May 2020 at 00:32, Phill Carter  wrote:

> If we link to one site then we may as well link to every known site that has 
> a LinuxCNC compatible GUI

That is what I am proposing, yes.

(It's not like there are hundreds)

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs.

[Phill Carter]

> On 2 May 2020, at 9:28 am, John Thornton  wrote:
> 
> Actually I would just link to the QtPyVCP web site qtpyvcp.com
> 
> JT
> 

If we link to one site then we may as well link to every known site that has a 
LinuxCNC compatible GUI

Cheers, Phill

> On 5/1/2020 4:28 PM, Gene Heskett wrote:
>> On Friday 01 May 2020 16:38:01 John Thornton wrote:
>> 
>>> Sounds like a good idea to me.
>>> 
>>> JT
>> I think so too John, but verifying that all those extras are alive and
>> well is more than I'll ask our limited manpower to do, so just the
>> mention of something google should find s/b more than enough.
>>> On 5/1/2020 7:17 AM, andy pugh wrote:
 I wonder if the docs should mention the GUIs that are made for
 LinuxCNC but are not part of LinuxCNC?
 
 I am thinking of
 http://www.qtpyvcp.com/showcase/mill_vcps.html
 And
 https://github.com/DjangoReinhard/JCNCScreen
 
 And maybe also PathPilot.
>>> ___
>>> Emc-developers mailing list
>>> Emc-developers@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>> 
>> Cheers, Gene Heskett
> 
> 
> ___
> 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

Re: [Emc-developers] Third-Party GUIs.

[John Thornton]

Actually I would just link to the QtPyVCP web site qtpyvcp.com

JT

On 5/1/2020 4:28 PM, Gene Heskett wrote:

On Friday 01 May 2020 16:38:01 John Thornton wrote:


Sounds like a good idea to me.

JT

I think so too John, but verifying that all those extras are alive and
well is more than I'll ask our limited manpower to do, so just the
mention of something google should find s/b more than enough.

On 5/1/2020 7:17 AM, andy pugh wrote:

I wonder if the docs should mention the GUIs that are made for
LinuxCNC but are not part of LinuxCNC?

I am thinking of
http://www.qtpyvcp.com/showcase/mill_vcps.html
And
https://github.com/DjangoReinhard/JCNCScreen

And maybe also PathPilot.

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers


Cheers, Gene Heskett



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs.

[andy pugh]

On Fri, 1 May 2020 at 22:28, Gene Heskett  wrote:

> I think so too John, but verifying that all those extras are alive and
> well is more than I'll ask our limited manpower to do, so just the
> mention of something google should find s/b more than enough.

It's a matter of a link and checking it still works twice a year.
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs.

[Phill Carter]

I think so too.

> On 2 May 2020, at 4:29 am, Chris Morley  wrote:
> 
> I think we should just worry about/concentrate on, linuxcnc rather then other 
> projects.
> 
> 
> From: andy pugh 
> Sent: May 1, 2020 12:17 PM
> To: EMC developers 
> Subject: [Emc-developers] Third-Party GUIs.
> 
> I wonder if the docs should mention the GUIs that are made for
> LinuxCNC but are not part of LinuxCNC?
> 
> I am thinking of
> http://www.qtpyvcp.com/showcase/mill_vcps.html
> And
> https://github.com/DjangoReinhard/JCNCScreen
> 
> And maybe also PathPilot.
> 
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
> 
> 
> ___
> 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

Re: [Emc-developers] Third-Party GUIs.

[Gene Heskett]

On Friday 01 May 2020 16:38:01 John Thornton wrote:

> Sounds like a good idea to me.
>
> JT

I think so too John, but verifying that all those extras are alive and 
well is more than I'll ask our limited manpower to do, so just the 
mention of something google should find s/b more than enough.
>
> On 5/1/2020 7:17 AM, andy pugh wrote:
> > I wonder if the docs should mention the GUIs that are made for
> > LinuxCNC but are not part of LinuxCNC?
> >
> > I am thinking of
> > http://www.qtpyvcp.com/showcase/mill_vcps.html
> > And
> > https://github.com/DjangoReinhard/JCNCScreen
> >
> > And maybe also PathPilot.
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs.

[John Thornton]

Sounds like a good idea to me.

JT

On 5/1/2020 7:17 AM, andy pugh wrote:

I wonder if the docs should mention the GUIs that are made for
LinuxCNC but are not part of LinuxCNC?

I am thinking of
http://www.qtpyvcp.com/showcase/mill_vcps.html
And
https://github.com/DjangoReinhard/JCNCScreen

And maybe also PathPilot.




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[Chris Morley]

Users could make there own screens for quite some years now - gladevcp, gscreen 
and now qtvcp.
User interfaces are integral to Linuxcnc, so removing them doesn't help with 
maintenance, other then making less code to search through in one directory 
hierarchy. Machinekit separated ui from machine controller code but both 
projects are connected. I think they also have an easier mechanism for 
separating the coding, but wheather this was helpful in the long road of 
maintenance, I guess only they would know. I'm sure i'm sure it wasn't trivial 
to separate.

It also adds a small barrier for interface developers to not bother developing 
linuxcnc. ie if they do now they must have two pull requests...

Rather then splitting developers on more (related) projects we should try to 
collect them on one. We are drastically low on developers IMHO.




From: Johannes Fassotte 
Sent: May 1, 2020 3:43 PM
To: EMC developers 
Subject: Re: [Emc-developers] Third-Party GUIs

Here are my thoughts on user interfaces.

Frankly I think that just a mention that users can make their own user 
interface would be enough and how to do that using a universal user interface 
method.  In my opinion all user interfaces should be removed from LinuxCnc 
proper which will greatly reduce maintenance and upgrade problems.

As a example we’re still using Python 2.7 even though there has been talk about 
upgrading it for years. Perhaps a totally new version of LinuxCnc should be 
considered instead of adding more and more to the old. It does look to me that 
Qtpyvcp will be the winner in user interfaces.

Johannes P. Fassotte
Automation Assist
217 Sunny Hills Drive
Fairbanks, AK 99712



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs.

[Chris Morley]

I think we should just worry about/concentrate on, linuxcnc rather then other 
projects.


From: andy pugh 
Sent: May 1, 2020 12:17 PM
To: EMC developers 
Subject: [Emc-developers] Third-Party GUIs.

I wonder if the docs should mention the GUIs that are made for
LinuxCNC but are not part of LinuxCNC?

I am thinking of
http://www.qtpyvcp.com/showcase/mill_vcps.html
And
https://github.com/DjangoReinhard/JCNCScreen

And maybe also PathPilot.

--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


___
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

Re: [Emc-developers] Third-Party GUIs

[Nicklas Karlsson]

> Here are my thoughts on user interfaces.
> 
> Frankly I think that just a mention that users can make their own user 
> interface would be enough and how to do that using a universal user interface 
> method.  In my opinion all user interfaces should be removed from LinuxCnc 
> proper which will greatly reduce maintenance and upgrade problems.
> 
> As a example we’re still using Python 2.7 even though there has been talk 
> about upgrading it for years. Perhaps a totally new version of LinuxCnc 
> should be considered instead of adding more and more to the old. It does look 
> to me that Qtpyvcp will be the winner in user interfaces.

Would go for C or C++ or maybe ADA instead of python. As is now old version of 
GTK have to be used for custom panels, have one or two. Maybe sooner or later I 
get time, no night clubs ar open now and I decided I have more than enough 
courses from university.


Nicklas Karlsson


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Third-Party GUIs

[Johannes Fassotte]

Here are my thoughts on user interfaces.

Frankly I think that just a mention that users can make their own user 
interface would be enough and how to do that using a universal user interface 
method.  In my opinion all user interfaces should be removed from LinuxCnc 
proper which will greatly reduce maintenance and upgrade problems.

As a example we’re still using Python 2.7 even though there has been talk about 
upgrading it for years. Perhaps a totally new version of LinuxCnc should be 
considered instead of adding more and more to the old. It does look to me that 
Qtpyvcp will be the winner in user interfaces.

Johannes P. Fassotte
Automation Assist
217 Sunny Hills Drive
Fairbanks, AK 99712

> On May 1, 2020, at 4:17 AM, andy pugh  wrote:
> 
> I wonder if the docs should mention the GUIs that are made for
> LinuxCNC but are not part of LinuxCNC?
> 
> I am thinking of
> http://www.qtpyvcp.com/showcase/mill_vcps.html
> And
> https://github.com/DjangoReinhard/JCNCScreen
> 
> And maybe also PathPilot.
> 
> -- 
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
> 
> 
> ___
> 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