On Tuesday 22 December 2009 23:30:26 Stephen Wille Padnos wrote:
> Is there a particular reason why you're wedded to the 2.6.29 kernel?
I think that is the newest kernel the latest RTAI stable release supports.
--
Greetings, Michael.
On Tuesday 22 December 2009 23:09:41 Michael Buesch wrote:
> On Tuesday 22 December 2009 16:38:35 Jeff Epler wrote:
> > This is just a shot in the dark, but it seems to match several things
> > I'm seeing in the tracebacks -- SMP, x86-64, preempt, and irqs:
> >
On Tuesday 22 December 2009 16:38:35 Jeff Epler wrote:
> This is just a shot in the dark, but it seems to match several things
> I'm seeing in the tracebacks -- SMP, x86-64, preempt, and irqs:
> http://article.gmane.org/gmane.linux.kernel.adeos.general/1481
> http://article.gmane.org/gmane.
On Tuesday 22 December 2009 16:53:58 Chris Radek wrote:
> You are right that the first one is real,
Yeah I reproduced it twice with almost identical results (except the followup
oopses. Which
is why I think we can ignore these).
> and it is obviously an emc process.
Well, no. That is coincidenc
On Tuesday 22 December 2009 15:53:27 Stephen Wille Padnos wrote:
> Just to be very clear here - does this mean that you compiled emc 2.3.3
> from source against your SMP kernel?
emc-2.3.4
> One thing I noticed is that the GeForce driver is explicitly mentioned
> or implicit on basically every o
On Tuesday 22 December 2009 15:32:33 Michael Buesch wrote:
> And 4 of the 5 oopses obviously are followup-oopses to the first one.
Also notice that the first oops happens in interrupt context, so "comm" is
meaningless.
--
Greet
On Tuesday 22 December 2009 15:21:04 Chris Radek wrote:
> On Tue, Dec 22, 2009 at 11:51:31AM +0100, Michael Buesch wrote:
> > Here's an interesting crash.
> > It sometimes happens on EMC load. It's more or less reproducible by fireing
> > up
> > and shutting
Here's an interesting crash.
It sometimes happens on EMC load. It's more or less reproducible by fireing up
and shutting down EMC in a row. Something like 20 or 30 tries are sometimes
required to reproduce.
So, what is this? Well, I'm fairly certain that we have a race condition here.
This crash
On Saturday 21 November 2009 07:13:38 Jon Elson wrote:
> So, does anyone know anything about the sticky jog arrows?
> I know this problem has been around since 1998 and the earliest
> GUI. But, it seems like it might be worse since I just updated to the
> development head a couple days ago. Or, i
On Monday 09 November 2009 23:19:06 Chris Radek wrote:
> On Mon, Nov 09, 2009 at 11:14:41PM +0100, Michael Buesch wrote:
> >
> > Hm, I do still get it.
> > Routing to the machine seems to work, however. I can ping and traceroute it.
> >
> > m...@homer:~/develop/
On Monday 09 November 2009 23:11:52 Michael Buesch wrote:
> On Monday 09 November 2009 23:02:31 Chris Radek wrote:
> > On Mon, Nov 09, 2009 at 10:37:59PM +0100, Michael Buesch wrote:
> > > Is the git repository down?
> > > I always get "The remote end hung up u
On Monday 09 November 2009 23:02:31 Chris Radek wrote:
> On Mon, Nov 09, 2009 at 10:37:59PM +0100, Michael Buesch wrote:
> > Is the git repository down?
> > I always get "The remote end hung up unexpectedly" when trying to pull.
>
> It was down for about 10 minutes
Is the git repository down?
I always get "The remote end hung up unexpectedly" when trying to pull.
--
Greetings, Michael.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify y
On Monday 12 October 2009 23:09:13 Jeff Epler wrote:
> by implementing rtai/rtapi-inspired threads and shared memory (the two
One question about SHM. In the rtapi_app concept, is SHM ever accessed from
outside of rtapi_app, or is it only used for communication between the RT
threads?
(Sorry for s
On Monday 12 October 2009 23:09:13 Jeff Epler wrote:
> I suppose that since Michael Buesch beat me to the punch with something
> that works, I should at least mention the work I had done towards
> running emc on "realtime-linux".
>
> Michael's work adopts the "
So I created a quilt directory on my server where I will always publish my
latest work on this.
Just go to
http://bu3sch.de/patches/emc-linux-rt/
The constant link to the latest patchset is
http://bu3sch.de/patches/emc-linux-rt/LATEST/
There you can get the quilt series, split out and as tarball
On Sunday 11 October 2009 17:37:47 Michael Buesch wrote:
> On Sunday 11 October 2009 16:36:38 Jeff Epler wrote:
> > This is very interesting -- thanks for working on it. I have a few
> > questions, though.
> >
> > How do hardware drivers work with --realtime=linux
On Sunday 11 October 2009 16:48:35 Kenneth Lerman wrote:
> I find that --enable-simulator works fine in a virtual machine. Will
> --realtime=linux also work? If not, I think we need to keep
> --enable-simulator.
well, realtime=linux does some additional things, like memory locking, setuid
raw-io
On Sunday 11 October 2009 16:36:38 Jeff Epler wrote:
> This is very interesting -- thanks for working on it. I have a few
> questions, though.
>
> How do hardware drivers work with --realtime=linux?
They don't, yet. I'm currently focussing on the latency tester.
However, in x86 it's easy to do r
On Sunday 11 October 2009 00:19:57 Michael Buesch wrote:
> This patch is an attempt to port EMC to run on realtime capable linux
> without a realtime hypervisor.
>
> Linux-RT currently is not ready to support the hard realtime requirements
> of EMC, but I think it's a good i
This patch is an attempt to port EMC to run on realtime capable linux
without a realtime hypervisor.
Linux-RT currently is not ready to support the hard realtime requirements
of EMC, but I think it's a good idea to start playing with it.
The patch is based on an earlier patchset published by Jeff
On Thursday 13 August 2009 19:44:08 Jon Elson wrote:
> changed. I was hoping that the rtai folks would be more responsive, or
> maybe have a subgroup working on this. Or maybe I am asking in the
> wrong place, and there is a separate group working on the ARM platforms.
I think anything but x86
ror message on the broken program. It simply
iterates once
and then finishes the program. I think it should print an error message about
mismatched
O words.
>
> Ken
>
> Michael Buesch wrote:
> > On Tuesday 14 July 2009 15:04:55 Michael Buesch wrote:
> >
> >> On
On a simulated 3axis setup, the following program runs fine and
evaluates the while loop 10 times as expected.
But on my one-axis test machine (only one X axis), the while loop
is only evaluated once. The axis does move correctly, but the loop
is exited after the first iteration.
Any ideas?
%
g17
On Tuesday 14 July 2009 15:04:55 Michael Buesch wrote:
> On a simulated 3axis setup, the following program runs fine and
> evaluates the while loop 10 times as expected.
> But on my one-axis test machine (only one X axis), the while loop
> is only evaluated once. The axis does move co
On Saturday 27 June 2009 22:04:30 Stephen Wille Padnos wrote:
> Michael Buesch wrote:
>
> >Is the GIT server down?
> >
> >m...@homer:~/develop/git$ git clone git://git.linuxcnc.org/git/emc2.git
> >Initialized empty Git repository in /home/mb/develop/git/emc2/.git/
&g
Is the GIT server down?
m...@homer:~/develop/git$ git clone git://git.linuxcnc.org/git/emc2.git
Initialized empty Git repository in /home/mb/develop/git/emc2/.git/
fatal: The remote end hung up unexpectedly
fetch-pack from 'git://git.linuxcnc.org/git/emc2.git' failed.
--
Greetings, Michael.
---
On Saturday 20 June 2009 11:43:03 paul_c wrote:
> On Friday 19 June 2009, Michael Buesch wrote:
> > I think you should start to explain _why_ you don't want git.
> > What are your actual problems with git? What don't you like about git?
> > Which features ar
On Friday 19 June 2009 18:43:00 paul_c wrote:
> On Thursday 18 June 2009, Kenneth Lerman wrote:
> > How much of an invitation do you (or they) need?
> > Even though the wiki page is editable by anyone; the history is not.
>
> "We have decided If you have been selected, you may cast your yes vo
On Friday 05 June 2009 18:39:05 Maxime Lemonnier wrote:
> bzr offer an svn-mode
So does git.
--
Greetings, Michael.
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option th
On Tuesday 19 May 2009 22:33:50 Jeff Epler wrote:
> On Tue, May 19, 2009 at 03:51:56PM +0200, Michael Buesch wrote:
> > image-to-gcode (CVS trunk) throws the following error.
>
> this is due to a numarray bug on amd64 systems.
Doh, thanks that explains it :)
> Perhaps the th
image-to-gcode (CVS trunk) throws the following error.
Default options are used (.image2gcoderc deleted)
It does not do this on all of my systems. The powerpc system works, whereas
the x86_64 machine fails.
Traceback (most recent call last):
File "./image-to-gcode", line 818, in
main()
Fi
As soon as the "Roughing offset" field is cleared (empty string),
image-to-gcode (CVS trunk) throws the following exception:
m...@frink:~/emc2-current/bin$ ./image-to-gcode ../nc_files/torus.png
Exception in Tkinter callback
Traceback (most recent call last):
File "/usr/lib/python2.5/lib-tk/Tk
On Saturday 16 May 2009 00:09:16 Jeff Epler wrote:
> On Fri, May 15, 2009 at 11:03:50PM +0200, Michael Buesch wrote:
> > Hi,
> >
> > I'm wondering if it's possible to manipulate #parameters while the NC
> > program
> > is paused.
>
> No, it&
Hi,
I'm wondering if it's possible to manipulate #parameters while the NC program
is paused.
One use case for me would be to periodically do F#12345 in the program, so I
could
pause the program and adjust various feedrates without stop/modify/restart.
If this is not currently possible, how hard
nk, but it
may also need this) which fixes a hard machine crash due to
invalid opcodes.
Signed-off-by; Michael Buesch
---
Index: 2.3-branch/src/Makefile
===
--- 2.3-branch.orig/src/Makefile2009-05-02 16:35:44.0 +02
On Wednesday 29 April 2009 18:23:21 Jeff Epler wrote:
> On Wed, Apr 29, 2009 at 04:08:56PM +0200, Michael Buesch wrote:
> > These patches add facilities for convenient rapid jogging to Axis.
> > Rapid jogging will be accessible through a GUI button or the Keyboard shift
> >
This modifies the keyboard jog key behavior to use G0 speed while Shift is
pressed.
If shift is released, it will move at the feedrate-slider speed.
Signed-off-by: Michael Buesch
---
src/emc/usr_intf/axis/scripts/axis.py |2 ++
1 file changed, 2 insertions(+)
--- emc2.3-branch.orig/src
This patch adds two rapid-jog buttons to the Axis GUI that will
always jog the joints at G0 speed regardless of the feedrate slider setting.
Signed-off-by: Michael Buesch
---
share/axis/tcl/axis.tcl | 54 +-
src/emc/usr_intf/axis/scripts/axis.py
These patches add facilities for convenient rapid jogging to Axis.
Rapid jogging will be accessible through a GUI button or the Keyboard shift key.
This is to avoid the need to shift the feed-rate slider for rapid movement.
This is useful, if manual jogging is used for very simple milling tasks. S
On Wednesday 29 April 2009 12:22:12 Alex Joni wrote:
> rev. 1.291 http://cvs.linuxcnc.org/cvs/emc2/src/Makefile
> has the patch applied.
What about putting it into 2.3-branch, too?
--
Greetings, Michael.
--
Register Now
Any news on this one? Is this going to be applied?
On Friday 24 April 2009 19:35:21 Michael Buesch wrote:
> This fixes the EMC2 simulator compilation on PowerPC-64.
>
> The check should probably turned upside down and check for
> (arch==x86 || arch==x86_64), but I don't know w
4.
Of course other nonppc-nonX86 arches are still broken after this patch.
Signed-off-by: Michael Buesch
---
Index: src/Makefile
===
--- src.orig/Makefile 2009-04-24 19:28:32.0 +0200
+++ src/Makefile2009-04-24
On Monday 20 April 2009 06:42:49 Mario. wrote:
> None of the features are directly relevant to EMC2, more like that
> WiFi, UI, 3D, etc. works out of the box and such.
Just out of personal interest (I'm involved in Linux wireless development),
which WiFi chip do you use and how does it affect real
On Tuesday 24 March 2009 01:01:55 Jeff Epler wrote:
> > -EXTRA_CFLAGS += -msse -msse2
> > +EXTRA_CFLAGS += -msse
>
> I still have not been able to test this on an x86_64/rtai system, but I
> put it on TRUNK anyway.
What about 2.2 and 2.3? Will you put it into these branches after you tested it?
On Monday 16 March 2009 13:33:58 Mario. wrote:
> how do SSE2 SSE3 SSE4 and such instructions affect latency in terms of
> context switching?
> is there any noticeable difference?
I think they should not affect context switching in any way.
And the code that crashes with -msse2 is inside of the ke
that_ computational expensive. CPUs that
support the sse2 flags are way fast enough to run EMC2 without any problems
anyway.
Signed-off-by: Michael Buesch
---
Thanks to paul_c for suggesting this fix.
Index: emc2-2.2.8/src/Mak
On Monday 02 March 2009 02:40:17 paul_c wrote:
> As far as I am aware, ARM is the only architecture known to have issues with
> inline code and gcc-4.3. Using gcc-4.3 with i386 & x86_64 should not cause
> problems. What is more likely is one of the extended registers is being
> trashed as soon a
On Sunday 01 March 2009 20:03:08 Jon Elson wrote:
> Michael Buesch wrote:
> > On Friday 27 February 2009 21:58:50 Jeff Epler wrote:
> >
> >> On Fri, Feb 27, 2009 at 09:42:25PM +0100, Michael Buesch wrote:
> >>
> >>> Does emc use stuf
On Friday 27 February 2009 21:58:50 Jeff Epler wrote:
> On Fri, Feb 27, 2009 at 09:42:25PM +0100, Michael Buesch wrote:
> > Does emc use stuff like inline assembly or other special stuff
> > inside of the kernel?
>
> A bit, but not much. rtapi_bitops.h and rtapi_math_i38
On Friday 27 February 2009 21:29:42 Michael Buesch wrote:
> Invalid opcode looks interesting. Compiler bug?
> I'll try an older compiler...
Yes this is related to miscompilation.
Doing "export CC=gcc-3.4" before ./configure resolves the issue.
It does not crash anymore.
On Friday 27 February 2009 21:08:02 Michael Buesch wrote:
> On Friday 27 February 2009 20:56:52 Michael Buesch wrote:
> > On Friday 27 February 2009 20:33:24 Chris Radek wrote:
> > > On Fri, Feb 27, 2009 at 06:41:42PM +0100, Michael Buesch wrote:
> > > > It always c
On Friday 27 February 2009 20:56:52 Michael Buesch wrote:
> On Friday 27 February 2009 20:33:24 Chris Radek wrote:
> > On Fri, Feb 27, 2009 at 06:41:42PM +0100, Michael Buesch wrote:
> > > It always crashes a few microns before we reach the destination in Z.
> > > I thin
On Friday 27 February 2009 20:33:24 Chris Radek wrote:
> On Fri, Feb 27, 2009 at 06:41:42PM +0100, Michael Buesch wrote:
> > It always crashes a few microns before we reach the destination in Z.
> > I think this might have something to do with the backlash compensation.
>
>
On Friday 27 February 2009 18:41:42 Michael Buesch wrote:
> Hi,
>
> The following NC program reproducibly crashes my AMD64 machine running EMC2.2
> stable branch
> as of last week (I don't remember the exact date).
> It's either some kernel crash or a RTAI locku
Hi,
The following NC program reproducibly crashes my AMD64 machine running EMC2.2
stable branch
as of last week (I don't remember the exact date).
It's either some kernel crash or a RTAI lockup.
%
G17 G40 G49 G80 G90 G94 G61 G21
G54
G0 X0 Y0 Z30
G0 Z1
G1 Z-0.5F
On Tuesday 17 February 2009 00:21:15 Alex Joni wrote:
> I don't think linux-rt will get to the point where it replaces RTAI. They
> are different things, with different goals.
> But nonetheless linux-rt can be something usefull to run a servo system for
> example.
Yeah well. Currently it's not p
Hi,
Did somebody consider linux-rt (not RT-Linux) for EMC2?
Here's an LWN article about it:
http://lwn.net/Articles/319544/ (subscribers only. Mail me in private
and I can send you a free link to the article).
It seems that with linux-rt almost all RT stuff can run in userspace.
In fact, I think
On Saturday 07 February 2009 18:08:21 Michael Buesch wrote:
> Hi,
>
> I'm trying to compile emc2 stable branch on PPC64 (32bit userland) in
> simulator mode.
> The distribution is Debian Lenny, gcc-4.3.3, ld-2.18.0.20080103.
I'm sorry, this is Debian Sid.
It works pr
Hi,
I'm trying to compile emc2 stable branch on PPC64 (32bit userland) in
simulator mode.
The distribution is Debian Lenny, gcc-4.3.3, ld-2.18.0.20080103.
I get a linker error:
ld: objects/biquad.tmp(.text+0x330): R_PPC_PLTREL24 reloc against local symbol
objects/biquad.tmp: could not read symbo
On Friday 21 November 2008 05:07:50 Sebastian Kuzminsky wrote:
> Sebastian Kuzminsky wrote:
> > --- nml.cc 2008/04/27 01:43:50 1.18
> > +++ nml.cc 2008/11/21 02:59:48 1.19
> > @@ -68,6 +68,7 @@
> > {
> > if (cfg_file == NULL) {
> > default_nml_config_file = NULL;
> > +re
On Friday 14 November 2008 23:34:27 Jon Elson wrote:
> Michael Buesch wrote:
> > I don't think there is a solution for this, however.
> > If you want to run a component of the repository (be it the makefile or
> > the setuid programs itself) as root, you need to trust yo
On Friday 14 November 2008 21:58:56 Stephen Wille Padnos wrote:
> These scripts don't run on the CVS server,
Ok, I thought this would run on the machine running the server.
--
Greetings Michael.
-
This SF.Net email is spons
On Friday 14 November 2008 21:09:43 John Kasunich wrote:
> Sebastian Kuzminsky wrote:
>
> > # let the farm user run "sudo make setuid" without a password by
> > adding this line to /etc/sudoers:
> > farmer ALL = ALL, NOPASSWD: /usr/bin/make setuid
> >
>
> This part raises a red flag f
On Thursday 13 November 2008 14:42:58 Jeff Epler wrote:
> Checked in on the 2.2 branch
Thanks a lot, jeff :)
--
Greetings Michael.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coo
On Thursday 13 November 2008 02:45:17 Stephen Wille Padnos wrote:
> Michael Buesch wrote:
>
> >See kernel.h in current kernels.
> >It implements clamp() as a typesafe macro.
> >That's what the #ifdef is all about. It avoids the nameclash and uses
> &
On Thursday 13 November 2008 00:28:52 Stephen Wille Padnos wrote:
> I'm thinking of something like the kernel macro:
>
> ((v)<(sub)?(sub):((v)>(sup)?(sup):(v)))
>
> That has the advantage and possible disadvantage of not specifying a
> type. You could theoretically compare an into int to float
Hi,
Is there a chance of porting this trivial fix
http://cvs.linuxcnc.org/cvs/emc2/src/hal/components/limit2.comp.diff?r1=1.5;r2=1.6
to v2_2_branch?
I'm currently running 2.2-branch-cvs on a 2.6.26.8 kernel and it's
a little bit inconvenient to keep this tiny compiletime fix around
in the local c
Whoops, this was already merged on Sep 24th.
Sorry for the noise.
On Friday 07 November 2008 11:20:46 Michael Buesch wrote:
> This patch fixes a very hard to debug crash (took me about 5 hours)
> on an x86_64 kernel.
> It might not crash on an i386 kernel, because of the loos
This patch fixes a very hard to debug crash (took me about 5 hours)
on an x86_64 kernel.
It might not crash on an i386 kernel, because of the looser memory
requirements. But in any case, it will access uninitialized memory.
On x86_64 this will cause a machine crash on kernel shutdown.
This is the
The following error happens when compiling emc2 on a recent kernel:
hal/components/limit2.comp:14: error: expected identifier or ‘(’ before ‘{’
token
hal/components/limit2.comp: In function ‘_’:
hal/components/limit2.comp:22: warning: comparison of distinct pointer types
lacks a cast
hal/compone
On Saturday 04 October 2008 22:58:33 Jeff Epler wrote:
> On Sat, Oct 04, 2008 at 08:36:56PM +0200, Michael Buesch wrote:
> > Isn't it possible to implement a check and exit with an error message?
> > Where is it segfaulting? Does the kernel segfault us if we try to memlock
>
On Friday 03 October 2008 20:09:49 Michael Buesch wrote:
> On Friday 03 October 2008 14:04:28 Jeff Epler wrote:
> > Have you followed the instructions for modifying the
> > /etc/security/memlock.conf file shown here?
> > http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Debi
On Friday 03 October 2008 14:04:28 Jeff Epler wrote:
> Have you followed the instructions for modifying the
> /etc/security/memlock.conf file shown here?
> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Debian_Lenny_Compile_RTAI#Memlock_Size
Ok, no. I didn't know such documentation for lenny does exi
On Thursday 02 October 2008 23:20:28 Michael Buesch wrote:
> Hi,
>
> Did anybody try to run emc-2.2.6 on an x86_64 kernel?
> I just tried it, but it just segfaults in halcmd.
> I'm not sure what happens exactly, yet. I can provide some logs
> tomorrow (I'm currently
Hi,
Did anybody try to run emc-2.2.6 on an x86_64 kernel?
I just tried it, but it just segfaults in halcmd.
I'm not sure what happens exactly, yet. I can provide some logs
tomorrow (I'm currently not at the machine).
I tried with latest rtai, linux-2.6.24.7 and emc 2.2.6 on
a debian lenny system.
On Saturday 05 July 2008 21:57:10 Michael Buesch wrote:
> There's one little thing that's a little bit strange. I think
> it comes from my limited understanding of the realtime stuff, however.
> If the GPIO chip driver does use spin_unlock_irqrestore in the GPIO port
> write
On Saturday 05 July 2008 21:05:51 Alex Joni wrote:
> Or does it rely on linux stuff which makes it less "realtime"?
I forgot to answer that question.
Yes, it calles into the linux GPIO API. So this makes it
"less realtime". However that depends on the device that provides
the GPIO. There are devi
On Saturday 05 July 2008 21:05:51 Alex Joni wrote:
> Very nice work.
> We will probably include this asap in TRUNK ..
>
> I'm not very familiar with Linux GPIO, does the current driver work in
> realtime?
> Or does it rely on linux stuff which makes it less "realtime"?
>
> Thanks for the hard wo
970-01-01 00:00:00.0 +
+++ emc2/src/hal/drivers/hal_linux_gpio.c 2008-07-05 17:49:55.0
+0200
@@ -0,0 +1,341 @@
+/*
+ * Linux GPIO HAL driver
+ *
+ * Copyright 2008 Michael Buesch <[EMAIL PROTECTED]>
+ *
+ * Derived from the HAL skeleton:
+ * Copyright John Kasun
80 matches
Mail list logo
