Re: [Emc-developers] 2.8 doesn't compile on mint 18 or 19

[Gene Heskett]

On Monday 20 April 2020 01:06:28 Chris Morley wrote:

> The new driver breaks my systems from compiling.
> I get lots of lines similar to this:
> src/hal/user_comps/xhc-whb04b-6/usb.cc:190:  undefined reference to
> `libusb_alloc_transfer'
>
> gcc version on mint 18 is 5.4
> on mint 19 it's 7.3 I believe.
>
> Any hint how to work around this please.
>
> Chris
>
A Git pull at the top of your build script? I just rebuilt it a  few 
hours ago on wheezy, no problems to the end of runtests at least.
Running test: /media/linuxcnc/gene/linuxcnc-dev/tests/uspace/spawnv-root
Runtest: 231 tests run, 231 successful, 0 failed + 0 expected

real15m32.000s
user0m34.818s
sys 0m52.259s

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

[Emc-developers] 2.8 doesn't compile on mint 18 or 19

[Chris Morley]

The new driver breaks my systems from compiling.
I get lots of lines similar to this:
src/hal/user_comps/xhc-whb04b-6/usb.cc:190:  undefined reference to 
`libusb_alloc_transfer'

gcc version on mint 18 is 5.4
on mint 19 it's 7.3 I believe.

Any hint how to work around this please.

Chris

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

Re: [Emc-developers] old distros

[Chris Morley]

Since you addressed me directly. :)

On 2020-04-19 8:02 p.m., Robert Murphy wrote:

Whilst I agree with you Chris, people just want updates, without really
knowing why. This could be the case when users migrate from Windows &
Mach, but then gain how often does Mach get upgraded ?

Personally if I had an old machine that was pumping out parts with no
issues with Wheezy & 2.7 I be happy just to let it do it's thing.

I might too - but it's not up to us to decide how users update their 
machines.


But more importantly It affects how future releases are handled. For 
instance if it's 2+ years  until 2.9 is out then forcing the use of 
newer distributions is probably less of a big deal. By then we possibly 
_will_ have a bunch of _necessary_ code that needs newer distribution.


If we (lol) happen to release in 6 months to a year then maybe it's 
still just the two _optional_ drives that stops someone from just 
updating linuxcnc rather the the whole distribution. Because updating 
the distribution often is a big PITA when you are talking of kernels and 
motherboards and ethernet cards etc.


We need to remember that linuxcnc packages are for users not developers 
and also that over the years we have tended (unintentionally) to 
encourage the use of master branch.





I found this with the Mint ISOs, I'd do a release with Linuxcnc built
from the latest 2.8 sources and people were wanting to know how to 
update.


I started to think that not many people were actually using the images
to run a machine, as there was very very little feed back on that, they
just wanted to install and be able to update.

One user admitted to not knowing what Mint was but went and installed it
on his machine anyways, then was wanting updated packages for Linuxcnc.

This is because you were making packages for a branch that was still 
being added to. Some guys had qtvcp problems I pushed a fix - they 
didn't get it cause their package doesn't automatically update...


It's really the projects fault for waiting so long to release 2.8. Not 
that was on purpose.



As for updating the OS.. there's enough users have trouble
installing Linuxcnc after being given basic instructions.


This is not a good reason to make limit choices for users.

It may seems like all users have trouble but of course if they had no 
trouble you probably wouldn't hear from them, so it tends to magnify 
that gut feeling.



Ideally a virtual package could be of use, user installs Debian or a
Ubuntu variant, adds the repo to the apt sources, then does "sudo
apt-get install awesome-machine-controller" and it installs a kernel and
the matching linuxcnc version and the deps for qtvcp. Have one each for
RT_PREEMPT & RTAI

Yes I'm sure there are other ways to release - I'm not up on new stuff. 
But it would really help to have more developers active in the project. 
That has been an on going problem too.


Anyways the point was to have a discussion and i think that is done.

Chris



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

Re: [Emc-developers] old distros

[Robert Murphy]

Whilst I agree with you Chris, people just want updates, without really
knowing why. This could be the case when users migrate from Windows &
Mach, but then gain how often does Mach get upgraded ?

Personally if I had an old machine that was pumping out parts with no
issues with Wheezy & 2.7 I be happy just to let it do it's thing.

If someone started selling a "Black Box" cnc controller with Linuxcnc
and the average user was unaware what was inside how often would they be
wanting updates, not often or maybe wouldn't even think about. Even more
so if the install was a Just Enough OS to run Linuxcnc, similar to what
libreelec do with Kodi.

I used to work for a company that installed "Zero Gravity Treadmills"
all the control was done by a PC running Win2k and later it was migrated
to Linux. None of the customers cared about updates just as long the
machine ran. These were installed in gyms, physios and some of the
larger sporting teams, Rugby League, Aussie Rules & Rugby Union. Even
the Australian Institute of Sport had a couple. If the user doesn't know
what's under the hood they don't really care. I just treat my Linuxcnc
machine as "black box" as long as it runs, it's good.

I found this with the Mint ISOs, I'd do a release with Linuxcnc built
from the latest 2.8 sources and people were wanting to know how to update.

I started to think that not many people were actually using the images
to run a machine, as there was very very little feed back on that, they
just wanted to install and be able to update.

One user admitted to not knowing what Mint was but went and installed it
on his machine anyways, then was wanting updated packages for Linuxcnc.

As for updating the OS.. there's enough users have trouble
installing Linuxcnc after being given basic instructions.

Ideally a virtual package could be of use, user installs Debian or a
Ubuntu variant, adds the repo to the apt sources, then does "sudo
apt-get install awesome-machine-controller" and it installs a kernel and
the matching linuxcnc version and the deps for qtvcp. Have one each for
RT_PREEMPT & RTAI

On 20/4/20 4:47 am, Chris Morley wrote:

Why does end of life matter to a machine controller?
Once you have a kernel/motherboard/distro combination that woks,
I wouldn't want to upgrade the distro unless I had to, because it probably will 
become painful.
If it is easy enough to keep support of an old distro then why not?
One optional driver not compiling does not seem a good reason to drop support.
Eventually we will need to but that is not a good enough reason IMHO.

Chris


From: René Hopf via Emc-developers 
Sent: April 19, 2020 4:58 PM
To: emc-developers@lists.sourceforge.net 
Cc: René Hopf 
Subject: [Emc-developers] old distros

Hi,

I added the EOL date of the official distros to the wiki:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions
Notice that only stretch and buster are not near end of life.

Recently there have been 2 PRs with code that doesn’t work on old compilers.
https://github.com/LinuxCNC/linuxcnc/pull/689
https://github.com/LinuxCNC/linuxcnc/pull/714

I don’t understand why we support distros that have been released 8 years
ago.
Making newer stuff work on legacy software is just a waste of developers
time.
If people can’t be bothered to update the distro, why would they be
bothered to update linuxcnc?
As far as Im aware everything works on stretch.

After a short discussion with jepler on irc, he mentioned that it hasn’t
been decided to drop support, and its unclear on how to decide stuff like
this.

My proposal:
Keep 2.8 as it is, as it's near the release.

