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
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. Movemen
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 s
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.
_
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
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
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
s
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 whil
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 recalcu
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
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 pr
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 p
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
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 th
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 moto
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 th
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.
>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:
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
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/lin
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
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 t
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
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
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 dri
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 dro
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 becom
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
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 t
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 probl
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 nece
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
> 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 the
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
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 versi
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
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
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
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
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 b
40 matches
Mail list logo
