Back
[00:02:58] -!-
asdfasd has quit [Ping timeout: 245 seconds]
[00:05:44] -!-
Tom_itx has quit [Ping timeout: 265 seconds]
[00:05:54] Tom_L is now known as
Tom_itx
[00:08:10] -!-
zlog_ has quit [Ping timeout: 276 seconds]
[00:16:34] -!-
vladimirek has quit [Ping timeout: 272 seconds]
[00:21:08] -!-
Loetmichel has quit [Ping timeout: 240 seconds]
[00:41:07] -!-
micges has quit [Quit: Leaving]
[00:59:11] -!-
asdfasd has quit [Ping timeout: 252 seconds]
[01:03:37] -!-
jsr__ has quit [Remote host closed the connection]
[01:47:03] -!-
andypugh has quit [Quit: andypugh]
[01:47:49] <cradek> skunkworks__: spiral is a good test because the segments get shorter and shorter.
[01:50:56] <cradek> skunkworks__: I want to study and test this some more. It's tempting to put it in 2.5 if it passes all the tests we can come up with, but my better judgement would argue.
[01:57:24] toast2 is now known as
toastydeath
[02:17:08] -!-
demacus_ has quit [Ping timeout: 245 seconds]
[02:20:46] Connor2 is now known as
Connor_CNC
[02:49:02] -!-
dgarr [dgarr!~dgarrett@adsl-75-61-68-165.dsl.pltn13.sbcglobal.net] has joined #linuxcnc-devel
[02:51:56] <dgarr> updates for ngcgui, includes arc-making subroutines, for consideration:
http://www.panix.com/~dgarrett/stuff/ngcgui_update.mbox
[02:57:01] <skunkworks__> cradek: no issues here (although I have not been checkiing constraints.)
[02:57:18] <skunkworks__> tort runs about the same... (must be mostly large moves
[03:17:19] -!-
phantoxeD has quit [Ping timeout: 276 seconds]
[03:31:16] -!-
zlog has quit [Remote host closed the connection]
[03:31:19] -!-
Tom_itx has quit []
[03:53:31] -!-
elmo000 has quit [Read error: Connection reset by peer]
[04:28:04] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[04:43:18] -!-
Connor_CNC has quit [Read error: Connection reset by peer]
[04:45:59] Connor2 is now known as
Connor_CNC
[04:53:14] -!-
mhaberler has quit [Quit: mhaberler]
[05:02:08] -!-
Connor_CNC has quit [Read error: Connection reset by peer]
[05:03:56] -!-
Fox_Muldr has quit [Ping timeout: 265 seconds]
[05:05:01] cylly2 is now known as
Loetmichel
[05:15:33] -!-
dgarr has quit [Ping timeout: 248 seconds]
[05:24:04] fragalot_ is now known as
fragalot
[05:24:10] -!-
fragalot has quit [Changing host]
[05:35:33] -!-
vladimirek has quit [Remote host closed the connection]
[05:37:08] -!-
psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[05:41:46] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[05:45:00] -!-
pfred1 has quit [Quit: Lost terminal]
[06:09:58] <mhaberler> cradek: re 436aa8 - minor nit: I think the following line isnt needed (duplicate):
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/emc/kinematics/tp.c;h=ff228b1db69fc118074c85a5b8d7eef60bdc981d;hb=436aa886a1890767ce8a5cef9908c911749a363e#l657
[07:25:26] -!-
factor has quit [Read error: Connection reset by peer]
[07:53:17] <alex_joni> morning mhaberler
[07:53:25] <mhaberler> guten morgen
[07:53:33] <alex_joni> gut geschlafen?
[07:53:34] <mhaberler> sorry wegen gestern, da war ich echt daneben
[07:53:53] <mhaberler> ja, tutto been
[07:53:53] <alex_joni> nix passiert, kann mal vorkommen ;)
[07:53:54] <mhaberler> bene
[07:54:30] <mhaberler> ich hatte den Eindruck ich war grundlos des 'unwarranted change' verdächtig, aber das war nicht was Du sagtest
[07:55:53] <mhaberler> the exchange with viesturs made it clear for me - programmability at the ngc level during pause is pretty much nonsense
[07:56:19] -!-
dimas has quit [Read error: Connection reset by peer]
[07:57:49] <mhaberler> what would work relatively easy and low impact: switching motion queues and work with a Python binding to usrmotintf during pause - that wouldnt affect suspended interp state at all and gives some limited form of programmability if one were to absolutely need it
[07:57:49] <alex_joni> ne, ueberhaupt nicht was ich meinte
[07:58:39] <alex_joni> well, you still have to update the paused interpreter
[07:58:52] <alex_joni> so some form of programmability is needed
[07:59:23] <alex_joni> and the updated things _might_ bork the rest of the interpreted things
[07:59:26] <mhaberler> not if the invariant is 'you resume at the current point where paused'
[07:59:35] <alex_joni> imagine user pushes pause, then MDI's G20 instead of G21
[07:59:39] <alex_joni> then hits resume
[08:00:02] <mhaberler> thats why I said its pretty much nonsense at the NGC level
[08:00:20] <mhaberler> it wasnt totally clear to me until he asked
[08:01:03] <mhaberler> I was referring to a non-NGC programmability during pause - that is a bit like canon; fairly esoteric
[08:18:14] -!-
rob_h [rob_h!~rob_h@5ace70d6.bb.sky.com] has joined #linuxcnc-devel
[08:19:51] -!-
maximilian_h [maximilian_h!~bonsai@p549DF31E.dip.t-dialin.net] has joined #linuxcnc-devel
[08:20:44] -!-
maximilian_h [maximilian_h!~bonsai@p549DF31E.dip.t-dialin.net] has parted #linuxcnc-devel
[08:23:18] <alex_joni> yeah, but what I mean is that whatever you do (be it canon or interp or even at motion level) you can cause things which should influence the existing (and paused) queue
[08:24:40] -!-
hm2-buildmaster has quit [Ping timeout: 260 seconds]
[08:24:53] -!-
linuxcnc-build has quit [Ping timeout: 248 seconds]
[08:26:17] -!-
MarkusBec has quit [Excess Flood]
[08:37:25] <mhaberler> I dont doubt it needs a serious look, but at the usrmotif & motion layer it is fairly isolated what should be subject to snapshot/restore
[08:39:07] -!-
hm2-buildmaster [hm2-buildmaster!~hm2-build@75-166-182-242.hlrn.qwest.net] has joined #linuxcnc-devel
[08:39:27] -!-
linuxcnc-build [linuxcnc-build!~linuxcnc-@75-166-182-242.hlrn.qwest.net] has joined #linuxcnc-devel
[08:43:02] _Poincare is now known as
Poincare
[08:43:09] -!-
Poincare has quit [Quit: changing servers]
[08:50:44] -!-
sumpfralle has quit [Ping timeout: 260 seconds]
[08:55:34] -!-
sumpfralle has quit [Ping timeout: 245 seconds]
[08:58:40] <alex_joni> mhaberler: yeah, sure. that part feels doable
[08:59:16] <mhaberler> "you may program any motion during pause provided you do it in canterp" ;)
[08:59:36] <mhaberler> which make sure nobody will ever use it
[09:01:37] <mhaberler> its kinda like the "Ford T" argument - 'you can have it in any color provided the color is black'
[09:05:02] -!-
maximilian_h [maximilian_h!~bonsai@p549DE979.dip.t-dialin.net] has joined #linuxcnc-devel
[09:07:00] <alex_joni> heh
[09:18:26] -!-
mhaberler_ [mhaberler_!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[09:18:26] -!-
mhaberler has quit [Read error: Connection reset by peer]
[09:18:26] mhaberler_ is now known as
mhaberler
[09:53:13] -!-
sumpfralle has quit [Quit: Leaving.]
[10:10:05] -!-
ktchk has quit [Ping timeout: 260 seconds]
[10:27:38] -!-
fliebel has quit [Remote host closed the connection]
[10:47:05] -!-
vladimirek has quit [Remote host closed the connection]
[10:51:33] -!-
maximilian_h [maximilian_h!~bonsai@p549DE979.dip.t-dialin.net] has parted #linuxcnc-devel
[11:36:12] jthornton is now known as
Jymmmmm2
[11:40:29] Jymmmmm2 is now known as
jthornton
[11:43:01] -!-
psha[work] has quit [Quit: Lost terminal]
[11:47:23] -!-
H264 has quit [Ping timeout: 260 seconds]
[12:41:29] -!-
mhaberler has quit [Quit: mhaberler]
[12:49:12] -!-
pingufan has quit [Quit: Konversation terminated!]
[13:03:09] -!-
pingufan has quit [Client Quit]
[13:42:50] -!-
mozmck has quit [Quit: Leaving.]
[13:44:02] -!-
mozmck [mozmck!~moses@client-74.117.92.175.dfwtx.partnershipbroadband.com] has joined #linuxcnc-devel
[13:49:35] -!-
factor has quit [Read error: Connection reset by peer]
[14:06:40] -!-
nots has quit [Ping timeout: 276 seconds]
[14:06:57] <cradek> hm, accel constraint is violated when aborting
[14:14:06] -!-
nots has quit [Ping timeout: 260 seconds]
[14:14:22] -!-
Valen has quit [Quit: Leaving.]
[14:19:31] -!-
pingufan has quit [Quit: Konversation terminated!]
[14:25:14] <cradek> ouch, AXIS crashed on me when I clicked the clear brush
[14:27:33] -!-
psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[14:29:31] -!-
nots has quit [Ping timeout: 252 seconds]
[14:31:05] -!-
psha has quit [Read error: No route to host]
[14:31:21] <JT-Shop> yuck
[14:32:34] -!-
psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[14:34:15] <cradek> axis[10653]: segfault at b60a9fd0 ip 00debd89 sp b6935214 error 4 in linuxcnc.so[de5000+15000]
[14:34:30] <cradek> not having any luck doing it again. this is all I have.
[14:36:08] -!-
cmorley has quit [Ping timeout: 244 seconds]
[14:39:18] -!-
elmo40 has quit [Read error: Connection reset by peer]
[14:39:35] <cradek> I had previously run tort, which is long enough that old backplot starts disappearing
[14:39:49] -!-
nots has quit [Ping timeout: 276 seconds]
[14:43:36] -!-
e-ndy has quit [Read error: Operation timed out]
[14:43:48] -!-
e-ndy [e-ndy!~e-ndy@fantomas.bestit.cz] has joined #linuxcnc-devel
[14:50:02] -!-
cmorley [cmorley!~chris@d64-180-200-50.bchsia.telus.net] has joined #linuxcnc-devel
[14:51:43] -!-
nots has quit [Ping timeout: 260 seconds]
[14:54:02] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[14:57:15] -!-
vladimirek has quit [Remote host closed the connection]
[15:03:05] -!-
nots has quit [Remote host closed the connection]
[15:09:50] -!-
Rogge [Rogge!~IceChat77@mail.tormach.com] has joined #linuxcnc-devel
[15:23:34] -!-
psha has quit [Read error: No route to host]
[15:27:50] -!-
psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[15:30:43] -!-
DJ9DJ has quit [Quit: bye]
[15:33:35] -!-
psha has quit [Read error: Connection reset by peer]
[15:36:35] -!-
capricorn_one has quit [Quit: Konversation terminated!]
[15:36:55] -!-
nots has quit [Ping timeout: 260 seconds]
[15:38:00] -!-
psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[15:38:37] -!-
joe9 has quit [Quit: leaving]
[15:45:14] -!-
psha has quit [Read error: Connection reset by peer]
[15:49:37] -!-
psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[15:53:05] -!-
psha has quit [Read error: No route to host]
[15:54:57] <skunkworks__> cradek: /home/samco/linuxcncfast/scripts/linuxcnc: line 708: 32748 Segmentation fault $EMCDISPLAY -ini "$INIFILE" $EMCDISPLAYARGS $EXTRA_ARGS
[15:59:36] -!-
psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[16:00:47] -!-
adb [adb!~adb@178-211-226-40.dhcp.voenergies.net] has joined #linuxcnc-devel
[16:00:53] -!-
tiago has quit [Remote host closed the connection]
[16:02:01] -!-
sebjames__ has quit [Quit: Ex-Chat]
[16:02:01] -!-
seb_ has quit [Quit: Ex-Chat]
[16:04:16] <skunkworks__> cradek: If I load 3dchips - run it then load tort and run it then load spiral and run it - I get a segfault. It doesn't seem to be clearing the backplot automatically either (I would think those 3 programs would start clearing the older backplots)
[16:04:43] <cradek> master build?
[16:04:58] <skunkworks__> yes
[16:05:07] <cradek> I definitely get clearing even on just a tort run
[16:05:17] <skunkworks__> *I get the segfault when I clear the backblot.
[16:05:21] <cradek> maybe our vel/acc settings are different - that would sure affect it
[16:05:40] <cradek> we sure need to get a backtrace - can you reproduce it?
[16:05:46] <skunkworks__> I think so.
[16:05:56] <skunkworks__> just did it twice
[16:06:05] <skunkworks__> how do I do a backtrace?
[16:06:13] <cradek> good question
[16:06:23] <cradek> after everything is running, find AXIS's pid
[16:06:37] <cradek> gdb /usr/bin/python [the pid]
[16:07:24] <cradek> gdb will attach and at the (gdb) prompt type c return
[16:07:34] <cradek> then hopefully go make the error happen
[16:08:25] <skunkworks__> op the pid is 917 - let me see
[16:10:35] <skunkworks__> I did the gdb /usr/bin/python 917 in a deferent terminal.. is there anything else I need to do? because it made axis unresponsive.
[16:10:52] <skunkworks__> wait
[16:11:02] <skunkworks__> I suck at following directions
[16:13:13] <cradek> now if you can make it segfault again gdb will halt it at the error
[16:17:32] <skunkworks__> well - it didn't happen that time. let me goof around
[16:17:41] -!-
ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #linuxcnc-devel
[16:17:44] <skunkworks__> of course
[16:19:19] -!-
zlog has quit [Ping timeout: 256 seconds]
[16:20:30] -!-
Tom_itx has quit [Ping timeout: 272 seconds]
[16:25:49] -!-
mhaberler has quit [Quit: mhaberler]
[16:28:05] Tom_L is now known as
Tom_itx
[16:33:10] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[16:40:17] -!-
nots has quit [Ping timeout: 256 seconds]
[16:44:07] <skunkworks__> cradek:
http://pastebin.com/Lnt6L9MQ
[16:44:12] <skunkworks__> do I do anything now?
[16:46:24] <cradek> yay
[16:46:26] <cradek> (gdb) bt
[16:46:50] <skunkworks__> so type bt at the prompt?
[16:46:53] <cradek> yes
[16:46:58] <cradek> pastebin the results please
[16:47:45] <skunkworks__> http://pastebin.com/2Q1Vhc8t
[16:48:16] <cradek> ick, that doesn't look very useful.
[16:48:27] <skunkworks__> crap
[16:48:51] <cradek> how about "p op" and "p oop"
[16:49:59] <cradek> p s->npts
[16:50:26] <skunkworks__> http://pastebin.com/55mY9fAE
[16:51:20] <skunkworks__> http://pastebin.com/T7dgctEQ
[16:51:27] <cradek> ahhhhh
[16:51:33] <cradek> there it is
[16:51:41] <skunkworks__> great! what?
[16:52:13] <cradek> I think npts=0 leads to a negative array index
[16:52:16] -!-
pingufan has quit [Quit: Konversation terminated!]
[16:52:19] <cradek> not that I know what's wrong with the code though
[16:53:26] <cradek> can you make one big pastebin to show jepler?
[16:53:32] <cradek> of the whole gdb session I mean
[16:53:36] <skunkworks__> sure
[16:56:50] <skunkworks__> this work? it is from the start of gdb
http://pastebin.com/6EiChHqH
[16:57:14] <cradek> perfect, thanks
[16:58:27] -!-
maximilian_h [maximilian_h!~bonsai@130.255.104.157] has joined #linuxcnc-devel
[16:59:52] <cradek> ooh, try generate-core-file
[17:00:41] <skunkworks__> http://pastebin.com/Pz1WbK7c
[17:00:57] -!-
psha has quit [Read error: No route to host]
[17:01:03] <cradek> huh, wonder if that worked. I've never used it before.
[17:01:19] <jepler> p s->p
[17:01:24] <jepler> p add_Point
[17:01:34] <jepler> er, p add_point
[17:01:48] <jepler> if s->npts is 0, then add_point should already be true
[17:02:22] <cradek> oh, tricky, I didn't catch that
[17:02:24] <jepler> that means that at add_point |= colinear(...) the RHS is not evaluated
[17:02:28] <skunkworks__> http://pastebin.com/61riE6YW
[17:03:41] <cradek> but |= is bitwise, are you sure about short circuit behavior?
[17:03:49] <jepler> hmm am I?
[17:03:56] <jepler> you may be right
[17:03:58] <cradek> I don't think you should be sure
[17:04:29] <cradek> but with bools I sure don't know
[17:04:57] <jepler> bool segfault() { return *(bool*)0; }
[17:04:57] <jepler> int main() { bool b = true; b |= segfault(); return 0; }
[17:05:02] <jepler> on my system, this program doesn't segfault
[17:05:41] <cradek> built as c++?
[17:06:05] <cradek> I assume emcmodule.cc is built with g++ but didn't check
[17:06:07] <jepler> interesting, it does start segfaulting if built without optimization
[17:06:09] <jepler> yes it is
[17:06:25] <cradek> this gun might be smoking, yay
[17:06:40] <jepler> Ok, yeah, those have to be add_point = add_point || colinear...
[17:06:47] <jepler> since there's no ||=
[17:06:51] <jepler> patch forthcoming
[17:06:59] <cradek> thanks
[17:07:00] <jepler> .. after lunch
[17:07:03] <cradek> skunkworks__: also thanks
[17:07:10] <jepler> indeed
[17:07:21] <cradek> 2.4 patch I suspect
[17:07:25] <skunkworks__> Great!
[17:11:45] -!-
psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[17:16:24] -!-
psha has quit [Read error: No route to host]
[17:16:45] -!-
psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[17:25:54] -!-
psha has quit [Read error: No route to host]
[17:26:59] -!-
demacus has quit [Ping timeout: 246 seconds]
[17:30:59] -!-
psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[17:32:14] <mhaberler> progress on cuisine: besides "Noodles Chow-Mein" we now sport "NURBS a la Yi-shin" ;)
[17:32:45] -!-
mhaberler has quit [Quit: mhaberler]
[17:36:23] -!-
nots has quit [Ping timeout: 256 seconds]
[17:38:31] -!-
lerman [lerman!~chatzilla@24-151-1-146.static.nwtn.ct.charter.com] has joined #linuxcnc-devel
[17:40:59] -!-
phantoxe has quit []
[17:41:44] -!-
factor has quit [Read error: Connection reset by peer]
[18:01:32] -!-
andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has joined #linuxcnc-devel
[18:07:10] -!-
psha has quit [Read error: Connection reset by peer]
[18:07:15] -!-
psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[18:11:04] -!-
nots has quit [Ping timeout: 244 seconds]
[18:12:14] -!-
ve7it has quit [Remote host closed the connection]
[18:13:19] -!-
ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #linuxcnc-devel
[18:16:50] -!-
IchGuckLive [IchGuckLive!~chatzilla@95-89-236-191-dynip.superkabel.de] has joined #linuxcnc-devel
[18:17:39] <IchGuckLive> hi all jepler ? i did a recalculation on python tkinter canvas drawinfg to postscript picture
[18:18:12] -!-
nots_ has quit [Ping timeout: 252 seconds]
[18:18:13] <IchGuckLive> i found soome example of your codes snip it wars hard to find all the options
[18:19:34] -!-
IchGuckLive [IchGuckLive!~chatzilla@95-89-236-191-dynip.superkabel.de] has parted #linuxcnc-devel
[18:28:14] -!-
maximilian_h has quit [Ping timeout: 246 seconds]
[18:42:26] -!-
maximilian_h [maximilian_h!~bonsai@93.182.173.28] has joined #linuxcnc-devel
[18:50:22] <jepler> huh, I thought that add_point |= ... code was fairly old, but it looks like it's not in 2.5.
[18:52:51] <skunkworks__> probably why no one has really noticed it
[18:52:54] <skunkworks__> ?
[18:52:58] <jepler> could be
[18:53:13] <jepler> does anyone know what IchGuckLive was talking about?
[18:59:29] <CIA-68> 03jepler 07master * r1f30f27f1b32 10/src/emc/usr_intf/axis/extensions/emcmodule.cc: Fix crash in AXIS backplot
[19:02:28] <cradek> thanks jepler
[19:02:41] <jepler> I'm sad I wrote it in the first place, but otherwise you're welcome.
[19:03:08] <cradek> good thing nobody else is perfect either.
[19:04:17] <cradek> did you find that the bug is not in the stable branches?
[19:11:59] -!-
maximilian_h has quit [Read error: Connection reset by peer]
[19:17:19] <jepler> cradek: right. 2.5 has this instead:
[19:17:19] <jepler> bool add_point = s->npts < 2 || c != op->c || !colinear(
[19:17:19] <jepler> x, y, z, op->x, op->y, op->z, oop->x, oop->y, oop->z);
[19:17:22] <jepler> if(add_point) {
[19:17:27] <jepler> and I broke it specifically when I added foam
[19:17:33] <cradek> yay!
[19:17:53] <cradek> I should have looked for myself, sorry.
[19:18:00] <jepler> s'okay.
[19:27:38] -!-
cmorley has quit [Ping timeout: 260 seconds]
[19:30:28] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[19:31:10] -!-
psha has quit [Quit: Lost terminal]
[19:33:45] -!-
vladimirek has quit [Ping timeout: 260 seconds]
[19:35:25] -!-
maximilian_h [maximilian_h!~bonsai@93.182.172.242] has joined #linuxcnc-devel
[19:40:47] -!-
ve7it has quit [Remote host closed the connection]
[19:52:04] -!-
nots has quit [Ping timeout: 252 seconds]
[19:52:08] -!-
motioncontrol has quit [Quit: Sto andando via]
[20:04:12] -!-
dimas_ has quit [Ping timeout: 255 seconds]
[20:19:57] -!-
sumpfralle has quit [Quit: Leaving.]
[20:40:32] -!-
maximilian_h has quit [Ping timeout: 246 seconds]
[20:41:52] -!-
nots has quit [Remote host closed the connection]
[20:45:29] -!-
fliebel has quit [Remote host closed the connection]
[20:47:13] -!-
sliptonic_shop has quit [Remote host closed the connection]
[20:50:29] -!-
jackc has quit [Ping timeout: 252 seconds]
[20:56:30] <skunkworks__> when I try to do a jpeg import into axis - I am getting an error File "/home/samco/linuxcnc/bin/image-to-gcode", line 35, in <module>
[20:56:32] <skunkworks__> import numarray, numarray.ieeespecial
[20:56:59] <skunkworks__> a little google searching isn't helping
[20:57:09] <skunkworks__> both in 2.5 and master
[20:57:29] -!-
maximilian_h [maximilian_h!~bonsai@93.182.172.70] has joined #linuxcnc-devel
[20:58:10] <cradek> do you have python-numpy installed?
[20:59:29] -!-
andypugh has quit [Quit: andypugh]
[21:00:56] -!-
andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has joined #linuxcnc-devel
[21:02:33] <skunkworks__> cradek: Thanks! that did it
[21:06:08] -!-
nots has quit [Ping timeout: 272 seconds]
[21:07:13] <skunkworks__> cradek: did you see genes issue with mdi? master doesn't allow you to que up commands anymore.. Don't know if it is big deal or not.. (I know i have use that before)
[21:07:33] -!-
DJ9DJ has quit [Quit: bye]
[21:10:05] -!-
bedah has quit [Quit: bye]
[21:10:22] <andypugh> I am trying to reproduce it, but Master won't run at all for me at the moment
[21:11:16] <andypugh> OK, and just as I hit "enter" on "make clean" I realised that it is probably a lack of ye olde "sudo make setuid" thing...
[21:11:27] <skunkworks__> queing up works in 2.5 - not in master
[21:13:25] <andypugh> I think that has to have been a change in Axis ?
[21:13:55] <andypugh> As I don't think I have seen MDO greyed out, ever.
[21:15:10] <skunkworks__> neither have I (until I just pulled the latest master yesterday..)
[21:16:31] <skunkworks__> cradeks changes to tp are pretty cool
[21:24:51] <skunkworks__> http://imagebin.org/210706
[21:25:19] <skunkworks__> that was the g1x10f1
[21:27:05] -!-
maximilian_h has quit [Ping timeout: 246 seconds]
[21:41:28] -!-
maximilian_h [maximilian_h!~bonsai@anon-174-197.vpn.ipredator.se] has joined #linuxcnc-devel
[21:41:31] -!-
nots has quit [Ping timeout: 260 seconds]
[21:42:32] -!-
servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[21:48:58] -!-
simax has quit [Quit: Page closed]
[21:50:17] <andypugh> OK, I see the problem
[21:50:50] <skunkworks__> in code?
[21:51:51] <andypugh> Not as such, I just reverted
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commit;h=81f105b477699060d6c721a06034aceea31cb964 and it went away
[21:52:17] -!-
maximilian_h has quit [Ping timeout: 246 seconds]
[21:52:44] <andypugh> It looks like Axis uses that signal to grey-out the MDI when the program is running, and now that the signal is set for MDI too...
[21:53:07] <andypugh> mhaberler: You broke Axis!
[21:54:27] <mhaberler> I beg to differ - it was incorrectly traced and hence this didn show up
[21:55:02] <andypugh> Well, yes, to be fair this is a problem with Axis not acting correctly on the state data
[21:55:07] <mhaberler> for the same reason you cannot start a another program when one is running
[21:55:38] <andypugh> I guess the MDI should be disabled only if mode = auto too.
[21:57:47] <mhaberler> If a UI choses to enable MDI input during running, then it explicitly do so, but I am at wits end where to find the place or knob how the axis tab gets disabled in Axis
[21:59:02] <mhaberler> for sure we will not compensate for that by reintroducing the bug, so I'd ask Gene to wait until Jeff can have a look at it
[21:59:38] <andypugh> I think it is related to the oddly-named "manual_ok()" function
[21:59:46] <mhaberler> let me see
[22:00:28] <mhaberler> right, this could be it
[22:00:39] -!-
rob_h has quit [Quit: Leaving]
[22:01:11] <mhaberler> probably returning true if s.task_mode == linuxcnc.MODE_MDI fixes it
[22:01:30] <mhaberler> hold the presses..
[22:01:53] <andypugh> 3053?
[22:02:18] -!-
syyl has quit [Read error: Connection reset by peer]
[22:02:47] <mhaberler> wrong. it is the idle state which now gets correctly reported
[22:03:52] <mhaberler> what's 3054?
[22:04:00] <mhaberler> 3053?
[22:04:56] <mhaberler> I think the last line of manual_ok should read:
[22:05:19] <mhaberler> return s.task_mode == linuxcnc.MODE_MDI or s.interp_state == linuxcnc.INTERP_IDLE
[22:05:30] <mhaberler> would you be so kind to try?
[22:05:31] <andypugh> As manual_ok is used 30 times, I would be more tempted to add an extra option to the MDI masking
[22:05:59] -!-
r00t4rd3d has quit [Quit: Leaving]
[22:06:40] -!-
nots has quit [Ping timeout: 244 seconds]
[22:07:09] <mhaberler> well whatever it is: the change means that during MDI execution s.interp_state is reported as INTERP_RUNNING, I think during MDI it was reported as INTERP_IDLE which is plain wrong
[22:08:42] <mhaberler> this violates a state assumption, namely INTERP_IDLE means the interpreter is synced, at it isnt at that point. Not sure if that matters though
[22:08:43] <andypugh> I agree with your opinion on what is correct. I worry that other behaviour might depend on the incorrect behaviour
[22:09:01] <mhaberler> that might be the case
[22:09:58] <andypugh> OK, so I can't guess Python. Line 3054 is not the one that disables the MDI tab
[22:10:53] -!-
maximilian_h [maximilian_h!~bonsai@93.182.168.151] has joined #linuxcnc-devel
[22:10:58] <mhaberler> I'm unsure whether manual_ok() is the place to change that; I'd rather ask Jeff before causing a mess
[22:11:30] <andypugh> How do you make changes to axis.py propogate?
[22:11:41] <mhaberler> I think that is the RFL right click in program window menu
[22:11:48] <andypugh> Ah., OK
[22:14:03] -!-
rob_h [rob_h!~rob_h@5ace70d6.bb.sky.com] has joined #linuxcnc-devel
[22:14:05] <andypugh> mhaberler: I made your change, the tab still greys-out. I think perhaps it is linked directly to the sate?
[22:14:36] <mhaberler> does returning always true ungrey it?
[22:14:56] <mhaberler> then you know you hit a sensitive spot at least..
[22:16:52] <andypugh> I don't know how to be sure that am running my changes to the python file
[22:17:55] <mhaberler> ok, you can either edit src/emc/usr_intf/axis/scripts/axis.py and do a make
[22:18:09] <andypugh> OK, that is what I have been doing.
[22:18:10] <mhaberler> or temporarily edit bin/axis, thats whats gets started
[22:18:30] <mhaberler> during a make bin/axis gets overwritten from the source location
[22:19:04] <mhaberler> great Python training btw, 'hands on' ;)
[22:19:04] <andypugh> I knoew there was something a bit comnvoluted about it. And an axis.pyc too, no doubt?
[22:19:28] <mhaberler> pyc is the Python bytecode, ignore it
[22:19:55] -!-
elmo40 has quit [Ping timeout: 250 seconds]
[22:20:15] <mhaberler> once a .py file is run the first time, a .pyc file is generated; next time you run .py the .pyc gets executed if it is younger than the corresponding .py file
[22:20:31] <mhaberler> starts faster
[22:20:53] -!-
maximilian_h has quit [Ping timeout: 260 seconds]
[22:20:57] <mhaberler> bb in 5mins
[22:21:08] <andypugh> making manual_ok() return 1 doesn't do the trick
[22:24:55] -!-
Tom_itx has quit []
[22:25:40] -!-
mhaberler_ [mhaberler_!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[22:25:42] <mhaberler_> andy - please reconsider whether you want to 'fix' this - it might not be a good idea
[22:25:51] -!-
mhaberler has quit [Ping timeout: 260 seconds]
[22:25:51] mhaberler_ is now known as
mhaberler
[22:26:12] <andypugh> I rather rely on queuing MDI commands myself.
[22:26:40] <mhaberler> well this is a bug. to make it a feature, a bit more is reuired:
[22:26:46] <andypugh> It's nice to get the retract programmed before the end of the move, for example
[22:27:12] <mhaberler> thats all dandy, but there's some footwork which isnt done yet
[22:27:19] <skunkworks__> exactly. (for us lazy people)
[22:27:51] -!-
zlog has quit [Ping timeout: 244 seconds]
[22:28:21] <mhaberler> the question to be answered is: does 'queuing' of MDI commands assure that they are serially executed. for instance, a more interesting case would be queuing several oword sub calls
[22:28:47] <andypugh> I don't know.
[22:29:02] <mhaberler> I dont either yet
[22:29:19] <andypugh> I doubt if many people are fast enough, or confident enough, to stack more than a few commands. Though that isn't the question you asked.
[22:29:48] <mhaberler> it would be a nice feature if it were fully thought through wrt the preconditions
[22:30:12] <andypugh> It's a nice feature now, even if it is also a bug
[22:30:17] <mhaberler> yes
[22:31:13] <mhaberler> the question is: is there a scenario where the second MDI command tramples on the one executing. 'my G0/G1 moves work' isnt a sufficient answer
[22:31:26] <andypugh> I think you fixed a bug which had never bitten anyone, and removed a behaviour that many folk had relied on.
[22:31:59] <mhaberler> I made it possible that a user interface executes something with a defined semantics, sorry
[22:32:13] <andypugh> Well, I can see that queueing the commands as text in the MDI window rather than in the intepreter would be safer. And you could change your mind too.
[22:32:37] <mhaberler> look, I am not saying 'never queue MDI commands'
[22:33:14] <mhaberler> I think giving it a second look before explicitly enabling it now that interpstate is correctly reported would be prudent, thats all
[22:33:34] <mhaberler> and that second look isnt at the manual_ok level, unfortunately
[22:33:39] -!-
maximilian_h [maximilian_h!~bonsai@93.182.169.14] has joined #linuxcnc-devel
[22:33:42] -!-
maximilian_h [maximilian_h!~bonsai@93.182.169.14] has parted #linuxcnc-devel
[22:34:21] <andypugh> No. The problem is that almost nobody knows LinusCNC well enough to figure out how queued MDI commands get executed.
[22:35:17] <mhaberler> I think that is solvable, it needs a bit of logging and playing through a few scenarios; I *think* it might be ok
[22:35:33] <mhaberler> note there was a second change a few months ago which relates to it
[22:36:05] <mhaberler> cradek and psha got oword sub callls working in MDI, and that is very different from executing a single G/Mxxx block
[22:36:13] <andypugh> My assumption has always been that MDI commands go into the larger system exactly as lines of g-code do.
[22:36:58] <mhaberler> up to about a year ago only blocks could go in, but not oword calls (which implies the interpreter does a lot more than looking at the single block)
[22:37:51] <mhaberler> an input file is a 'queue' if you will
[22:38:46] <mhaberler> but on 'mdi execute' the interpreter is called with interp.execute('o<foo>call') and that is not a single line so the termination of this code is an issue
[22:39:07] <mhaberler> it wasnt with single blocks because the interp could only do one at a time anyway
[22:39:28] <mhaberler> now assume this:
[22:39:41] <mhaberler> interp.execute('o <foo> call')
[22:39:54] <mhaberler> interpstate running is ignored, just to be bug-compatible
[22:40:29] <mhaberler> as a consequence, interp.execute('nextcommand') gets called. Do we know this doesnt happen?
[22:41:15] <mhaberler> it is quite involved because oword subs and mdi is very messy; could well be its fine, and there is a chance it isnt at all
[22:42:43] <mhaberler> what I'm saying is: the serialization of commands when 'queueing MDI' could be broken, and nobody noticed because the feature which shows the bug was enabled only recently
[22:42:53] <andypugh> I am still unable to find the code that disables the window.
[22:42:57] <mhaberler> ok, I'll stop second-guessing, I'll sleep about it
[22:43:15] <mhaberler> I feel with you, I'v not penetrated the Axis UI logic
[22:43:36] <mhaberler> the extra TCL layer makes it hard to follow what goes on (axis.tcl)
[22:43:40] <andypugh> the tcl is static, and just a graphical definition, yes?
[22:43:50] <andypugh> Or does that execute too?
[22:43:57] <mhaberler> no, that is a completely different interpretd language
[22:44:38] <mhaberler> the widgets in Axis are actually in TCL, Python just defers to TCL at some point but I dont fully understand how that works
[22:45:18] <andypugh> Ah
[22:50:24] -!-
heccy [heccy!~bcundal@216.81.62.52] has joined #linuxcnc-devel
[22:51:07] <heccy> Hi, just curious if anyone was aware of this:
http://linuxcnc.org/experimental/gutsy/tradefile.htm
[22:51:21] <heccy> Seems to have been there for over a year - I'm amazed noone has taken it down.
[22:52:08] <andypugh> Where is it linked from?
[22:52:28] -!-
memleak [memleak!~memleak@unaffiliated/memleak] has joined #linuxcnc-devel
[22:52:39] <mhaberler> thinking about the MDI thing, I could think of the test required. leave my commit in and fudge Axis to 'reenable queuing'. Then the interp code which gets called on MDI needs a test against against task's idea of 'interp running'. If that test ever evaluates to true, then there is a BIG issue which just nobody happened to trip over
[22:52:41] <heccy> Dunno, some phishing email I assume... It's been in a phishing DB for quite some time
[22:52:49] <heccy> http://www.phishtank.com/phish_detail.php?phish_id=1255286
[22:53:17] <heccy> your site is blacklisted in a few places for phishing
[22:53:32] <andypugh> Yes, we had a problem with Joomla
[22:53:50] <heccy> hasn't been cleaned up fully, apparently ;)
[22:54:00] <mhaberler> uh oh
[22:54:16] <andypugh> If you spoofed your browser to look like Googlebot you got completely different content. Clever, and rather subtle. As well as hugely annoying
[22:55:25] <mhaberler> and that, andy, is the reason I asked Gene to file a bug report: now all this discussion is littered here and there, an email, some IRC log, and NO bug report
[22:55:36] <mhaberler> and a potential severe issue
[22:55:41] <memleak> I'm compiling RTAI and EMC from source, I spent a lot of time on this already and I've been working out bugs here and there, but now I'm stuck again. RTAPI: ERROR: version mismatch 1 vs 0 any idea?
[22:57:41] <andypugh> sorry memleak, I decided that compiling from scratch was a mugs game some time ago.
[22:59:09] <memleak> insmod rtapi.ko reported a bunch of unknown symbols too. last time my only two were floor and frexp. this list just got a lot larger.
http://pastebin.com/aKtxY0vd
[23:00:00] <memleak> What is EMC's RTAPI module aligned to? Like which version of RTAI? 3.8, 3.8.1 ?
[23:00:21] <memleak> I tried magma, I had a lot of problems, tried volcano, seemed to have gotten closer but still not there.
[23:00:58] -!-
zlog has quit [Read error: Connection reset by peer]
[23:03:40] -!-
maximilian_h [maximilian_h!~bonsai@93.182.175.153] has joined #linuxcnc-devel
[23:05:56] <memleak> It's probably why I'm getting the version mismatch is because the kernel module can't load.
[23:05:58] <andypugh> Do you know how to find out?
[23:06:38] <memleak> Well the people who make the Ubuntu EMC + RTAI live cd would know (if they remember off the top of their head)
[23:07:21] <memleak> but how could I _manually_ find out for certain.... :/
[23:09:17] -!-
maximilian_h has quit [Ping timeout: 246 seconds]
[23:11:32] <andypugh> Which kernel version?
[23:11:50] <memleak> 2.6.38.8-ipipe
[23:12:31] <memleak> I ran dmesg on the ubuntu box next to me with the EMC live cd installed, dmesg reports no IPIPE versions....
[23:14:27] <memleak> there we go! 3.8.1!
[23:16:29] <andypugh> 2.6.38.8 might be a bit ahead of where the RTAI patches have got. My LinuxCNC is running on 2.6.32-122
[23:17:19] <heccy> So uhh... someone's on the case regarding the phishing page?
[23:17:41] -!-
sumpfralle has quit [Ping timeout: 246 seconds]
[23:18:29] <mhaberler> I dropped alex a mail
[23:18:37] <memleak> andypugh, I had to re-write parts of the IPIPE patch for 2.6.38.8 to fix my spurious interrupts and kernel BUG() fixes
[23:18:40] <mhaberler> I dont have access
[23:19:31] <andypugh> heccy: I don't even know who does have access
[23:19:37] <memleak> I also had to fix some other various things because Linux couldn't bring up the other 3 cores on my 4 core CPU
[23:20:47] <memleak> I'll try compiling 3.8.1. I have a fear that the kernel patch might be too new for the RTAI userspace to handle (the stuff in /usr/realtime)
[23:23:12] <heccy> Welp, FYI it's there... just thought I'd let someone know since it appeared noone had reported the problem. I just happened across the site some months ago looking for CNC stuff and got a phishing warning. Good luck cleaning it up.
[23:24:08] -!-
heccy [heccy!~bcundal@216.81.62.52] has parted #linuxcnc-devel
[23:25:57] -!-
maximilian_h [maximilian_h!~bonsai@93.182.139.193] has joined #linuxcnc-devel
[23:30:49] <memleak> the userspace won't compile (as expected) it's calling a bunch of functions that aren't used anymore (undeclared functions are everywhere)
[23:31:32] <memleak> I'll try the only 2.6.32 kernel patch in 3.8.1 as it must be the one used for ubuntu
[23:32:11] <andypugh> memleak: You have some really good reason for not using the debs?
[23:32:39] <memleak> I'm not using debian / ubuntu.
[23:33:27] <memleak> and i have a "really good reason" for not touching those ;)
[23:34:04] <andypugh> Any chance you can graft your distro onto the LinuxCNC kernel?
[23:35:29] <andypugh> Have you read:
http://code.google.com/p/neo-technical/wiki/emc2arch ?
[23:35:39] <memleak> I.. wrote that actually ;)
[23:35:55] <andypugh> Ah, well, if you will go changing your name...
[23:36:37] <memleak> Except I can't maintain those anymore as I'm not using Arch anymore. I got tired of the package maintainers breaking stuff (like X and whatnot) so I moved to gentoo
[23:37:20] <memleak> Those wikis are also out-of-date and I'm trying to freshen things up from square one.
[23:38:14] <andypugh> Thing is, I can't see why you even have an opinion on the OS that your CNC machine runs on. It's like worrying about the firmware in your TV.
[23:39:05] <memleak> I'm actually not to far from worrying about the firmware in my TV :)
[23:39:31] <andypugh> Yeah, it dawned on me that perhaps I hadn't chosen an extreme enough metaphor.
[23:40:01] <memleak> Secondly, if anything breaks, I'd like to be able to fix it. I hate "magic" and Ubuntu is simply.. loaded full of it.
[23:41:08] <memleak> I know most of the people here like it, and to each their own. I'm just not one of those people is all.
[23:43:19] <andypugh> I have no real opinion about Ubuntu, it works OK for LinuxCNC, and that is all I use it for. My main machine is: 11.3.0 Darwin Kernel Version 11.3.0:
[23:43:32] <memleak> The underlying issue with all my problems looks to be that EMC hasn't caught up with the new RTAI code and I'm jumping through hoops to make it so. I'll just downgrade all my stuff right now and everything should work.
[23:44:11] <andypugh> Well, a secondary problem is that RTAI hasn't caught up with Ubuntu Kernels, so LinuxCNC is holding back.
[23:44:33] <memleak> Ubuntu is using newer kernels than 2.6.38!?
[23:45:40] <cradek> mhaberler: until recently, queueing mdi commands worked, I think because of the interp_list. I've used it lots and lots. I have probably never used it with the mdi-o-call feature though.
[23:46:24] <cradek> I queue up several commands using touchy's mdi all the time - like for a bunch of drills, etc
[23:46:25] <mhaberler> no it isnt. I'm just writing to dev list, it is much more complex. Its a potential race conditon
[23:46:48] <andypugh> I don't know. I do recall hearing that using the current Ubuntu version with LinuxCNC is tricky because there is no RTAI patch compatible with the kernel that comes with it.
[23:47:25] <mhaberler> you might just happend not to trip it - it likely doesnt trip with plain blocks, likely with an osub call followed by 'a queued MDI command'
[23:47:54] <mhaberler> note there IS no input queue, and defective state tracking just calls the interp again!!
[23:48:12] <memleak> and changing major kernel releases with Ubuntu is not something that should be done lightly..
[23:48:34] <mhaberler> I wont be able to do anything before end of may about it, but I'll give a hint how to address it if folks get antsy
[23:49:51] <andypugh> memleak: Apparently 12.04 is on kernel 3.2.14
[23:50:17] <mhaberler> cradek: as things stand now, the fix is to queue MDI commands within Axis
[23:50:28] <cradek> sure could be - I surely used plain blocks and drill cycles only
[23:50:55] <andypugh> Not being able to queue boring cycles could get very squeaky.
[23:50:57] <mhaberler> these are mostly atomic as far as interp execution gies
[23:51:00] <cradek> from a user perspective, it previously worked with all guis
[23:51:10] <memleak> Oh that makes sense.. RTAI won't be supporting 3.X on x86 any time soon based on the look of it. I mean RTAI only has two core devs on it really.
[23:51:30] <mhaberler> I can draw a scenario to crash your machine with this 'feature', be wary
[23:51:30] <cradek> well a drill cycle can output hundreds of moves - not sure how atomic that is
[23:51:55] <cradek> tell me how and I'll try it in 2.5.0
[23:52:03] <mhaberler> 'atomic on the input side' is the relevant question
[23:52:14] <andypugh> set peck to 0.00001"?
[23:52:15] <memleak> RTAI supports 3.X kernels on PPC and ARM though...
[23:52:32] <mhaberler> hold on, I'll write it up to the list so I dont do it twice
[23:52:37] <memleak> I had a hunch that x86 would be the first to shine...
[23:52:44] <cradek> well I believe you - it's just that for a user (and as far as task goes I hardly know more than a user) it seems like a regression
[23:52:49] <cradek> ok
[23:53:04] <mhaberler> MDI queuing is surely useful, and should work again, but not by patching up axis or reverting my fix
[23:53:44] -!-
maximilian_h1 [maximilian_h1!~bonsai@130.255.104.157] has joined #linuxcnc-devel
[23:53:45] <mhaberler> regression.. make it crash prevention for now ;)
[23:53:46] -!-
maximilian_h1 [maximilian_h1!~bonsai@130.255.104.157] has parted #linuxcnc-devel
[23:54:26] -!-
maximilian_h has quit [Ping timeout: 246 seconds]
[23:55:03] <andypugh> TBH anyone running 2.6 ought to be prepared to swallow the occasional wierdness. I have no idea why Gene insists on running it.
[23:55:29] <cradek> I agree with you and also am glad people test it
[23:56:06] -!-
r00t4rd3d has quit [Read error: Connection reset by peer]
[23:56:18] -!-
r00t4rd3d has quit [Changing host]
[23:56:37] -!-
Nick001-Shop has quit [Remote host closed the connection]
[23:57:38] -!-
Tom_L has quit []
[23:58:45] <memleak> 2.6 kernels?
[23:59:04] <memleak> or EMC 2.6?
[23:59:13] <cradek> 2.6 is the next major linuxcnc version and some people call the master branch that