Drop support for anything earlier than Stretch in master, and as soon as
python3 support is working, drop support for python2 in master.
Python2 is EOL since January, and it's not feasible to support both.

Rene

___
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] fixture offset

[Chris Morley]

I thought it might be helpful to overview our understanding of the 
current process. Hopefully the gurus will straighten out any errors I 
make here - but a least it's a talking point.


This is a very simplified description of the two processes running to 
turn gcode into machine motion. I didn't include tool I/O etc or manual 
commands. Basic auto or MDI process.


task (userspace- runs continuously)
    -calls interpreter to read gcode line
    -interp updates an internal settings structure
    - if the line has a motion command adds it to queue.
    - updates status on some things (not in sync with machine)
    repeat

Motion (realtime - runs continuously)
    -reads queue for next command
    -updates status on some things (in sync with machine)
    -reads HAL inputs for motion/spindle
    - plans trajectory (adjusts for overrides/threading etc)
    -outputs HAL pins for motion/spindle
    repeat

Once we know this is rightish then we can expand on it.

Hopefully in the end I can pull together some enough for documents for 
the future so more people can get involved. It also is helping wrap my 
head around linuxcnc internals.



Chris


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

Re: [Emc-developers] old distros

[Chris Morley]

On 2020-04-19 2:02 p.m., andy pugh wrote:

On Sun, 19 Apr 2020 at 19:47, Chris Morley  wrote:


If it is easy enough to keep support of an old distro then why not?

We are being squeezed at both ends, though. LinuxCNC relies on tools
(and versions of tools) that don't work on the latest OS versions.
Whereas the older OS versions don't necessarily work with the latest tools.
Ubuntu Precise uses gcc 4.6. That implements C++98 by default. C++17
is almost a different language.

And we will have to move to Python3 at some point. The legacy OSes all
have Py3, but whether the associated things (PyGTK etc) will work on
those systems with Py3 is not something I know.


I didn't suggest trying to make all thing compile on all distros.

I read the process you guys tried to get the driver to compile.

At that point the next sane answer would be to just not offer the 
drivers on older distros.



And it is hard to test on all the platforms. I spent much of today
setting up test systems for Precise and Wheezy, to go along with my
triple-boot hardware testing machine that runs Mint, Buster and
Stretch. The buildbot is currently testing builds for 20 different
combinations of OS and realtime. (and I would like to see Buster RTAI
added)


Well the buildbot is the usual process to test software compiling on 
different distros.


If we run out of buildbots - well thats a decent argument for dropping 
distros at least.


It probably highlights that he buildbot is a vulnerability for linuxcnc 
too. There was a guy willing to host a builtbot...



Anyways guys. Since I'm not during any of this work and at least we have 
had a discussion about it. I'll quiet down again :)


Chris



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

Re: [Emc-developers] old distros

[Chris Morley]

On 2020-04-19 2:14 p.m., mar...@r-bechtold.de wrote:



Am 19.04.2020 um 22:46 schrieb Chris Morley :


On 2020-04-19 1:07 p.m., mar...@r-bechtold.de wrote:

the problem is that this distros are that old and EOL that you even can not 
just install it, do to missing repo servers that are shut off

If it's an already installed version then they don't need the repo.

But you need it for setup and testing in development

It's already set up in the buildbot

You have to program around problems fixed in newer distro versions or you have 
to backport fixes just for a hand full of running installations and you have to 
test all off it.

This is part of having a project like this. and of course at some point it 
becomes more trouble then it is worth. I don't see that we are at that point. 
These are optional drivers we are talking of. When motion can not compile any 
more then I agree. and obviously there is a tipping point somewhere in between 
these two extreme examples. I am saying that the first time an optional driver 
can't be easily made to compile that we drop everything thing old.

I mean we are still stuck on python2 - so talking about optional drivers 
holding us back is a bit odd.


Something like this will active prevent innovation for the regular installation 
because you have to backport all feature to a OS you don't have a test 
environment for.
Stucking on python2 is not an argument its a symptom of this problems.


No I didn't suggest that and I didn't suggest supporting old distros 
forever.


You are talking my argument to the extreme.




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

Re: [Emc-developers] old distros

[mar...@r-bechtold.de]

> Am 19.04.2020 um 22:46 schrieb Chris Morley :
> 
> 
> On 2020-04-19 1:07 p.m., mar...@r-bechtold.de wrote:
>> the problem is that this distros are that old and EOL that you even can not 
>> just install it, do to missing repo servers that are shut off
> If it's an already installed version then they don't need the repo.

But you need it for setup and testing in development 

>> 
>> You have to program around problems fixed in newer distro versions or you 
>> have to backport fixes just for a hand full of running installations and you 
>> have to test all off it.
> 
> This is part of having a project like this. and of course at some point it 
> becomes more trouble then it is worth. I don't see that we are at that point. 
> These are optional drivers we are talking of. When motion can not compile any 
> more then I agree. and obviously there is a tipping point somewhere in 
> between these two extreme examples. I am saying that the first time an 
> optional driver can't be easily made to compile that we drop everything thing 
> old.
> 
> I mean we are still stuck on python2 - so talking about optional drivers 
> holding us back is a bit odd.
> 

Something like this will active prevent innovation for the regular installation 
because you have to backport all feature to a OS you don't have a test 
environment for.
Stucking on python2 is not an argument its a symptom of this problems.

>> 
>> That is just wasting valuable Developer time missing in the support of 
>> essential features.
> These weren't essential features.The easiest fix is to just not compile them 
> on older systems - I;m not a make file guru but that doesn't sound like too 
> much effort . There are plenty of bigger reasons we don't have enough 
> 'developer time'
>> Its realy not that Hard to update to a  new distor, if you want to use a 
>> newer Linuxcnc version. You have to port your configs anyway.
>> 
>> Markus
>> 
> That is absolutely not true. (and we are talking uses here not developers).
> 
> Even as a developer I find it a PITA sometimes. my Lathe computer I think is 
> on wheezy because I could not find a kernel that would work with stretch but 
> I do keep updating it fairly often in 2.8 (because master does not support 
> wheezy and 2.8 and master where very close )
> 
> We are the Debian of machine controllers. Slow to upgrade, stable and boring 
> :)
> 
> 
> 
> ___
> 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] old distros

[andy pugh]

On Sun, 19 Apr 2020 at 21:46, Chris Morley  wrote:

>  (because
> master does not support wheezy and 2.8 and master where very close )

Master supports Precise. Wheezy is newer than Precise.
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions

-- 
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] old distros

[andy pugh]

On Sun, 19 Apr 2020 at 19:47, Chris Morley  wrote:

> If it is easy enough to keep support of an old distro then why not?

We are being squeezed at both ends, though. LinuxCNC relies on tools
(and versions of tools) that don't work on the latest OS versions.
Whereas the older OS versions don't necessarily work with the latest tools.
Ubuntu Precise uses gcc 4.6. That implements C++98 by default. C++17
is almost a different language.

And we will have to move to Python3 at some point. The legacy OSes all
have Py3, but whether the associated things (PyGTK etc) will work on
those systems with Py3 is not something I know.

