* Can anyone else running a BeagleBone system try using the mini GUI and
enabling the backplot while a program is running? I'd like to know I'm
not the only one seeing this issue.
I have noticed this issue on RPi as well, the motors would slowdown or pause
whenever the graphics load is too
[this is mostly for Sascha who has agreed to review the work (and maybe more
than that ;), plus any folks desiring to get their hands on code which shows
how zmq and protobuf can be used in LinuxCNC]
The linuxcnc module is functionally complete as it can submit commands either
with NML, or
Woa... Nice step forward!
On Aug 12 2013 8:10 AM, Michael Haberler wrote:
[this is mostly for Sascha who has agreed to review the work (and
maybe more than that ;), plus any folks desiring to get their hands
on
code which shows how zmq and protobuf can be used in LinuxCNC]
The linuxcnc
On 08/12/2013 05:51 AM, GP Orcullo wrote:
* Can anyone else running a BeagleBone system try using the mini
GUI and enabling the backplot while a program is running? I'd like
to know I'm not the only one seeing this issue.
I have noticed this issue on RPi as well, the motors would slowdown
On 08/11/2013 05:00 AM, Schooner wrote:
I have Sebs 3.4.55-1-rtai kernel, plus my own 3.5.7-rtai kernel running
on 12.04.2 using RTAI-3.9.1 fixed by Shabby and memleak
I also have my own 3.5.7-rtai kernel running on Debian 7.1 using the
magma realtime from the current CVS
(there are
On Mon, Aug 12, 2013, at 11:12 AM, Kirk Wallace wrote:
On 08/12/2013 05:51 AM, GP Orcullo wrote:
* Can anyone else running a BeagleBone system try using the mini
GUI and enabling the backplot while a program is running? I'd like
to know I'm not the only one seeing this issue.
I
Is that the compile error that looks similar to this?
In file included from /usr/include/math.h:28:0,
from wherever:
/usr/include/features.h:324:26: fatal error: bits/predefs.h: \
No such file or directory
That is the indication of the problem yes. /bits /asm /gnu
On Monday 12 August 2013 11:34:12 Kirk Wallace did opine:
On 08/12/2013 05:51 AM, GP Orcullo wrote:
* Can anyone else running a BeagleBone system try using the mini
GUI and enabling the backplot while a program is running? I'd like
to know I'm not the only one seeing this issue.
I
On 8/12/2013 10:48 AM, John Kasunich wrote:
I think Kirk's prespective is right on target. A real-time system that
misses timing targets is not a very good real time system. A real-time
system that misses timing targets and doesn't even know it isn't a
real-time system at all.
Yes,
On 8/12/2013 10:58 AM, Gene Heskett wrote:
That said, even with the latest 2.5.3, I see a realtime error advisory, but
it may not show up until the next day of uptime for LCNC itself. And I
have never detected that the machine itself, if in motion at the time, was
ever affected.
I've had
On Monday 12 August 2013 12:36:23 Charles Steinkuehler did opine:
On 8/12/2013 10:58 AM, Gene Heskett wrote:
That said, even with the latest 2.5.3, I see a realtime error
advisory, but it may not show up until the next day of uptime for
LCNC itself. And I have never detected that the
Am 12.08.2013 um 17:48 schrieb John Kasunich jmkasun...@fastmail.fm:
I wonder how all these new RTOSes and new platforms measure
the passage of real time?
there is no need to wonder, it's all in the open, APIs used and all, and the
timing API's are unchanged over at least 10 months:
On Mon, Aug 12, 2013, at 12:09 PM, Charles Steinkuehler wrote:
On 8/12/2013 10:48 AM, John Kasunich wrote:
I think Kirk's prespective is right on target. A real-time system that
misses timing targets is not a very good real time system. A real-time
system that misses timing targets
On Mon, Aug 12, 2013, at 12:15 PM, Charles Steinkuehler wrote:
On 8/12/2013 10:58 AM, Gene Heskett wrote:
That said, even with the latest 2.5.3, I see a realtime error advisory, but
it may not show up until the next day of uptime for LCNC itself. And I
have never detected that the
Hi Sascha,
I managed to delete your reply to this email. I'm copying the text from
the sf archive, but replying to myself, so your client's threading may
get messed up. ;(
Since EtherCAT libs will be missing on most systems, library detection
would need to be added configure.in, and driver
Request for testing:
Can someone with a traditional x86 system test master and one of the
RTOS integration previews to see if you can reproduce this problem on
x86 with RTAI?
More details inline...
On 8/12/2013 11:56 AM, John Kasunich wrote:
On Mon, Aug 12, 2013, at 12:09 PM, Charles
just reading through tcl/mini.tcl by an author not present around here any more
there is some backplot init code which looks suspicious:
emc is paused during backplot init:
On Tue, 2013-08-13 at 01:00 +0200, Michael Haberler wrote:
just reading through tcl/mini.tcl by an author not present around here any
more
there is some backplot init code which looks suspicious:
emc is paused during backplot init:
Am 13.08.2013 um 01:12 schrieb dave dengv...@charter.net:
On Tue, 2013-08-13 at 01:00 +0200, Michael Haberler wrote:
just reading through tcl/mini.tcl by an author not present around here any
more
there is some backplot init code which looks suspicious:
emc is paused during backplot
I just fixed (I think) a very serious bug in the Resolver driver on
64-bit systems
It was in some code that promotes a 32-bit register into a 64-bit accumulator.
This is done by subtracting the old 32-bit register value from the new
one, and adding the difference to the accumulator.
This works
On Monday 12 August 2013 20:45:22 andy pugh did opine:
I just fixed (I think) a very serious bug in the Resolver driver on
64-bit systems
It was in some code that promotes a 32-bit register into a 64-bit
accumulator.
This is done by subtracting the old 32-bit register value from the new
21 matches
Mail list logo
