Back
[00:12:32] <dgarr> hi -- i modified one but haven't seen comments on it,
http://www.panix.com/~dgarrett/stuff/0001-provide-way-for-axis-gui-to-reject-remote-applicatio.patch
[00:26:52] <jepler> dgarr: committed with tweaks, thanks
[00:27:00] <CIA-62> EMC: 03jepler 07master * r0979454356fd 10/src/emc/usr_intf/axis/scripts/axis-remote.py: add --mdi to axis-remote
[00:27:01] <CIA-62> EMC: 03jepler 07master * r1a80e617b21b 10/src/emc/usr_intf/axis/scripts/ (axis-remote.py axis.py): improve communication between axis and axis-remote
[00:31:04] <dgarr> thanks! -- i use it with send command from a separate tcl interpreter
[00:32:41] <dgarr> i've been running simulator on a karmic install and see the problem with tcl's send command and xhost
[00:33:18] <dgarr> i just: xhost - SI:localuser:root ... etc. but wonder if you have a better solution?
[00:34:21] <jepler> yeah, I know of the problem
[00:39:49] <jepler> http://emergent.unpy.net/files/sandbox/tk8.5_8.5.7-1.1.diff.gz http://emergent.unpy.net/files/sandbox/tk8.5_8.5.7-1.1.dsc modified version that incorporates a fix for the SI: problem
[00:40:23] <jepler> http://archive.ubuntu.com/ubuntu/pool/main/t/tk8.5/tk8.5_8.5.7.orig.tar.gz
[00:41:02] <jepler> I think the routine is: get all those in one folder, dpkg-source -x tk8.5*1.1.dsc, cd into the tk8.5-8.5.7 directory, dpkg-buildpackage, and install the packages created in ..
[00:42:27] <jepler> the patch itself is
http://emergent.unpy.net/files/sandbox/send-SI.diff
[00:47:43] <jepler> in the latest cvs versions of tk8.5 and tk8.6 they've incorporated a different fix which I haven't tested myself:
http://tktoolkit.cvs.sourceforge.net/viewvc/tktoolkit/tk/unix/tkUnixSend.c?r1=1.26&r2=1.24
[01:03:41] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[01:26:14] <Dave911_> Dave911_ is now known as Dave911
[01:39:55] <dgarr> jepler: using your instructions, i built the debs with your patch and it seems to solve the problem (karmic,simulator) -- Nice Work
[02:07:14] <Dave911_> Dave911_ is now known as Dave911
[02:14:42] <jepler> dgarr: you're welcome
[02:47:13] <Dave911_> Dave911_ is now known as Dave911
[03:08:27] <jepler_> jepler_ is now known as jepler
[03:27:08] <Dave911_> Dave911_ is now known as Dave911
[03:46:55] <Dave911_> Dave911_ is now known as Dave911
[04:07:07] <Dave911_> Dave911_ is now known as Dave911
[08:15:18] <micges_work> SWPLinux, jepler:
http://www.pastebin.ca/1738507
[08:20:23] <micges_work> gcode file:
http://filebin.ca/fcobus/0.ngc.zip
[08:31:58] <alex_joni> micges_work: now that's what I call heavy use of M66 :)
[08:32:32] <micges_work> hehe
[08:32:39] <alex_joni> glad someone is using it
[08:33:30] <micges_work> my gcode generator was set for oxygen cutter mode, so each line is protected by M66
[08:33:55] <micges_work> alex_joni: all the time :)
[08:34:14] <micges_work> even if it has some bugs
[08:36:23] <alex_joni> yah, well.. fix it :P
[08:36:32] <alex_joni> (kidding)
[08:38:04] <micges_work> ok I try ;)
[08:38:18] <alex_joni> didn't get a chance to talk to you yesterday
[08:38:53] <micges_work> me too, so np ;)
[08:39:07] <alex_joni> I'm available today if you have time
[08:39:12] <micges_work> I was off at 23.00
[08:39:41] <micges_work> now or evening?
[08:40:02] <alex_joni> even now
[08:40:44] <micges_work> brb
[08:46:59] <micges_work> ok we can talk now, my boss is off :)
[08:50:32] <micges_work> so you talked about joints pos limit and velocity limits
[08:51:18] <micges_work> two kinds of check that could be done (simualtion at canon level or simple check and scale down at motion level)
[08:52:35] <micges_work> I've still no idea how to make teleop with gantry slave joints with scale other that 1:1
[09:01:11] <micges_work> (sync other that 1:1 I mean)
[09:02:17] <alex_joni> back.. was reading the mailing list
[09:02:44] <alex_joni> micges_work: probably the best is to use a special kinematics
[09:03:09] <alex_joni> j[2] = n * pos.x;
[09:03:15] <alex_joni> j[3] = m * pos.x;
[09:03:40] <alex_joni> but the problem is moving the joints for jogging
[09:03:46] <alex_joni> err.. I mean for homing
[09:07:48] <micges_work1> micges_work1 is now known as micges
[09:08:00] <alex_joni> logger_dev: bookmark
[09:08:00] <alex_joni> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-01-05.txt
[09:08:03] <alex_joni> micges: ^^
[09:10:40] <micges> thx
[09:11:41] <micges> homing and jogging are in joint mode so it soesn't matter
[09:12:14] <micges> problem is how to do teleop with that kins?
[09:12:58] <alex_joni> well homing is a problem, as you're not allowed to move one joint without the other
[09:13:05] <alex_joni> or not much as it will break the machine
[09:13:17] <alex_joni> I don't see the teleop problem?
[09:13:27] <micges> oh that problem..
[09:13:28] <micges> I see
[09:14:04] <alex_joni> I wouldn't trust setting homing sequence and just letting the 2 joints run off at the same speed
[09:14:06] <micges> alex_joni: ok I don't see teleop problem
[09:19:18] <micges> why you wouldn't trust? It's not that bad but mechanics must be precise
[09:19:38] <micges> and scales!
[09:19:42] <alex_joni> hmm.. dunno
[09:19:49] <alex_joni> yeah, with encoder feedback it should be ok
[09:19:58] <alex_joni> but most people using gantry would use steppers
[09:20:18] <micges> right
[09:21:01] <alex_joni> maybe it doesn't matter there either.. dunno
[09:23:49] <micges> ok let leave this problem for now
[09:24:07] <alex_joni> ok
[09:24:14] <micges> next is problem what motion should do if there is singularity detected
[09:24:51] <alex_joni> right
[09:25:20] <micges> it's too late for deacc..
[09:25:21] <alex_joni> I think motion should check inverse kins for current position (as it is now) and for the next position
[09:25:41] <alex_joni> but maybe even that is too late
[09:26:52] <micges> problably
[09:26:55] <alex_joni> anyways.. if the kins return a problem, motion should try to get the results again
[09:27:01] <alex_joni> and if that fails too it should error
[09:27:06] <alex_joni> and switch to joint mode
[09:29:07] <micges> mhm
[09:29:33] <micges> so operator can move out from error area
[09:29:46] <alex_joni> right
[09:30:01] <alex_joni> and since in a singularity the kins don't return proper values
[09:31:19] <micges> I see
[09:33:31] <alex_joni> the problem is that you were doing carthesian -> joints transformation
[09:33:34] <alex_joni> and that failed
[09:33:43] <alex_joni> but motion still has the joint positions to switch back to
[09:34:11] <alex_joni> the puma config (the one with genserkins) is quite good to test this
[09:34:16] <alex_joni> as the kins fail sometimes
[09:37:29] <micges> this can be done
[09:38:31] <alex_joni> yup
[09:39:00] <micges> next
[09:40:06] <micges> how can we deal with 'carthesian max_vel changes based on joint position'?
[09:41:07] <alex_joni> what do you have in mind?
[09:42:13] <micges> 2010-01-03 20:57:52 <alex_joni> you know that carthesian max_vel changes based on joint position.. right?
[09:45:47] <micges> is there any way to motion got to know that?
[09:56:16] <alex_joni> I don't think so
[09:56:32] <alex_joni> but that was referring to the 2 ways of solving
[09:56:58] <alex_joni> either simulate the whole move and see if any of the joints go faster than their joint_max_vel
[09:57:20] <alex_joni> or #2 start moving and if a joint is going faster than joint_max_vel clamp the velocity
[10:40:39] <micges> alex_joni: can we continue on the evening? have admin problems here and must go
[10:46:42] <alex_joni> sure, no problem
[17:24:05] <micges> SWPadnos: hi
[17:24:08] <SWPadnos> hi
[17:24:15] <micges> logger_dev: bookmark
[17:24:15] <micges> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-01-05.txt
[17:24:35] <micges> are those numbers satisfy you? ^^
[17:26:24] <SWPadnos> interesting
[17:26:45] <SWPadnos> is there a line missing from the top set? (for emc.draw_dwells)
[17:27:00] <SWPadnos> or is that function only in your patched version?
[17:27:08] <micges> exactly
[17:27:38] <micges> that function born by move python code to c
[17:27:43] <SWPadnos> ok
[17:28:05] <SWPadnos> and the largest number in the "cumtime" column is the actual runtime of the preview generation?
[17:28:19] <SWPadnos> so 16.353 and 2.316 seconds, respectively
[17:28:27] <micges> yes
[17:29:00] <SWPadnos> what is the ncalls column?
[17:29:11] <SWPadnos> did you use emc to do this, or a test program
[17:29:44] <micges> this is part of cProfile output, imported by Axis
[17:29:58] <SWPadnos> ok
[17:30:09] <micges> normal Axis run it was
[17:30:25] <SWPadnos> ok, and how many runs did you do for each version of the code?
[17:30:32] <SWPadnos> is this sim?
[17:31:00] <micges> ?
[17:31:36] <SWPadnos> hmm. actually, this is a profiler, so the actual code execution time is what should be measured, not the elapsed time
[17:32:20] <micges> this is light profiler, python is about 10% slower
[17:32:50] <SWPadnos> I don't know if you ran emc several times and took one of the results, or ran it once for each version and used the only result available :)
[17:33:48] <SWPadnos> in any case, other than my skepticism, it looks like it actually does speed things up
[17:33:49] <SWPadnos> I
[17:34:12] <SWPadnos> I'd just like to know why, since it's counterintuitive that you would see that much of a difference
[17:34:26] <micges> I prepared this patch few days ago and it was always that fast, today I've run it from git pull to get those numbers
[17:35:49] <micges> python calls are slow that's why
[17:36:01] <micges> loops are even slowe
[17:36:02] <micges> r
[17:36:42] <micges> even on my buggy celeron it was faster :)
[17:36:58] <SWPadnos> that's the thing, python is a little bit slower than C, but the work being done by the GL subsystem is a lot larger than the python overhead should be
[17:37:19] <SWPadnos> did you say that there was a more pronounced effect with a faster video card?
[17:37:50] <micges> python is about 5 times slower, counting every case
[17:39:01] <SWPadnos> well, it looks like it is faster, so I'm not against it. I'm just surprised :)
[17:39:03] <micges> each dot in varable name causes python to lookup in varables dictionary so this is another thing that it was so slow
[17:41:04] <micges> SWPadnos: yesterday I've speeded up huge (45MB) dxf loading by 40sec only by make local varables that were pointing to global variables
[17:41:20] <micges> like 'repl = string.replace'
[17:41:42] <SWPadnos> if I get a chance soon, I'll try it out on a 20MB G-code file I have
[17:41:52] <micges> python programming is tricky and fun
[17:46:51] <SWPadnos> all programming should be tricky and fun :)
[17:47:57] <micges> should - that's the proper word ;)
[19:10:41] <jepler> dxf loading? you must be talking about some software that is not emc2 now.
[19:17:47] <alex_joni> jepler: I think micges has a dxf import filter
[20:18:35] <cradek> ... that he has not shared
[20:18:43] <cradek> ... with the rest of the kids in the class
[20:19:47] <skunkworks_> tisk tisk
[20:34:53] <micges> cradek: www.sf.net/projects/vec2ngc
[20:42:08] <cradek> then I take it all back
[20:42:28] <cradek> but I see "anonymous" doesn't like you very much
[20:44:36] <micges> need some fixes ;)
[20:51:28] <jepler_> I think anonymous is the one who has hacked my dsl
[20:52:50] <cradek> micges: it loads my DXF (with polyline even) but I get several errors in generator.py (one error and when I comment out the offending line I get another unrelated error). should I pastebin them?
[20:53:16] <jepler_> jepler_ is now known as jepler
[20:53:23] <micges> cradek: I know that, thanks
[20:53:31] <cradek> ok
[20:53:55] <micges> you can try your complicated dxf and see if it's load
[20:54:18] <micges> rest will be fixed soon
[20:54:26] <cradek> the one I tried was a big pline but I think it had no arcs
[21:02:06] <cradek> hm, I found a file that it imports incorrectly. are you interested in that?
[21:02:14] <cradek> some features are the wrong size/scale
[21:02:38] <micges> yes
[21:06:39] <cradek> see /msg
[22:47:35] <micges> alex_joni: around?
[22:47:45] <alex_joni> yup
[22:50:18] <micges> do you still writing your 'small' program?
[22:50:58] <alex_joni> nope, that's done
[22:51:26] <alex_joni> http://dsplabs.cs.upt.ro/~juve/radio/
[22:51:52] <micges> I can't finish my program from about 2 months, I hate it now :)
[22:52:20] <alex_joni> heh, what is it?
[22:53:35] <micges> machine parts loading, sorting, nesting, some simple shapes generating and export to gcode
[22:53:39] <micges> (bleh)
[22:53:59] <alex_joni> ah, cool
[22:54:31] <alex_joni> mine's the user interface for a wifi radio I'm building for the kitchen
[22:55:18] <micges> ah, more cool ;)
[22:56:15] <micges> re jerk limit: my machine once have 1.0g acceleration
[22:56:58] <micges> but it's weight 400kg and it was all shaking on that
[22:57:30] <micges> too dangerous
[22:58:10] <micges> it can be handy to see what S-curve 1.0g motion would look like
[22:59:45] <alex_joni> yup, should be way better
[23:05:22] <alex_joni> you can probably do a test in hal
[23:05:32] <alex_joni> use limit3 and drive the axis directly
[23:05:39] <alex_joni> compare that to limit2
[23:06:58] <micges> alex_joni: in a few days I'll build bipod simmilar to yours to make real tests of what can I control with kinematics module
[23:07:38] <micges> alex_joni: thanks I'll try to test that
[23:09:49] <alex_joni> but even if the result is better (and I'm sure it is) it still means someone needs to hack/rewrite tp for s-curve
[23:11:43] <micges> yep
[23:14:16] <alex_joni> too many projects ;)
[23:20:56] <micges> off to bed, I'm tired
[23:21:07] <micges> goodnight
[23:22:20] <alex_joni> g'night