And it is hard to test on all the platforms. I spent much of today
setting up test systems for Precise and Wheezy, to go along with my
triple-boot hardware testing machine that runs Mint, Buster and
Stretch. The buildbot is currently testing builds for 20 different
combinations of OS and realtime. (and I would like to see Buster RTAI
added)

--
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] old distros

[Chris Morley]

On 2020-04-19 1:07 p.m., mar...@r-bechtold.de wrote:

the problem is that this distros are that old and EOL that you even can not 
just install it, do to missing repo servers that are shut off

If it's an already installed version then they don't need the repo.


You have to program around problems fixed in newer distro versions or you have 
to backport fixes just for a hand full of running installations and you have to 
test all off it.


This is part of having a project like this. and of course at some point 
it becomes more trouble then it is worth. I don't see that we are at 
that point. These are optional drivers we are talking of. When motion 
can not compile any more then I agree. and obviously there is a tipping 
point somewhere in between these two extreme examples. I am saying that 
the first time an optional driver can't be easily made to compile that 
we drop everything thing old.


I mean we are still stuck on python2 - so talking about optional drivers 
holding us back is a bit odd.




That is just wasting valuable Developer time missing in the support of 
essential features.
These weren't essential features.The easiest fix is to just not compile 
them on older systems - I;m not a make file guru but that doesn't sound 
like too much effort . There are plenty of bigger reasons we don't have 
enough 'developer time'

Its realy not that Hard to update to a  new distor, if you want to use a newer 
Linuxcnc version. You have to port your configs anyway.

Markus


That is absolutely not true. (and we are talking uses here not developers).

Even as a developer I find it a PITA sometimes. my Lathe computer I 
think is on wheezy because I could not find a kernel that would work 
with stretch but I do keep updating it fairly often in 2.8 (because 
master does not support wheezy and 2.8 and master where very close )


We are the Debian of machine controllers. Slow to upgrade, stable and 
boring :)




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

Re: [Emc-developers] old distros

[mar...@r-bechtold.de]

the problem is that this distros are that old and EOL that you even can not 
just install it, do to missing repo servers that are shut off 

You have to program around problems fixed in newer distro versions or you have 
to backport fixes just for a hand full of running installations and you have to 
test all off it.

That is just wasting valuable Developer time missing in the support of 
essential features.

Its realy not that Hard to update to a  new distor, if you want to use a newer 
Linuxcnc version. You have to port your configs anyway.

Markus



> Am 19.04.2020 um 21:53 schrieb Chris Morley :
> 
> Did you rty making it not try to compile on systems too old?
> I'm not suggesting putting a ton of effort into making it compile on 
> everything.
> 
> That's a huge difference.
> 
> Chris
> 
> From: Sync 
> Sent: April 19, 2020 7:10 PM
> To: emc-developers@lists.sourceforge.net 
> 
> Subject: Re: [Emc-developers] old distros
> 
> On 19.04.20 20:47, Chris Morley wrote:
>> Why does end of life matter to a machine controller?
> 
> It doesn't. It matters for the developers.
> 
>> If it is easy enough to keep support of an old distro then why not?
> 
> Because it isn't.
> 
>> One optional driver not compiling does not seem a good reason to drop 
>> support.
> 
> It's just that one driver now, but forcing developers to use legacy
> versions of their tools will drive people away.
> 
> 
> 
> ___
> 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] old distros

[Chris Morley]

Did you rty making it not try to compile on systems too old?
I'm not suggesting putting a ton of effort into making it compile on everything.

That's a huge difference.

Chris

From: Sync 
Sent: April 19, 2020 7:10 PM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] old distros

On 19.04.20 20:47, Chris Morley wrote:
> Why does end of life matter to a machine controller?

It doesn't. It matters for the developers.

> If it is easy enough to keep support of an old distro then why not?

Because it isn't.

> One optional driver not compiling does not seem a good reason to drop support.

It's just that one driver now, but forcing developers to use legacy
versions of their tools will drive people away.



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

Re: [Emc-developers] old distros

[René Hopf via Emc-developers]

Am So., 19. Apr. 2020 um 20:47 Uhr schrieb Chris Morley <
chrisinnana...@hotmail.com>:

> Why does end of life matter to a machine controller?
> Once you have a kernel/motherboard/distro combination that woks,
> I wouldn't want to upgrade the distro unless I had to, because it probably
> will become painful.
> If it is easy enough to keep support of an old distro then why not?
> One optional driver not compiling does not seem a good reason to drop
> support.
> Eventually we will need to but that is not a good enough reason IMHO.
>

if you dont want to update, dont update. once you have a linuxcnc version
that works for you, keep it.
updating major linuxcnc version is more complicated than updating
the distro, as the config changes.
It isnt easy to support them. its a pain for developers, and scares away
new people.
And stuff on the internet stops working. try watching youtube on ubuntu 8.04
try cloning a git repo that uses https.
eventually developers want to use newer features.




>
> Chris
>
> 
> From: René Hopf via Emc-developers 
> Sent: April 19, 2020 4:58 PM
> To: emc-developers@lists.sourceforge.net <
> emc-developers@lists.sourceforge.net>
> Cc: René Hopf 
> Subject: [Emc-developers] old distros
>
> Hi,
>
> I added the EOL date of the official distros to the wiki:
> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions
> Notice that only stretch and buster are not near end of life.
>
> Recently there have been 2 PRs with code that doesn’t work on old
> compilers.
> https://github.com/LinuxCNC/linuxcnc/pull/689
> https://github.com/LinuxCNC/linuxcnc/pull/714
>
> I don’t understand why we support distros that have been released 8 years
> ago.
> Making newer stuff work on legacy software is just a waste of developers
> time.
> If people can’t be bothered to update the distro, why would they be
> bothered to update linuxcnc?
> As far as Im aware everything works on stretch.
>
> After a short discussion with jepler on irc, he mentioned that it hasn’t
> been decided to drop support, and its unclear on how to decide stuff like
> this.
>
> My proposal:
> Keep 2.8 as it is, as it's near the release.
>
> Drop support for anything earlier than Stretch in master, and as soon as
> python3 support is working, drop support for python2 in master.
> Python2 is EOL since January, and it's not feasible to support both.
>
> Rene
>
> ___
> 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] old distros

[Sync]

On 19.04.20 20:47, Chris Morley wrote:
> Why does end of life matter to a machine controller?

It doesn't. It matters for the developers.

> If it is easy enough to keep support of an old distro then why not?

Because it isn't.

> One optional driver not compiling does not seem a good reason to drop support.

It's just that one driver now, but forcing developers to use legacy
versions of their tools will drive people away.


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

Re: [Emc-developers] old distros

[Chris Morley]

Why does end of life matter to a machine controller?
Once you have a kernel/motherboard/distro combination that woks,
I wouldn't want to upgrade the distro unless I had to, because it probably will 
become painful.
If it is easy enough to keep support of an old distro then why not?
One optional driver not compiling does not seem a good reason to drop support.
Eventually we will need to but that is not a good enough reason IMHO.

Chris


