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