Back
[00:51:00] <ledvinap> Hello ... I just finished simple patch to allow stepcont to configured machine with all limit and home switches wired to single pin...
[00:51:43] <ledvinap> Anyone here can review it? ...
[13:01:04] <CIA-81> EMC: 03jthornton 07master * r0a3a037804a8 10/docs/src/ (4 files): Change version in documents
[13:05:06] <CIA-81> EMC: 03jthornton 07v2.4_branch * r8dc56c21105b 10/docs/src/ (4 files): update preamble version number
[16:43:53] <cradek> how do I start using the new firmwares? On my machine running 2.4 branch, I have a symlink ... somewhere to ... something
[16:46:00] <jepler> download and install the right .deb from my blog --
http://media.unpythonic.net/emergent-files/01263684229/hostmot2-firmware-5i20_0.4_all.deb
[16:46:11] <jepler> I have to confess I haven't actually installed the debs yet :-/
[16:46:31] <jepler> for 5i20 the firmware path names should be the same as from the emc2-firmware package
[16:46:56] <cradek> ok, I figure I should start using that if I want to do the best testing.
[16:47:12] <cradek> did you push your task fix yet?
[16:47:18] <jepler> not yet
[16:47:27] <cradek> will you put it in 2.3.5?
[16:47:34] <SWPLinux> should the individual firmware debs conflict with the combined firmware deb?
[16:48:21] <jepler> SWPLinux: hostmot2-firmware-all is a package that contains no firmwares but depends on all the other firmware packages
[16:48:44] <SWPLinux> oh. I thought there was a different package that actually had all of the firmwares in it
[17:20:51] <jepler> cradek: do you think I should put the start-with-step fix in 2.3.5?
[17:33:01] <cradek> jepler: if it's right, definitely
[17:33:09] <jepler> who can say..
[17:33:18] <jepler> I haven't found anything that it makes more broken
[17:33:29] <cradek> that's a close second best
[17:33:31] <jepler> but I didn't test it much more after the other afternoon (was that yesterday? or monday?)
[17:34:04] <cradek> are you going to come drill holes tonight?
[17:34:32] <jepler> I think tonight would work for me.
[17:34:36] <cradek> ok
[17:46:48] <jepler> can anyone test the proposed stepconf all-limit-home patch?
[17:48:32] <cradek> I don't have suitable hardware for that
[17:48:54] <jepler> same here
[17:49:01] <jepler> I can only see that it looks plausible
[17:52:31] <JT-Work> jepler: what kind of hardware to you need to test it?
[17:53:59] <jepler> JT-Work: a stepper machine with all home and limit switches shared on a single input
[17:54:14] <SWPLinux> and an actual parallel port and stuff :)
[17:54:18] <jepler> right
[17:55:21] <JT-Work> could you simulate the switch with a single switch input to the parallel port?
[17:55:33] <JT-Work> na, dumb idea
[17:56:12] <JT-Work> connect all the switches with hal?
[17:56:36] <JT-Work> my plasma has three inputs for limits and homing one for each axis
[18:28:55] <JanVanGilsen> Shouldn't puma560_sim_6.hal use axis.N.joint-pos-fb instead of axis.N.motor-pos-fb for the vismach simulation?
[19:48:29] <aystarik> recent axis does not update DRO tab... Only while changing from view to dro.
[19:49:23] <cradek> what version?
[19:50:22] <aystarik> git from yesterday or so...
[19:50:36] <cradek> oh git master?
[19:50:55] <aystarik> yes.
[19:52:15] <cradek> I see it too
[19:52:41] <jepler> yeah
[19:53:19] <aystarik> I would guess 2.4 branch is broken too then...
[19:53:48] <jepler> more likely it got broken when I merged glrefactor into master
[19:54:13] <aystarik> what is the date?
[19:55:14] <aystarik> jepler, is there any way to accelerate loading of big programs?
[19:55:32] <aystarik> and possibly redraw?
[19:56:22] <jepler> the commit I'm talking about is bae58918225cedb13e250b1ebc72ae58f44b920e and the commit before it that is probably good is 68a3312b5a4418a4b14258fcfe8c4a34a45d2144 but I haven't tested that
[19:57:10] <jepler> as for speeding up loading/redrawing, I don't know of any obvious targets for optimization right now.
[19:57:20] <jepler> you might talk to micges, he's taken an interest in that lately
[19:57:45] <cradek> that's one thing you can really improve with a fast computer. otherwise, if you don't care if the preview is complete, you can use (AXIS,stop) to disable it
[19:59:07] <aystarik> is it comment in .ngc file?
[19:59:31] <jepler> http://linuxcnc.org/docs/html/gui_axis.html#r1_11_7
[20:00:42] <aystarik> thanks!
[20:03:24] <jepler> anyone want to confirm whether 2.4's big dro is OK and save me the trouble/
[20:03:25] <jepler> ?
[20:04:35] <aystarik> doing that right now
[20:04:41] <jepler> you can also tell me whether this one-line fix makes master happy:
[20:04:42] <jepler> def redraw_dro(self):
[20:04:42] <jepler> + self.stat.poll()
[20:04:42] <jepler> limit, homed, posstrs, droposstrs = self.posstrs()
[20:04:56] <jepler> (in axis.py)
[20:05:19] <micges> aystarik: there is little room of speed up loading programs
[20:05:53] <aystarik> I was thinking of adaptive number of circle breaks for one...
[20:06:39] <aystarik> right now it is hardcoded as 128 or so...
[20:06:56] <jepler> adaptive based on what? For some users it might be OK for a 10mm circle to be drawn with only a few segments because it's small; for others, a 10mm circle is big
[20:09:24] <jepler> the decision has to be made at load time, not at each redraw; having each redraw resegment the circles would kill performance
[20:09:59] <jepler> (one OpenGL API call, glCallList, redraws the preview plot)
[20:10:26] <jepler> (if you turn it into dozens or hundreds of Python statements for each arc, you've just killed performance)
[20:12:11] <jepler> (hm, I should add a special comment to clear the backplot..)
[20:12:23] <jepler> (is that possible?)
[20:12:36] <jepler> ((why are we talking in parentheses?))
[20:13:21] <cradek> (((I didn't believe all arcs are drawn with 128 steps, and I was right)))
[20:14:39] <micges> aystarik: do you have any test program to show slow loading in axis?
[20:15:20] <aystarik> I have program which _breaks_ current axis master...
[20:15:31] <micges> I'll test and see where (if any) are some parts to optimize
[20:16:03] <cradek> actually, I think it uses anywhere from 8 to 256 lines: steps = max(8, int(128 * abs(theta1 - theta2) / math.pi))
[20:16:18] <aystarik> please remind me where do all uploads go?
[20:16:27] <cradek> http://pastebin.ca works ok
[20:16:37] <micges> www.filebin.ca also
[20:17:26] <aystarik> it is 628kb. do you prefer it zipped?
[20:18:01] <skunkworks> aystarik: how does it break it?
[20:18:08] <micges> aystarik: yes
[20:20:01] <aystarik> python: vbo/vbo_save_api.c:217: map_vertex_store: Assertion `vertex_store->buffer' failed.
[20:20:01] <aystarik> /home/aystarik/cnc/emc/emc2-dev/scripts/emc: line 654: 9189 Aborted $EMCDISPLAY -ini "$INIFILE" $EMCDISPLAYARGS $EXTRA_ARGS
[20:20:01] <aystarik> Shutting down and cleaning up EMC2...
[20:20:01] <aystarik> Cleanup done
[20:20:01] <aystarik> EMC terminated with an error. You can find more information in the log:
[20:20:40] <jepler> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539455
[20:21:12] <aystarik> updates of DRO in 2.4 are ok.
[20:21:14] <jepler> looks like axis is not alone in triggering this bug in some opengl driver
[20:21:26] <cradek> radeon?
[20:21:34] <jepler> the bugreport I found said intel
[20:21:40] <cradek> http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.ati/12864
[20:21:54] <micges> I have that bug too
[20:21:58] <micges> on intel
[20:22:04] <jepler> but a total guess based on the assertion implies that it might be a general bug in mesa-based opengl
[20:22:19] <cradek> yuck
[20:22:28] <aystarik> I have radeon here...
[20:22:36] <jepler> src/mesa/vbo/vbo_save_api.c |
[20:23:36] <jepler> anyway, here's a part program that takes a long time to load: G90 / G0 X0Y0Z0 / O100 repeat [100000] / G1 X1Y1Z1 F999 / O100 endrepeat / M2
[20:25:37] <aystarik> :)
[20:26:02] <aystarik> small patch works for DRO
[20:26:25] <jepler> thanks for verifying, will push
[20:27:32] <jepler> bbl
[20:27:47] <CIA-81> EMC: 03jepler 07master * r8a74ef6760b4 10/src/emc/usr_intf/axis/scripts/axis.py: fix big dro not updating
[20:27:47] <CIA-81> EMC: 03jepler 07master * r7b018b24ea2e 10/share/axis/tcl/dialog.tcl: fix specifying dialog accelerator list
[20:33:35] <aystarik> micges, does axis redraw the view while in DRO tab?
[20:34:45] <micges> no
[20:37:51] <aystarik> cool... it actually does not even break if in DRO :)
[20:38:31] <micges> aystarik: I've found some bottlenecks, will talk about them with jepler
[20:38:43] <micges> aystarik: can you give me that file?
[20:39:12] <aystarik> yes, uploading right now
[20:41:26] <aystarik> http://filebin.ca/kmzofr -- it appears to be several stamps with M1 separating them...
[20:44:15] <micges> aystarik: paste at pastebin.ca unzipped
[20:44:28] <micges> can't extract on 8.04
[20:44:35] <aystarik> it was gzip.
[20:44:50] <micges> strange
[20:45:23] <jepler> $ gunzip < kmzofr > aystarik.ngc
[20:45:25] <cradek> wfm
[20:45:26] <jepler> worked fine for me
[20:47:20] <micges> damn gui tools
[20:50:21] <jepler> curious .. I can't click on the big arcs to select them
[20:51:03] <jepler> the one on line 19 for intstance. I can click it in the program text, but not in the plot
[20:52:44] <aystarik> m/b there are too many of them in one place?
[20:52:59] <jepler> it's not just arcs .. the straight move in line 530 is another one I can't click on
[20:54:45] <jepler> that may be the pattern
[20:55:00] <jepler> if I rotate so that the central area is viewed nearly edge on I can't select from the parts with lots of lines there either
[20:55:05] <jepler> parts I can select when in the X view
[20:55:07] <jepler> er, Z view
[20:56:03] <cradek> I don't think I can click any preview lines to select them
[20:56:35] <cradek> I'm wrong - I can select some
[20:59:23] <jepler> can you tell the pattern?
[21:00:13] <cradek> seems like I can select any of the (overlapped-looking) things in the inner circle, but nothing else
[21:00:50] <jepler> @@ -346 +346 @@ class GlCanonDraw:
[21:00:51] <jepler> - self.select_buffer_size = 100
[21:00:51] <jepler> + self.select_buffer_size = 10000
[21:00:56] <jepler> this makes it work
[21:01:11] <cradek> I think it fails when two or more lines are 'close enough' to the click
[21:01:39] <jepler> the theory of the code near there is that the "select buffer" is doubled until it is big enough, with 100 being the default. However, instead of throwing a GL_STACK_OVERFLOW in that case it's returning 0
[21:06:35] <jepler> looks like I simply never tested this code..
[21:07:57] <jepler> GL_STACK_OVERFLOW doesn't even make sense
[21:09:00] <aystarik> micges: what bottlenecks did you notice? May I help?
[21:10:02] <micges> your programs shows that processing arcs are very slow
[21:11:06] <micges> here my program show that generating gcode in text widget is very slow
[21:11:36] <micges> aystarik: you can help by getting more programs like this ;P
[21:12:42] <micges> aystarik: first part can be fixed by optimize function arc_feed in interp.py line 56
[21:12:53] <jepler> the individual programs are seldom that interesting. It's much easier to write a program to do a million dwells, or a thousand arcs, or whatever.
[21:13:23] <jepler> (or a million G1s that go nowhere, like my earlier example :-P)
[21:13:48] <micges> jepler: real examples are much better imo
[21:13:59] <jepler> my ho is different
[21:16:01] <micges> jepler: I don't think if you would focus on unable selecting line in your million line gcode
[21:17:10] <CIA-81> EMC: 03jepler 07master * rd0cc290310fc 10/ (2 files in 2 dirs): fix clicking preview plot where lots of motions overlap
[21:42:18] <aystarik> is there any profiler for python?
[21:47:54] <jepler> like any good thing, there are several. the best one to choose depends on your Python version.
http://docs.python.org/library/profile.html
[21:52:37] <aystarik> do you know how to use them with axis?
[21:53:23] <aystarik> btw, changing 128 to 32 in the equation above saved my day -- I can load this program now.
[21:53:46] <aystarik> and I can't see angles in arcs.
[22:02:16] <aystarik> well, even 16 works for me -- segments are visible, but tolerable.
[22:02:31] <aystarik> min value might be 3 too.
[22:04:55] <jepler> this speeds up loading by about 20% (51 seconds -> 39 seconds on my system using your part program) but is pretty gross
[22:05:51] <jepler> ..
http://emergent.unpy.net/files/sandbox/0001-speed-up-arc-loading-20-by-aggressive-manual-inlinin.patch
[22:10:46] <jepler> for master I'd consider a patch that gives an inifile or gui choice between "high" and "low" quality arc preview
[22:11:09] <jepler> decreasing the minimum number of segments unconditionally is probably fine
[22:12:03] <jt-plasma> would it make sense to have a menu choice for that?
[22:12:31] <jepler> yeah, one sensible option would be a checkbox in a menu
[22:12:44] <jepler> saved to ~/.axis_preferences automatically
[22:13:47] <jepler> "high quality arc preview" might be a sensible text to go with it
[22:14:00] <jt-plasma> yea
[22:16:30] <jepler> bbl
[22:24:40] <aystarik> micges: steps = max(3, int(24 * abs(theta1 - theta2) / math.pi)) -- works quite good, also can save on rad calculation...
[22:28:04] <micges> cool
[22:41:42] <alex_joni> logger_dev: bookmark
[22:41:42] <alex_joni> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-02-10.txt
[22:41:50] <alex_joni> micges, aystarik: ^^
[22:42:31] <aystarik> alex_joni: hi
[22:43:05] <alex_joni> hi
[22:44:29] <alex_joni> dobryi vecher
[22:46:30] <micges> bună seara
[22:47:50] <alex_joni> :P
[23:26:01] <micges> noapte bună