From: René Hopf via Emc-developers 
Sent: April 19, 2020 4:58 PM
To: emc-developers@lists.sourceforge.net 
Cc: René Hopf 
Subject: [Emc-developers] old distros

Hi,

I added the EOL date of the official distros to the wiki:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions
Notice that only stretch and buster are not near end of life.

Recently there have been 2 PRs with code that doesn’t work on old compilers.
https://github.com/LinuxCNC/linuxcnc/pull/689
https://github.com/LinuxCNC/linuxcnc/pull/714

I don’t understand why we support distros that have been released 8 years
ago.
Making newer stuff work on legacy software is just a waste of developers
time.
If people can’t be bothered to update the distro, why would they be
bothered to update linuxcnc?
As far as Im aware everything works on stretch.

After a short discussion with jepler on irc, he mentioned that it hasn’t
been decided to drop support, and its unclear on how to decide stuff like
this.

My proposal:
Keep 2.8 as it is, as it's near the release.

Drop support for anything earlier than Stretch in master, and as soon as
python3 support is working, drop support for python2 in master.
Python2 is EOL since January, and it's not feasible to support both.

Rene

___
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] old distros

[René Hopf via Emc-developers]

if you use 2.8, keep using it on whatever you currently have.
if you want to use master, and we decide to drop support we will have to
make sure there are isos when 2.9 is released.

Am So., 19. Apr. 2020 um 20:21 Uhr schrieb Gene Heskett <
ghesk...@shentel.net>:

> On Sunday 19 April 2020 13:55:28 René Hopf via Emc-developers wrote:
>
> > no one forces you to update, you can just stick with 2.8.
> > if you do want to update, update to buster.
> >
> Where is the install iso?
>
> 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
>

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

Re: [Emc-developers] old distros

[Gene Heskett]

On Sunday 19 April 2020 13:55:28 René Hopf via Emc-developers wrote:

> no one forces you to update, you can just stick with 2.8.
> if you do want to update, update to buster.
>
Where is the install iso?

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] old distros

[René Hopf via Emc-developers]

no one forces you to update, you can just stick with 2.8.
if you do want to update, update to buster.

Am So., 19. Apr. 2020 um 19:51 Uhr schrieb Gene Heskett <
ghesk...@shentel.net>:

> On Sunday 19 April 2020 12:58:13 René Hopf via Emc-developers wrote:
>
> > Hi,
> >
> > I added the EOL date of the official distros to the wiki:
> > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions
> > Notice that only stretch and buster are not near end of life.
> >
> > Recently there have been 2 PRs with code that doesn’t work on old
> > compilers. https://github.com/LinuxCNC/linuxcnc/pull/689
> > https://github.com/LinuxCNC/linuxcnc/pull/714
> >
> > I don’t understand why we support distros that have been released 8
> > years ago.
> > Making newer stuff work on legacy software is just a waste of
> > developers time.
> > If people can’t be bothered to update the distro, why would they be
> > bothered to update linuxcnc?
> > As far as Im aware everything works on stretch.
> >
> > After a short discussion with jepler on irc, he mentioned that it
> > hasn’t been decided to drop support, and its unclear on how to decide
> > stuff like this.
> >
> > My proposal:
> > Keep 2.8 as it is, as it's near the release.
> >
> > Drop support for anything earlier than Stretch in master, and as soon
> > as python3 support is working, drop support for python2 in master.
> > Python2 is EOL since January, and it's not feasible to support both.
> >
> > Rene
> >
> All well and nice in theory. But after some discussion a month or so back
> saying you had perms to use mint for the next release whereas debian was
> dragging their feet, I mention in replying to someone suggesting I
> update that upgrading would change to mint, but then Andy popped in and
> said no. According to the downloads web page, the latest that does a
> full capability install is still wheezy.
>
> If we now are forced to upgrade because support for the older wheezy
> build kit is to be dropped, what do we upgrade to? IOW whats the
> official word and where can I download an install iso for it that is not
> obsoleted by the distro before we can fan the paint is dry.
>
> FWIW, I am haveing great luck building master on an rpi4b to run on an
> rpi4b. I've even figured out how to install a 4.19.71-rt24-v7l+ #1 SMP
> PREEMPT RT kernel from a 30 meg tarball, which has decent latency AND
> support for the video hardware on a late pi board.  Thats your basic
> buster 10.3 install according to raspbian.  Works great and VERY STABLE.
>
> I've had 3 wintel boxes waiting for the next release since the wheezy
> repo's were pulled, what 4 years ago?  Now jessie and stretch are gone
> too.
>
> Cheers, and curious, 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
>

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

Re: [Emc-developers] old distros

[Gene Heskett]

On Sunday 19 April 2020 12:58:13 René Hopf via Emc-developers wrote:

> Hi,
>
> I added the EOL date of the official distros to the wiki:
> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions
> Notice that only stretch and buster are not near end of life.
>
> Recently there have been 2 PRs with code that doesn’t work on old
> compilers. https://github.com/LinuxCNC/linuxcnc/pull/689
> https://github.com/LinuxCNC/linuxcnc/pull/714
>
> I don’t understand why we support distros that have been released 8
> years ago.
> Making newer stuff work on legacy software is just a waste of
> developers time.
> If people can’t be bothered to update the distro, why would they be
> bothered to update linuxcnc?
> As far as Im aware everything works on stretch.
>
> After a short discussion with jepler on irc, he mentioned that it
> hasn’t been decided to drop support, and its unclear on how to decide
> stuff like this.
>
> My proposal:
> Keep 2.8 as it is, as it's near the release.
>
> Drop support for anything earlier than Stretch in master, and as soon
> as python3 support is working, drop support for python2 in master.
> Python2 is EOL since January, and it's not feasible to support both.
>
> Rene
>
All well and nice in theory. But after some discussion a month or so back 
saying you had perms to use mint for the next release whereas debian was 
dragging their feet, I mention in replying to someone suggesting I 
update that upgrading would change to mint, but then Andy popped in and 
said no. According to the downloads web page, the latest that does a 
full capability install is still wheezy.

If we now are forced to upgrade because support for the older wheezy 
build kit is to be dropped, what do we upgrade to? IOW whats the 
official word and where can I download an install iso for it that is not 
obsoleted by the distro before we can fan the paint is dry.

FWIW, I am haveing great luck building master on an rpi4b to run on an 
rpi4b. I've even figured out how to install a 4.19.71-rt24-v7l+ #1 SMP 
PREEMPT RT kernel from a 30 meg tarball, which has decent latency AND 
support for the video hardware on a late pi board.  Thats your basic 
buster 10.3 install according to raspbian.  Works great and VERY STABLE.

I've had 3 wintel boxes waiting for the next release since the wheezy 
repo's were pulled, what 4 years ago?  Now jessie and stretch are gone 
too.

Cheers, and curious, 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

[Emc-developers] old distros

[René Hopf via Emc-developers]

Hi,

I added the EOL date of the official distros to the wiki:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions
Notice that only stretch and buster are not near end of life.

Recently there have been 2 PRs with code that doesn’t work on old compilers.
https://github.com/LinuxCNC/linuxcnc/pull/689
https://github.com/LinuxCNC/linuxcnc/pull/714

