On 06/09/2020 03:07 PM, andy pugh wrote:
I have a simple test, but I am far from sure that it exercises the same bug.
#!/bin/bash
for PASS in $(seq 1 10); do
echo starting pass ${PASS}
insmod /usr/realtime-4.14.174-rtai-amd64/modules/rtai_hal.ko
insmod /usr/realtime-4.14.174-
>Why? Has anyone indicated a reason why not? If some has, perhaps this
>thread should be exploring ways to aleaviate that perceived pain.
I think that is a different issue which might warrant a separate thread. A
formal mechanism to connect sponsors with interested developers would be
useful.
But
On Tuesday 09 June 2020 20:24:09 Rod Webster wrote:
> >Well maybe they could poke some resources towards helping instead of
>
> coming along for a free ride.
>
> Well they are more than happy to do that and have offered to engage an
> experienced developer several times but nobody seems to care...
>Well maybe they could poke some resources towards helping instead of
coming along for a free ride.
Well they are more than happy to do that and have offered to engage an
experienced developer several times but nobody seems to care... and emails
remain unanswered...
Its a long haul to understand t
How many are deterred from trying linuxcnc because its so dated?
I didn't realize we into looking at it from a marketing angle and 2.8 is not
dated and is easy to get.
> On 10 Jun 2020, at 8:35 am, Rod Webster wrote:
>
> We have at
> least one manufacturer wanting to adopt it.
Well maybe the
Needless to say, I'm more than thankful to everyone here for the efforts.
El mar., 9 jun. 2020 21:13, Leonardo Marsaglia
escribió:
> Not even close from being a developer. But I have to say we have three
> machines in production five days a week. They are all working with Wheezy
> and RTAI. I've
Not even close from being a developer. But I have to say we have three
machines in production five days a week. They are all working with Wheezy
and RTAI. I've tried running PREEMPT-RT with Stretch on the Mazak and I had
serious latency problems that made the system impossible to work with so I
th
>I don't really understand the need to rush it out right now. I know it has
been a long time coming but if it seems this bug can be fixed in the
foreseeable future we may as well wait a bit longer.
>If folk need 2.8 it is really not too difficult to get.
But Phill, we said that two years ago..
Well, how often are isos made? If it's every 5 years or something like that,
then I'd say what's a few more weeks or a month? If Paolo doesn't respond or
can't figure it out in time for us, and there's a big need for a new iso right
away, then leaving it out of the disc image wouldn't be a bad o
I don't really understand the need to rush it out right now. I know it has been
a long time coming but if it seems this bug can be fixed in the foreseeable
future we may as well wait a bit longer.
If folk need 2.8 it is really not too difficult to get.
> On 10 Jun 2020, at 8:35 am, Rod Webster
I'm not seeing where RTAI is being removed from LinuxCNC only
suggestions so far say release preempt-rt now and hold RTAI ISO until
the bug can be sorted out. It's not good to hold back at least a portion
of 2.8 when they are used for different reasons.
I don't know you but I appreciate any effort
On Tue, 9 Jun 2020 at 21:49, Alec Ari via Emc-developers
wrote:
> Has Paolo looked into this? Has anyone asked him?
I just subscribed to the RTAI mailing list and asked there.
(But it is moderated, so my message awaits moderation)
--
atp
"A motorcycle is a bicycle with a pandemonium attachment
I'm not seeing where RTAI is being removed from LinuxCNC only
suggestions so far say release preempt-rt now and hold RTAI ISO until
the bug can be sorted out. It's not good to hold back at least a portion
of 2.8 when they are used for different reasons.
I don't know you but I appreciate any ef
Thanks Andy. It would be a shame if all of the RTAI support in LinuxCNC
disappeared because of a bug. Has Paolo looked into this? Has anyone asked him?
On a side note, if your machine has a problem, do you just junk it or try to
work through it?
___
So there are a few people here that care about my efforts, which is great and I
thank you for that, but if RTAI support gets removed from LinuxCNC, it all
becomes meaningless, and it will most likely never enter the tree again after
that point. Paolo is not aware of this bug yet, and I don't thi
On Tue, 9 Jun 2020, Alec Ari via Emc-developers wrote:
Date: Tue, 9 Jun 2020 19:56:32 + (UTC)
From: Alec Ari via Emc-developers
To: EMC developers
Cc: Alec Ari
Subject: Re: [Emc-developers] 2.8 Situation
I want what I want because I'm five and I want it now. I spent 6 years working
my a
If the crash happens with this, then Poalo would definitely look into it:
#!/bin/bash
for PASS in $(seq 1 10); do
echo starting pass ${PASS}
insmod /usr/realtime-4.14.174-rtai-amd64/modules/rtai_hal.ko
insmod /usr/realtime-4.14.174-rtai-amd64/modules/rtai_sched.ko
rmmod rtai_sc
Alec:
Waving hand here!
I know from bitter experience that *some* users of open-source software
expect you do give your 24/7 to them to help solve their problems.
Others are very thankful and considerate of the open-source.
Go with with the 99.9% who are grateful, and, sometimes out-of-the-blue
On Tue, 9 Jun 2020 at 20:59, Jon Elson wrote:
> But, if you can strip the issue down to a simple test that
> only requires RTAI, maybe it'll get him
> motivated.
I have a simple test, but I am far from sure that it exercises the same bug.
#!/bin/bash
for PASS in $(seq 1 10); do
echo sta
On Tue, 9 Jun 2020 at 20:57, Alec Ari via Emc-developers
wrote:
>
> I want what I want because I'm five and I want it now. I spent 6 years
> working my ass off on RTAI and none of you could give a fuck less.
I, for one, am extremely grateful for your efforts with RTAI.
--
atp
"A motorcycle is
"threads" creates a module called "HAL__fast" and then exits itself
without exiting the new module:
Jun 9 20:06:26 rm-one kernel: [ 3186.136955] HAL: initializing
component '__fast'
Jun 9 20:06:26 rm-one kernel: [ 3186.136956] RTAPI: initing module HAL___fast
Jun 9 20:06:26 rm-one kernel: [ 318
On 06/09/2020 10:03 AM, andy pugh wrote:
On Tue, 9 Jun 2020 at 15:49, Jon Elson wrote:
Now that you've narrowed it down to abs
It's not abs. That's just the alphabetically first test.
It crashes (more slowly) even if you just do realtime start / halrun -U in
a loop.
Ugh! Well, Paolo is th
I want what I want because I'm five and I want it now. I spent 6 years working
my ass off on RTAI and none of you could give a fuck less.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/
I'd second Rod Webster's suggestion.
Leave RTAI on the curb, focus the project, and move forward.
Those motivated to get RTAI supported again have an obvious work item they can
contribute to if its important to them. It can always be brought back in if
there are folks motivated for it and will
I am for fast 2.8 get stable .. if my voice count.
Normal user
On Tue, Jun 9, 2020, 18:30 wrote:
> RELEASE 2.8...
>
> As JT mentioned, if/when the rtai problem gets resolved, then release that
> particular version.
>
> Roguish
> Using LinuxCNC since '06
>
>
>
> -Original Message
RELEASE 2.8...
As JT mentioned, if/when the rtai problem gets resolved, then release that
particular version.
Roguish
Using LinuxCNC since '06
-Original Message-
From: andy pugh
Sent: Tuesday, June 09, 2020 3:26 AM
To: EMC developers
Subject: [Emc-developers] 2.8 Situat
On Tue, 9 Jun 2020 at 15:49, Jon Elson wrote:
>
> Now that you've narrowed it down to abs
It's not abs. That's just the alphabetically first test.
It crashes (more slowly) even if you just do realtime start / halrun -U in
a loop.
--
atp
"A motorcycle is a bicycle with a pandemonium attachmen
At this point I would suggest releasing 2.8 with preempt-rt ISO and if
at a later
date RTAI becomes stable release that ISO.
Just my 2¢ well with inflation maybe my $2
JT
On 6/9/2020 5:25 AM, andy pugh wrote:
I had hoped to release 2.8 at Easter, but hit a roadblock.
My plan was to offer bot
On 06/09/2020 05:25 AM, andy pugh wrote:
Specifically a script that starts realtime, loads an instance of the abs
component and then exists will cause a kernel lock up after hundreds to
thousands of cycles.
Now that you've narrowed it down to abs (VERY good detective
work, there!) you might look
On Tue, 9 Jun 2020, andy pugh wrote:
Date: Tue, 9 Jun 2020 11:25:40 +0100
From: andy pugh
Reply-To: EMC developers
To: EMC developers
Subject: [Emc-developers] 2.8 Situation
I had hoped to release 2.8 at Easter, but hit a roadblock.
My plan was to offer both preempt-rt and RTAI ISOs for fre
>Not so, the situation has changed markedly since Alec did the work to make
>RTAI usable on 4.x.x 64-bit kernels.
I appreciate that you have expended enormous effort, But what I thought you
said is that despite that effort, you still have not got a result and you
did not know what to do.
My view i
On Tue, 9 Jun 2020 at 12:02, Rod Webster wrote:
> It appears there are no prospects to resolve the situation which has
> clearly been an issue since Wheezy went EOL over two years ago.
Not so, the situation has changed markedly since Alec did the work to make
RTAI usable on 4.x.x 64-bit kernels.
I know I'm not on the dev team but my take on this is that you have no
choice but to release 2.8 without RTAI.
It appears there are no prospects to resolve the situation which has
clearly been an issue since Wheezy went EOL over two years ago.
By withholding the release of V 2.8 for such an obscene
I had hoped to release 2.8 at Easter, but hit a roadblock.
My plan was to offer both preempt-rt and RTAI ISOs for fresh installs with
Debian Buster, and packages for both realtime systems for the other
supported OSs too.
Unfortunately, despite a lot of effort on the part of Alec and a lesser
amoun
34 matches
Mail list logo
