EMC: 03jepler 07v2.4_branch * rb8d45acd5fdd 10/src/emc/usr_intf/stepconf/stepconf.py: Fix period, maxvel calculations in axis test
anone saw something like this?: http://www.pastebin.ca/1830014
looks like debian has a bug about the i915 message. I assume that's what you're asking about? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467319
another bug in mesa that hangs emc :/
it's probably not in the mesa driver
though it could be something weird with the way the PCI bridge is being used
there is "mesa" the implementation of OpenGL and "mesa" the interface card.
heh, true enough
time for more coffee
micges_work1: is that 8.04?
on that pc there are many other bug of mesa opengl
looks like ubuntu hasn't packaged the version of libgl1-mesa-dri that fixed 467319
you could always do whatever it is to turn off direct rendering / hardware opengl and accept the performance hit
heh can't do that, with hw acceleration there is 0,7 fps in Axis preview on our programs :)
it seems this is the change that fixes it: http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_0_branch&id=709f24adbb21419881f0d857c8454814f85c2757
wow those must be big programs
yes they are
30-40h of work
you should run smaller programs instead
jepler: thanks for links
* jepler is the king of google
* seb_kuzminsky is glad it's that *other* mesa that's at fault this time
I hear there's another HAL too :)
naming a hardware abstraction layer "HAL" is like naming a library "LIB"
jmkasunich: package recieved! thanks again.
he must like you better
I am closer
skunkworks_: what's for christmas?
bunch of opto22 modules
jepler, I've just posted a patch to somewhat optimize code loading into AXIS, could you please review it?
your editor changed a bunch of whitespace. Trailing whitespace is bad, but removing it AND changing other things in the same commit makes it much harder to review the functional changes.
likewise getting rid of these very old emc1-compatiblity defines should be a separate commit; I don't think it has any effect on loading speed
-#define active_settings interp_new.active_settings
- interp_new.error_text(err, savedError, LINELEN);
+ interp.error_text(err, savedError, LINELEN);
this is also a different matter, should be a different commit:
- STRAIGHT_FEED(12345, P1.X,P1.Y, _pos_z, _pos_a, _pos_b, _pos_c, _pos_u, _pos_v, _pos_w);
+ STRAIGHT_FEED(line_number, P1.X,P1.Y, _pos_z, _pos_a, _pos_b, _pos_c, _pos_u, _pos_v, _pos_w);
I can create a series if you like
looks like some changes at the end are just whitespace? that might be a mistake your editor made.
so let me see if I understand the actual changes that are increasing performance. first, you avoid doing extra math when there is no rotation. second, you decrease the number of "next_line" calls.
for the former it sure seems possible that would speed it up some
no, number of calls to next_line is the same,
I just do not allocate stats object if line did not change
I see that now
any performance measurements?
no, still did not figure out how to do that in python
one very simple but inaccurate way is: time axis-remote --reload
nurbs line select started to work though
aystarik@thinkpad:~/cnc/emc/emc2-dev$ time axis-remote --reload
X server insecure (must use xauth-style authorization); command ignored
did not work, I guess
oh, you have a broken ubuntu. maybe they'll fix that bug in the next 4 years sometime.
this is odd behavior. Loading a part program with about 40000 G1 moves over multiple trials gave the following timings: 28s; 16s; 12s; 10s; 9s; 9s; 9s; 10s; 9s
I wonder why the first loads were slower
I recommend testing rotation if you mess with it... load up systems.ngc, offset and rotate some of the systems, run to see if the preview matches.
my version of aystarik's changes take a second off the load time of this file, 9s to 8s
overhead is about 1.6s
~10% -- noticable
re: first time vs. second time -- may be python optimizes code paths?
here's what I did timings with: http://emergent.unpy.net/files/sandbox/my-version-of-aystarik-speedups.mbox
jepler, you did not change maybe_new_line(void) to call interp.line()
also if you change anything with line numbers, make sure click-select still works right with a program using cutter comp
sent the patch as a series of independent changes.
hm, I bet the axis preview is wrong when you use cutter comp and set the tool radius using G10
EMC: 03jepler 07v2.4_branch * r0de098a4d455 10/src/emc/usr_intf/axis/scripts/axis.py: fix a memory leak
guys, NURBS does not work in master?
butterfly.ngc does not run...
last I tried, it sort of worked
but yeah, it's sure not right
now it stops at F600
mostly we put the code in so we wouldn't lose it - in case someone wanted to work on finishing it. In hindsight I'm not sure if that was a good idea or not.
phew. I just about panicked there. I was trying to run 2.4, but sim/axis wouldn't go to "machine on". I eventually found that I had two TRUNK milltasks still running under valgrind; dunno exactly how I got in that state, but it sure made emc unhappy.
incidentally, butterfly.ngc at the tip of v2.4_branch gives me similar behavior: it gets stuck showing line 6 (G1 Z-5 F100) as the current line, but having moved a small distance on the curve from G5.x
it did work less poorly than this at some point, but I don't recall when...
jepler, do you like series I've sent?
Resolved 'src/emc/usr_intf/axis/scripts/axis.py' using previous resolution.
ooh, that's cool
EMC: 03jepler 07master * rff4f97372f11 10/src/po/fr.po: French translation update
EMC: 03jepler 07master * rb8d45acd5fdd 10/src/emc/usr_intf/stepconf/stepconf.py: Fix period, maxvel calculations in axis test
EMC: 03jepler 07master * r1e3c57753a29 10/src/emc/rs274ngc/gcodemodule.cc: avoid unneeded work when sequence_number is unchanged
EMC: 03jepler 07master * rdd20c323367b 10/lib/python/rs274/interpret.py: avoid extra work when there's no rotation
EMC: 03jepler 07master * rf28154ab0686 10/src/emc/rs274ngc/gcodemodule.cc: simplify maybe_new_line with default argument
EMC: 03jepler 07master * re7de306526bb 10/src/emc/rs274ngc/gcodemodule.cc: get rid of some emc1-compatibility defines
EMC: 03jepler 07master * r75ce038f1f11 10/src/emc/rs274ngc/gcodemodule.cc: get rid of unused variable
EMC: 03jepler 07master * rf80f1c2f6882 10/src/emc/rs274ngc/gcodemodule.cc: get rid of unneeded declarations
EMC: 03jepler 07master * r898a1e15127c 10/src/emc/rs274ngc/gcodemodule.cc: add static qualifiers where appropriate
EMC: 03jepler 07master * r0de098a4d455 10/src/emc/usr_intf/axis/scripts/axis.py: fix a memory leak
EMC: 03jepler 07master * r9cad9886b6e0 10/src/emc/usr_intf/axis/scripts/axis.py: fix a memory leak
EMC: 03jepler 07master * rcab34489d40f 10/src/emc/usr_intf/stepconf/stepconf.py: Merge remote branch 'origin/v2.4_branch'
aystarik: yes, I like the idea of the speed up patches. I didn't look at all the other things in that file you attached to your message.
that's fine. thanks!