I don’t understand why we support distros that have been released 8 years
ago.
Making newer stuff work on legacy software is just a waste of developers
time.
If people can’t be bothered to update the distro, why would they be
bothered to update linuxcnc?
As far as Im aware everything works on stretch.

After a short discussion with jepler on irc, he mentioned that it hasn’t
been decided to drop support, and its unclear on how to decide stuff like
this.

My proposal:
Keep 2.8 as it is, as it's near the release.

Drop support for anything earlier than Stretch in master, and as soon as
python3 support is working, drop support for python2 in master.
Python2 is EOL since January, and it's not feasible to support both.

Rene

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

[Emc-developers] single step, task, TP, motion, offsets

[Juergen Gnoss]

Robert Ellenberg wrote :

>I agree, the motion / TP component now is doing work that doesn't have to
>be in real-time. Specifically, the queueing of motion commands and the
>lookahead optimization could be done in a user space component. You'd need
>a real-time safe queue structure to do it, but it would make the
>optimization part much easier to implement. I believe OpenCN took this
>approach, and a similar design was.proposed years ago for Machinekit as
>well.

I actually didn't have a look at OpenCN code, so I cannot tell about that.
As far as what I think about machinekit. The planned approach was really nice 
and
using zmq as messaging system has quite potential.
But before I moved away from machinekit, back to lcnc, the guys at machinekit
focussed a lot more on implementing gimmicks instead a reliable, easy to handle 
system.
Don't know what's the actual state there by now.

Somebody knows of some sort of compare nml and zmq?

ju

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

[Emc-developers] single step, task, TP, motion, offsets

[Juergen Gnoss]

>As for feedrate override, the TP adjusts the feed rate on the current move
>almost instantly. It's a scale factor applied to the target velocity, so it
>doesn't actually change the "planned" motion data, just how it executes.



>On Sonntag, 19. April 2020, 16:15:07 CEST Robert Ellenberg wrote:
>> It's the same process to adjust it up or down. ... No replanning has to
>> happen at all for any feed override value.

That's great, so what's an actual use case for TP need to happen in motion?







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

Re: [Emc-developers] Emc-developers Digest, Vol 168, Issue 80

[Reinhard]

On Sonntag, 19. April 2020, 16:15:07 CEST Robert Ellenberg wrote:
> It's the same process to adjust it up or down. ... No replanning has to
> happen at all for any feed override value. 

Perfect :)




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

Re: [Emc-developers] Emc-developers Digest, Vol 168, Issue 80

[Robert Ellenberg]

It's the same process to adjust it up or down. The TP plans blend sizes for
a maximum feed override (typically 150% or 200%). No replanning has to
happen at all for any feed override value. You could apply as large an
override as you wanted in theory, but it would slow down disproportionately
in the corners due to the aforementioned blend sizes.

On Sun, Apr 19, 2020, 10:09 AM Reinhard 
wrote:

> On Sonntag, 19. April 2020, 15:57:38 CEST Juergen Gnoss wrote:
> > If there is a Feed override, you cannot expect the user uses it just in
> one
> > direction (down in your case) The software has to deal with booth
> > directions.
>
> Sure!
>
> But don't you agree, that the way down is more timecritical, than the way
> up?
> Way up means, things work good and could be better.
> Way down means: houston - we have a problem.
>
>
> 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] Wheezy, C++ and the XHCWB-06 driver.

[andy pugh]

On Sun, 19 Apr 2020 at 13:53, andy pugh  wrote:

> By adding '-std=c++11' to the Submakefile of the driver (and deleting
> a couple of logging lines) it all seems to compile again.

Forget this, ./configure adds this to Makefile.inc automatically in Wheezy.

Not sure about Precise.

-- 
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] Emc-developers Digest, Vol 168, Issue 80

[Reinhard]

On Sonntag, 19. April 2020, 15:57:38 CEST Juergen Gnoss wrote:
> If there is a Feed override, you cannot expect the user uses it just in one
> direction (down in your case) The software has to deal with booth
> directions.

Sure!

But don't you agree, that the way down is more timecritical, than the way up?
Way up means, things work good and could be better.
Way down means: houston - we have a problem.


Reinhard





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

Re: [Emc-developers] single step, task, TP, motion, offsets ...

[Reinhard]

On Sonntag, 19. April 2020, 15:46:36 CEST Juergen Gnoss wrote:
> Sure, there are some occasions where trajectory needs to be recalculated,
> even after they made it already to the part where actual iron gets moved.

I think, there is no need to recalculate motion path based on users feed-
override action.

In my mind, optimization of motion queue is done to avoid full stop between 
motions. But on touching feed-override or in singlestep mode, there's no 
requirement to path optimization.

> G00 X... Y...
> G01 X... Y... F...
> G02 I... J... F...
> 
> has been sent already to three of motions buffers
> G00 is done and disappears from motions buffers.
> G01 move is half the way done, while the operator moves the feed override
> slider. Now, what is what actual happens and what would we expect to
> happen.

Well, the only time- (and cost-) critical question is the case, when the user 
turns feed-override to zero. Than the machine should stop immediately.
Any other case should affect the motion speed only.

So from other cnc-controller I know, that they apply feed-override as a time-
value which will be applied on step-generation. No other software-part cares 
about feed-override.
If the time-value at step-generation is handled in realtime, than the machine 
is able to do a fast stop.

... and for so - feed override should be applied independant of the move 
command or whether it is between moves or whatever. 
Feed override is the most important realtime value (in my mind).


Reinhard




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

Re: [Emc-developers] single step, task, TP, motion, offsets ...

[Robert Ellenberg]

I agree, the motion / TP component now is doing work that doesn't have to
be in real-time. Specifically, the queueing of motion commands and the
lookahead optimization could be done in a user space component. You'd need
a real-time safe queue structure to do it, but it would make the
optimization part much easier to implement. I believe OpenCN took this
approach, and a similar design was.proposed years ago for Machinekit as
well.

As for feedrate override, the TP adjusts the feed rate on the current move
almost instantly. It's a scale factor applied to the target velocity, so it
doesn't actually change the "planned" motion data, just how it executes.

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

Re: [Emc-developers] Emc-developers Digest, Vol 168, Issue 80

[Juergen Gnoss]

Reinhard wrote:

>The right way is to program the optimal feed (depending on tool, cutting
>volume and vibrations and ...). Then on executing g-code, speed will be
>adapted if necessary. Normally you lower the speed on first try and then you
>run at 100% programmed feed rate.
>I have to change programmed feedrate really seldom. Just in some special cases
>with already hardened material or extremly large milling tools ...
>But I use the feed override to lower speed many thousand times on a new job.

You're right, that's the way it should be done, but looking at it, it's the 
same, just other
way around. If there is a Feed override, you cannot expect the user uses it 
just in one
direction (down in your case) The software has to deal with booth directions.

ju









--



--

Subject: Digest Footer

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


--

End of Emc-developers Digest, Vol 168, Issue 80
***

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

Re: [Emc-developers] fixture offset

[Gene Heskett]

On Sunday 19 April 2020 02:22:12 Reinhard wrote:

> On Sonntag, 19. April 2020, 08:18:55 CEST Chris Morley wrote:
> > Take feedrate.
> >
> > Right now feedrate by it's self does not cause a motion command.
> >
> > Motion is the only part that syncs with the real world.
> >
> > So if you single step over a F code only line it's ignored because
> > motion won't know about it until there is an actual move.
>
> and in my understanding this is a bug - not a feature!

Yes.  No other option can be applicable.
>
>
>
> ___
> 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

[Emc-developers] single step, task, TP, motion, offsets ...

[Juergen Gnoss]

At the moment I'm on Reinhard's page thinking that TP has to be done i a 
separate module
rather than going to happen in motion.
But maybe I doesn't see the full picture.
What are the key factors why TP actually happens in motion?

Sure, there are some occasions where trajectory needs to be recalculated, even 
after they
made it already to the part where actual iron gets moved.

Implementing it the way I described before,
motion just does moving iron and has several motion queue buffers.

movements describing

G00 X... Y...
G01 X... Y... F...
G02 I... J... F...

has been sent already to three of motions buffers
G00 is done and disappears from motions buffers.
G01 move is half the way done, while the operator moves the feed override 
slider.
Now, what is what actual happens and what would we expect to happen.

Does motion actual recalculate the remaining part of the G01 move in order to 
run the
new feed rate or does it apply the new feed rate to the G02 moves?

juP


From: emc-developers-requ...@lists.sourceforge.net 

Sent: Sunday, April 19, 2020 8:18 AM
To: emc-developers@lists.sourceforge.net 
Subject: Emc-developers Digest, Vol 168, Issue 79

Send Emc-developers mailing list submissions to
emc-developers@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/emc-developers
or, via email, send a message with subject or body 'help' to
emc-developers-requ...@lists.sourceforge.net

You can reach the person managing the list at
emc-developers-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Emc-developers digest..."


Today's Topics:

   1. Re: fixture offset (Chris Morley)
   2. Re: fixture offset (Amit Goradia)
   3. Re: fixture offset (Reinhard)
   4. Re: fixture offset (Reinhard)


--

Message: 1
Date: Sun, 19 Apr 2020 00:06:26 -0700
From: Chris Morley 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] fixture offset
Message-ID:



Content-Type: text/plain; charset=utf-8; format=flowed


On 2020-04-18 11:01 p.m., Reinhard wrote:
> On Sonntag, 19. April 2020, 07:56:12 CEST Chris Morley wrote:
>> Motion does the movement planning so would be the one to know when to stop
>> before breaking limits.
> Well, if motion does the movement planning, than motion performs taskmanagers
> job. Movement planning is not motion.
> And if motion does the movement planning, it should of cause know about single
> step or auto mode and should know about g-code lines and machine commands.
>
> Very weird design.
>
>
>
Motion does the trajectory planning which can't be preplanned by
interpreter/task because of things like overides and spindle sync





--

Message: 2
Date: Sun, 19 Apr 2020 12:16:03 +0530
From: Amit Goradia 
To: EMC developers 
Subject: Re: [Emc-developers] fixture offset
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Current single stepping is done in task with little part implemented in
motion.

Task fetches one line ( there is some debate about line classification, but
more on that later) from rs274. Then does some checking on it and passes it
to motion. At this point, in the checking part, task does single stepping.
However, for the commands that have already been queued to motion, task
tells motion to single step those commands too.
Beyond this task will only send one command at a time to motion which will
execute them while task waits for that execution to complete.
At this time (during single stepping) read ahead from rs274 is not stopped.
That goes on to for us over or cannon queue is full or task is waiting for
explicit sync command i.e tool change m66 etc.

What qualifies as single line of gcode from rs274 is decided by the canon
commands. Canon  commands are used to send commands to task from rs274.
Canon commands are lined up by rs274 into a canon queue for task to read
from. A bunch of cannon commands like mcodes don't have line numbers in
them. Thus task cannot stop for them during single stepping. If we add line
numbers to those cannon commands, task should automatically start stopping
for them during single stepping.
Task implements a simple line number check while waiting for single
stepping, which is "Keep sending commands to motion to execute till we
don't see a different line number".

Hope this explains helps.

- automata


On Sun, 19 Apr, 2020, 11:33 am Reinhard, 
wrote:

> On Sonntag, 19. April 2020, 07:56:12 CEST Chris Morley wrote:
> > Motion does the movement planning so would be the one to know when to
> stop
> > before breaking limits.
>
> Well, if motion does the movement planning, than motion performs
> taskmanagers
> job. Movement planning is not motion.
> And if motion does the movement planning, it should of cause know about
> single
> 

Re: [Emc-developers] Emc-developers Digest, Vol 168, Issue 79

[Reinhard]

On Sonntag, 19. April 2020, 15:22:21 CEST Juergen Gnoss wrote:
> That's not the case for all lcnc users.

Of cause! I can't speek for all users. 
So I speek for me only.

> Override values are also often used to optimize cutting.
> While job setup, you program a low (secure) feed in g-code and while running
> the program you crank up the feed to an optimal value using override. Then
> you change the g-code for a production run.

Whow - so if users use the software in a wrong manner, than wrong behaviour of 
software is right?

The right way is to program the optimal feed (depending on tool, cutting 
volume and vibrations and ...). Then on executing g-code, speed will be 
adapted if necessary. Normally you lower the speed on first try and then you 
run at 100% programmed feed rate.
I have to change programmed feedrate really seldom. Just in some special cases 
with already hardened material or extremly large milling tools ...
But I use the feed override to lower speed many thousand times on a new job.

Some days ago some developer said, that they like to move linuxcnc toward more 
professional controllers - so I mentioned, what I expect from a professional 
controller. That's all.


Reinhard




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

Re: [Emc-developers] Emc-developers Digest, Vol 168, Issue 79

[Juergen Gnoss]

Chris wrote:
>Yes I agree but it shows the problem of stepping code when motion is not
>one to one with gcode.

>unless you put task in realtime side it's hard to work around.

That depends what you mean with "realtime side"
real time means, things have to get executed in a defined amount of time
starting from firing the command.
We can have task run in userspace, but it splits workload over a lot of modules 
(processes)
So meet that timing requirements isn't an issue on actual multi core machines.


Work split between g-code interpreter, task manager and motion in single step:
G00 X.. Y... Z...
G01 X... Y... F...

It really happens that on the G01 line, feed is set for subsequent operations, 
it happens (internally)
in a single instruction, before TP is calculating the move to the new location.
g-code interpreter and task has to know the order of executing several commands 
on a single line.

If I single step through g-code it doesn't bother me if I don't see any machine 
movement on a
only F... line, but see the result in a pin or so while looking at the related 
variable/pin in HAL.
The operator may not look at hal, but should not expect a physical move on a F 
or offset changing line.


Reinhard wrote:

>In my daily work, overwrite values are used to lower or stop programmed
>motion. If overwrite button is used, NO user cares about path optimization.
>It's irrelevant in that moment. The only important question is, that the
>machine stops as fast as the button hits zero. And the importance of that
>requirement is proportional to the moving speed :)

That's not the case for all lcnc users.
Override values are also often used to optimize cutting.
While job setup, you program a low (secure) feed in g-code and while running 
the program
you crank up the feed to an optimal value using override. Then you change the 
g-code for
a production run.
Taking that scenario in account, yes trajectory, especially path blending 
matters.


ju




From: emc-developers-requ...@lists.sourceforge.net 

Sent: Sunday, April 19, 2020 8:18 AM
To: emc-developers@lists.sourceforge.net 
Subject: Emc-developers Digest, Vol 168, Issue 79

Send Emc-developers mailing list submissions to
emc-developers@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/emc-developers
or, via email, send a message with subject or body 'help' to
emc-developers-requ...@lists.sourceforge.net

You can reach the person managing the list at
emc-developers-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Emc-developers digest..."


Today's Topics:

   1. Re: fixture offset (Chris Morley)
   2. Re: fixture offset (Amit Goradia)
   3. Re: fixture offset (Reinhard)
   4. Re: fixture offset (Reinhard)


--

Message: 1
Date: Sun, 19 Apr 2020 00:06:26 -0700
From: Chris Morley 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] fixture offset
Message-ID:



Content-Type: text/plain; charset=utf-8; format=flowed


On 2020-04-18 11:01 p.m., Reinhard wrote:
> On Sonntag, 19. April 2020, 07:56:12 CEST Chris Morley wrote:
>> Motion does the movement planning so would be the one to know when to stop
>> before breaking limits.
> Well, if motion does the movement planning, than motion performs taskmanagers
> job. Movement planning is not motion.
> And if motion does the movement planning, it should of cause know about single
> step or auto mode and should know about g-code lines and machine commands.
>
> Very weird design.
>
>
>
Motion does the trajectory planning which can't be preplanned by
interpreter/task because of things like overides and spindle sync





--

Message: 2
Date: Sun, 19 Apr 2020 12:16:03 +0530
From: Amit Goradia 
To: EMC developers 
Subject: Re: [Emc-developers] fixture offset
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Current single stepping is done in task with little part implemented in
motion.

Task fetches one line ( there is some debate about line classification, but
more on that later) from rs274. Then does some checking on it and passes it
to motion. At this point, in the checking part, task does single stepping.
However, for the commands that have already been queued to motion, task
tells motion to single step those commands too.
Beyond this task will only send one command at a time to motion which will
execute them while task waits for that execution to complete.
At this time (during single stepping) read ahead from rs274 is not stopped.
That goes on to for us over or cannon queue is full or task is waiting for
explicit sync command i.e tool change m66 etc.

What qualifies as single line of gcode from rs274 is decided by the canon
commands. Canon  commands are used to send commands to task from 

[Emc-developers] Wheezy, C++ and the XHCWB-06 driver.

[andy pugh]

There is a new driver for all of the XHC pendants, but it requires
slightly newer C++ than is the default in Wheezy, so the compile of
master on Wheezy is currently broken.
http://buildbot.linuxcnc.org/buildbot/grid

But is seems that Wheezy is perfectly happy to compile C++11 code, it
just doesn't choose to by default.

By adding '-std=c++11' to the Submakefile of the driver (and deleting
a couple of logging lines) it all seems to compile again.

But, is the submakefile the right place to do this? I also tried
adding -std=c++11 to the CXXFLAGS in the Makefile and nothing seemed
to break, and the component compiled.

Is it a good idea to put this flag in to the main makefile?

-- 
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] fixture offset

[Reinhard]

On Sonntag, 19. April 2020, 09:06:26 CEST Chris Morley wrote:
> Motion does the trajectory planning which can't be preplanned by
> interpreter/task because of things like overides and spindle sync

Well, in my mind, task-manager should do all motion planning respect to tool 
tip. Tool tip moves in 3D-coordinate space and other axis may help on tool-
shaft orientation without changing tooltip location.

So task-manager cares about theoretically (let me name it so) motion, whereas 
motion takes out physical motion.
Taskmanager knows anything about fixtures, tool-length, radius- and length 
properties ...
... but taskmanager does not know anything about physical machine (kinematics 
and the like), which means, it tells motion to move tooltip from location A to 
location B, but only motion knows how to do that (kinematics and all that 
things go into here).

Trajectory planning should not be based on overwrite values. Planning could be 
done with programmed feed rate. Only motion should care about overwrite values 
and changes projected speed from taskmanager.
I believe, that overwrite values don't change the quality of trajectory 
planning. That should work based on angular changes (or similar geometric 
based properties) from one motion to the other.

In my daily work, overwrite values are used to lower or stop programmed 
motion. If overwrite button is used, NO user cares about path optimization. 
It's irrelevant in that moment. The only important question is, that the 
machine stops as fast as the button hits zero. And the importance of that 
requirement is proportional to the moving speed :)

But even if only motion cares about overwrite values, UI should be able to 
reflect changes of overwrite values with acceptable delay. UI is not that 
timecritical than motion, so delay of 0.5s might be quite ok.
But UI is supposed to show any machine properties at time.
You can try to program feed or spindle speed without any motion. On 
professional machines, the UI shows the result of the programmed change.
You can program spindle speed even if the spindle is not turning.
Motion and programming is separated completely.

Reinhard




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

Re: [Emc-developers] fixture offset

[Reinhard]

On Sonntag, 19. April 2020, 09:00:16 CEST Chris Morley wrote:
> Yes I agree but it shows the problem of stepping code when motion is not
> one to one with gcode.

May be I don't get the whole picture, but at the moment, I can't see any 
reason for that requirement.




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

Re: [Emc-developers] fixture offset

[Amit Goradia]

Current single stepping is done in task with little part implemented in
motion.

Task fetches one line ( there is some debate about line classification, but
more on that later) from rs274. Then does some checking on it and passes it
to motion. At this point, in the checking part, task does single stepping.
However, for the commands that have already been queued to motion, task
tells motion to single step those commands too.
Beyond this task will only send one command at a time to motion which will
execute them while task waits for that execution to complete.
At this time (during single stepping) read ahead from rs274 is not stopped.
That goes on to for us over or cannon queue is full or task is waiting for
explicit sync command i.e tool change m66 etc.

What qualifies as single line of gcode from rs274 is decided by the canon
commands. Canon  commands are used to send commands to task from rs274.
Canon commands are lined up by rs274 into a canon queue for task to read
from. A bunch of cannon commands like mcodes don't have line numbers in
them. Thus task cannot stop for them during single stepping. If we add line
numbers to those cannon commands, task should automatically start stopping
for them during single stepping.
Task implements a simple line number check while waiting for single
stepping, which is "Keep sending commands to motion to execute till we
don't see a different line number".

Hope this explains helps.

- automata


On Sun, 19 Apr, 2020, 11:33 am Reinhard, 
wrote:

> On Sonntag, 19. April 2020, 07:56:12 CEST Chris Morley wrote:
> > Motion does the movement planning so would be the one to know when to
> stop
> > before breaking limits.
>
> Well, if motion does the movement planning, than motion performs
> taskmanagers
> job. Movement planning is not motion.
> And if motion does the movement planning, it should of cause know about
> single
> step or auto mode and should know about g-code lines and machine commands.
>
> Very weird design.
>
>
>
>
> ___
> 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] fixture offset

[Chris Morley]

On 2020-04-18 11:01 p.m., Reinhard wrote:

On Sonntag, 19. April 2020, 07:56:12 CEST Chris Morley wrote:

Motion does the movement planning so would be the one to know when to stop
before breaking limits.

Well, if motion does the movement planning, than motion performs taskmanagers
job. Movement planning is not motion.
And if motion does the movement planning, it should of cause know about single
step or auto mode and should know about g-code lines and machine commands.

Very weird design.



Motion does the trajectory planning which can't be preplanned by 
interpreter/task because of things like overides and spindle sync





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

Re: [Emc-developers] fixture offset

[Chris Morley]

On 2020-04-18 11:22 p.m., Reinhard wrote:

On Sonntag, 19. April 2020, 08:18:55 CEST Chris Morley wrote:

Take feedrate.

Right now feedrate by it's self does not cause a motion command.

Motion is the only part that syncs with the real world.

So if you single step over a F code only line it's ignored because
motion won't know about it until there is an actual move.

and in my understanding this is a bug - not a feature!


Yes I agree but it shows the problem of stepping code when motion is not 
one to one with gcode.


unless you put task in realtime side it's hard to work around.



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

Re: [Emc-developers] fixture offset

[Reinhard]

On Sonntag, 19. April 2020, 08:18:55 CEST Chris Morley wrote:
> Take feedrate.
> 
> Right now feedrate by it's self does not cause a motion command.
> 
> Motion is the only part that syncs with the real world.
> 
> So if you single step over a F code only line it's ignored because
> motion won't know about it until there is an actual move.

and in my understanding this is a bug - not a feature!




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

Re: [Emc-developers] fixture offset

[Chris Morley]

On 2020-04-18 11:04 p.m., Reinhard wrote:

On Sonntag, 19. April 2020, 07:58:52 CEST Chris Morley wrote:

The problem become that motion commands and gcode are not one to one.

Well, that does not mean, that it should cause problems.
When programming G-code (at the machine) there can be several commands in one
line. Its the interpreters job to know sequencing of commands and when they
arrive task-manager, they already should be single commands.
Though multiple commands can share the same source line.

Reinhard


Take feedrate.

Right now feedrate by it's self does not cause a motion command.

Motion is the only part that syncs with the real world.

So if you single step over a F code only line it's ignored because 
motion won't know about it until there is an actual move.





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

Re: [Emc-developers] Emc-developers Digest, Vol 168, Issue 75

[Reinhard]

Hi Jürgen,

I guess you really understood my writings.

On Sonntag, 19. April 2020, 08:03:30 CEST Juergen Gnoss wrote:
> If the motion queue is made of a few rolling buffers and does pull the
> content of that buffers from task-manager rather than get pushed into it,
> it's far more easy to keep track of the machine state. 

Right.

> Task-manager splits motion commands into "motion blocks", caring for motion
> logic not for filled buffers, and knows the order in what they should be
> executed.

Exactly

> If motion asks for the next block, ...

Well, motion should not ask for anything. 
It should work out what is in the motion queue.

If the task-manager works in single-step mode, than it puts only a single move 
into motions queue. Motion executes that and as the queue is empty it waits 
for next entry.

So task-manager knows the sequence of motions and machinecommands and how 
they interact or how they are related. Motion does not need to know about 
machine commands (like flood, mist or spindle commands)

> Sounds a lot of work, but that relativates to a lot of modules with a small
> amount of code each. So maintenance should profit from that as well.

Well, best would be, first discuss the desired system design. Code is all 
there, it needs to be reorganized/moved.
May be, that's a chance to rewrite ugly/obfuscated code.

Reinhard




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

Re: [Emc-developers] fixture offset

[Reinhard]

On Sonntag, 19. April 2020, 07:58:52 CEST Chris Morley wrote:
> The problem become that motion commands and gcode are not one to one.

Well, that does not mean, that it should cause problems.
When programming G-code (at the machine) there can be several commands in one 
line. Its the interpreters job to know sequencing of commands and when they 
arrive task-manager, they already should be single commands.
Though multiple commands can share the same source line.

Reinhard




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

Re: [Emc-developers] Emc-developers Digest, Vol 168, Issue 75

[Juergen Gnoss]

I think what the interpreter is actually doing is a result of different 
interpretation of the term "interpreter"
There is a difference in interpreting g-code or user commands/inputs, even 
further in the sense of g-code,
where does the g-code actual come from? A file or MDI.

I think I'm not the only one that's missing some hairs on the forehead already 
finding an intelligent
solution for that.

Here a really loose and initial idea (just brainstorming)

As Reinhard mentioned, glue logic goes into the task-manager, that should be 
kind of a server.
Lot's of different modules get loaded based on configuration. That modules 
register their functions they
provide on the server.
The server decides what function from what module should be called in order to 
get the desired result.
So if there is a module ATC, it has to know what IO's have to be managed in 
order to do it's job, same on
manual tool change. Both modules are mutual exclusive and provide functions like
Prepare_Tool(X)
Change_Tool()
After Tool change the task-manager calls Apply_Offsets() and whatever module 
provides that function has
to do what's expected and has to know where and how to get it's information.

If the motion queue is made of a few rolling buffers and does pull the content 
of that buffers from task-manager
rather than get pushed into it, it's far more easy to keep track of the machine 
state.
Task-manager splits motion commands into "motion blocks", caring for motion 
logic not for filled buffers, and
knows the order in what they should be executed. If motion asks for the next 
block, it gets transferred into the free
buffer, if motion is done with one buffer it switches to the next and requests 
new data. So motion knows what buffer
and what position in the buffer it is, and can return that if task-manager asks 
for that, task manager has to know
what to do next.

Sounds a lot of work, but that relativates to a lot of modules with a small 
amount of code each.
So maintenance should profit from that as well.

ju



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

Re: [Emc-developers] fixture offset

[Reinhard]

On Sonntag, 19. April 2020, 07:56:12 CEST Chris Morley wrote:
> Motion does the movement planning so would be the one to know when to stop
> before breaking limits.

Well, if motion does the movement planning, than motion performs taskmanagers 
job. Movement planning is not motion.
And if motion does the movement planning, it should of cause know about single 
step or auto mode and should know about g-code lines and machine commands.

Very weird design.




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

Re: [Emc-developers] fixture offset

[Chris Morley]

On 2020-04-18 10:50 p.m., Reinhard wrote:

On Sonntag, 19. April 2020, 07:45:13 CEST Chris Morley wrote:

Now if you want motion to do such things as step each line of gcode,

Well, motion should not step.

It's the task-manager, that should step.
The difference of a motion command in single step or auto mode is the speed at
begin and end of that motion.
In singlestep both start and end speed are set to 0 - in automode they
correspond to the neighbor motion and may be on path parameters too.


Reinhard


The problem become that motion commands and gcode are not one to one.




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