Back
[01:53:45] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/hal/components/timedelta.comp: show statistics as zero while 'reset' is asserted
[01:56:21] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/scripts/latency-test:
[01:56:21] <CIA-2> EMC: provide a "reset statistics" button
[01:56:21] <CIA-2> EMC: There are various uses for "reset statistics". For example, after a user
[01:56:21] <CIA-2> EMC: determines that a specific action causes bad latency, he can hit "reset
[01:56:21] <CIA-2> EMC: statistics" and then go on testing the next suspected latency source.
[01:56:23] <CIA-2> EMC: Presumably this is easier and faster than closing and restarting the latency
[01:56:25] <CIA-2> EMC: test.
[04:51:11] <CIA-2> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_queue.cc: it's nice to say what kind of move it is
[05:09:59] <CIA-2> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_convert.cc: followup to BJT's test case: make rapids with comp on a little less surprising
[06:30:52] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/docs/man/man9/hostmot2.9: Attempt to clarify the config modparam (though i'm no BJT)
[06:39:50] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (TODO hm2_7i43.c hm2_7i43.h):
[06:39:50] <CIA-2> EMC: The hm2_7i43 driver now supports up to 4 simultaneous 7i43 boards.
[06:39:50] <CIA-2> EMC: At least one PCI parport card is known to work (the OXSEMI PCI952).
[12:47:59] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/examples/gcode.lyx: removed reference to comp example no longer valid
[12:55:03] <CIA-2> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/examples/gcode.lyx: remove reference to smartprobe.ngc
[13:07:20] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ (docs.xml index.tmpl): add user concepts to html
[14:43:44] <cradek> BigJohnT: I fixed the bug (incorrect "gouging" error) that you found with your test program that did the rapids around the clamp.
[14:44:03] <BigJohnT> I saw that :) thanks
[14:44:15] <cradek> good thing that's the last bug!
[14:44:55] <BigJohnT> how do make a gouging error example?
[14:45:18] <cradek> use a big tool and make a little move in a corner that it can't get to
[14:45:33] <cradek> the corner move can be an arc or line
[14:45:55] <BigJohnT> ok
[14:46:25] <BigJohnT> like trying to fit a 1" diameter tool in a 3/4" slot?
[14:48:11] <cradek> yes, for example go left, then up 3/4", then right - if the tool is 1" you will get the gouging error on the 3/4" move
[14:49:04] <cradek> but there are others, imagine an L shape but in the corner of the L, put a little tiny extra move. if the tool is too big to touch it, you will get the gouging error
[14:49:40] <BigJohnT> thanks cradek
[14:50:06] <cradek> welcome, thanks for doing the docs, it's very important on new stuff
[14:50:40] <BigJohnT> np
[16:58:42] <cradek> BigJohnT:
http://timeguy.com/cradek-files/emc/slot-too-small.png
[16:59:24] <cradek> red is the nominal path, white is compensated with a tool too large to get to the left vertical segment
[16:59:34] <BigJohnT> cool
[16:59:42] <cradek> so it gives the gouging error there
[16:59:47] <SWPadnos> note that it doesn't stop when it enters the slot, which requires N-segment lookahead
[17:00:00] <SWPadnos> (N="the rest of the program")
[17:00:13] <seb_kuzminsky> it gouges the top horizontal red segment when it enters the slot?
[17:00:14] <cradek> yeah all it knows is it can't get to that vertical
[17:00:21] <SWPadnos> yes
[17:00:50] <SWPadnos> that's something that is hard(tm) to do in the software, so it should be noted in the manual that it won't save you from every error situation
[17:00:52] <cradek> but if I'd put more segments on the left that it could touch, it would happily gouge its way through the slot
[17:02:36] <BigJohnT> ok that is important to note :)
[17:02:46] <BigJohnT> well I'm really off to lunch now
[17:02:53] <cradek> http://timeguy.com/cradek-files/emc/success-sort-of.png
[17:03:12] <SWPadnos> heh
[17:03:21] <SWPadnos> that's one definition of success :)
[17:03:28] <SWPadnos> "squeezed it in there!"
[17:03:34] <cradek> the difference here is that the tool CAN travel along the right side of that arc
[17:03:54] <cradek> in the previous one, the tool could not travel on the right side of the line because the line is too short
[17:04:11] <cradek> the difference is easy for me to see but I think it is hard to explain
[17:06:18] <seb_kuzminsky> none of the Compile Farm builds build the docs, my buildbot farm is down (moving servers around), and top-of-trunk docs aren't building for me
[17:06:23] <seb_kuzminsky> i'll go bring the vm host back up, bbl
[17:06:34] <cradek> the algorithm does not know anything about gouging or part outlines. it only keeps the tool on one side of a path, going along each segment. in the previous program that was impossible; in this one, it's just fine
[17:08:06] <SWPadnos> seb_kuzminsky, try make clean
[17:08:24] <SWPadnos> I had a similar problem (some pyvcp_led image was missing I think), and make clean fixed it for me
[17:24:48] <cradek> I thought I remembered a bug report about cutter comp inside an arc with tool radius == arc radius
[17:24:58] <cradek> I can't find it on sf though. does anyone else remember it?
[17:25:33] <SWPadnos> I have no memory of it
[17:34:43] <jepler> doesn't ring a bell, but I wouldn't expect it to..
[17:42:01] <cradek> maybe it was never actually filed.
[17:42:16] <cradek> I was hoping to close a bug report, oh well.
[17:42:22] <skunkworks_> maybe on the list?
[17:42:51] <cradek> could be...
[18:21:16] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/docs/man/man9/ (hm2_pci.9 hm2_7i43.9): Note that the config modparam is really an array of strings.
[18:22:32] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/src/Makefile:
[18:22:32] <CIA-2> EMC: Removed the hm2_5i20 driver, as per the prophecy.
[18:22:32] <CIA-2> EMC: No one cares, because everyone's already switched to the hm2_pci driver
[18:22:32] <CIA-2> EMC: like I asked them to, right? ;-)
[18:22:33] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (README TODO hm2_5i20.c hm2_5i20.h):
[18:22:35] <CIA-2> EMC: Removed the hm2_5i20 driver, as per the prophecy.
[18:22:37] <CIA-2> EMC: No one cares, because everyone's already switched to the hm2_pci driver
[18:22:39] <CIA-2> EMC: like I asked them to, right? ;-)
[18:22:57] <skunkworks_> heh
[18:23:13] <skunkworks_> prophecy? I am scared now...
[18:23:24] <seb_kuzminsky> it's jarring each time i commit multiple dirs at the same time and get separate commit messages
[18:27:36] <seb_kuzminsky> hardy has lyx 1.5.3, which can build our docs
[18:27:56] <seb_kuzminsky> hardy-backports has lyx 1.6.1, which fails (exit val = 1) without an error message...
[18:28:20] <seb_kuzminsky> fails on Master_User.lyx, succeeds on the ones before that
[18:52:41] <cradek> uh-oh, my config is broken again!
[18:54:23] <SWPadnos> RTFM!
[18:55:37] <SWPadnos> incidentally, I looked at the "prblem" of making an alias file to port from hm2_5i20 -> hm2_pci
[18:55:52] <SWPadnos> there are other issues that can't be fixed, such as function names
[18:56:33] <SWPadnos> also, the loadrt line needs to be changed significantly (num_encoders=??)
[18:57:29] <SWPadnos> bbiab
[19:02:18] <jepler> hm, function names
[19:50:17] <cradek> * cradek stimulated the economy by buying a carbide boring bar
[19:50:37] <cradek> thru-coolant!
[19:50:40] <cradek> can't wait to try it
[19:52:18] <jepler> in that case, clearly 'alias' should be extended to function names
[19:55:51] <cradek> there's probably even a different number of functions
[19:56:19] <jepler> alias newfname oldf1;oldf2
[19:57:33] <seb_kuzminsky> when switching from hm2_5i20 to hm2_pci, no hal objects change names
[19:57:58] <seb_kuzminsky> no new functions or anything
[19:58:04] <seb_kuzminsky> hal shouldnt even be able to tell
[19:58:16] <seb_kuzminsky> the only change should be what you load with loadrt
[19:58:21] <seb_kuzminsky> everything else stays the same
[20:01:41] <seb_kuzminsky> oh i get it, SWPadnos meant m5i20 -> hm2_pci
[20:32:07] <seb_kuzminsky> hi eric
[20:32:21] <ehj> Hi Sebastian
[20:33:01] <alex_joni> anyone tried edytornc ?
[20:34:04] <alex_joni> http://sourceforge.net/project/screenshots.php?group_id=175588&ssid=50780
[20:36:24] <cradek> "Bold circle"?
[20:36:59] <cradek> (no)
[20:36:59] <seb_kuzminsky> "hey the spall checker didnt complain about it"
[20:39:08] <alex_joni> shecker
[20:40:04] <SWPadnos> you need a grammar checker to catch that one
[20:40:47] <ehj> swp: I have an updated set of debs on my ftp site. I used compiler settings from Mario / EBo specific to the Atom 330. Under emc-pre2.3/smp-debs.
[20:41:32] <SWPadnos> ok, great
[20:41:44] <SWPadnos> how specific to the Atom 33o are the settings?
[20:41:47] <SWPadnos> 330
[20:42:21] <ehj> Just a sec, I will post the reference.
[20:45:53] <ehj> Here:
http://en.gentoo-wiki.com/wiki/Safe_Cflags/Intel#Atom_330
[20:46:32] <SWPadnos> are these 32 or 64 bit kernels?
[20:46:56] <ehj> 32
[20:46:56] <SWPadnos> ok, 32 bit for the others
[20:47:29] <SWPadnos> other than -march=prescott, I don't see anything that should be a problem for any processor younger than ~15 years
[20:47:42] <ehj> k
[20:53:16] <SWPadnos> ok, prescott is P4, so code may possibly not run on a P3 or earlier
[20:53:29] <SWPadnos> also SSE2 and SSE3 could be used
[20:54:06] <alex_joni> SWPadnos:
http://www.gscreencorp.com/
[20:54:29] <SWPadnos> too funny
[20:54:39] <SWPadnos> there's an IBM that has two screens, a 17" and a 15" I think
[20:54:59] <ehj> swp: Instead of prescott I assume?
[20:55:04] <alex_joni> apparently they will build a couple for navy seals
[20:55:13] <SWPadnos> ehj, what?
[20:55:20] <SWPadnos> the prescott selection means this:
[20:55:30] <ehj> SSE2, SSE3
[20:55:32] <SWPadnos> "Improved version of Intel Pentium4 CPU with MMX, SSE, SSE2 and SSE3 instruction set support. "
[20:55:54] <alex_joni> "the frogman-commando IT types will get an Intel CORE 2 Quad QX9300 processor, 4GB of RAM, 500GB hard drive and standard MIL-STD 810F ruggedisation. The SEALs have also specified dual GeForce 8600M graphics cards, Blu-Ray drive, Gigabit networking, WiFi and Bluetooth. It seems they're no fans of Vista - the machines are to come with Windows XP Pro."
[20:56:05] <ehj> Oh, I see. I thought you were referring to a more generic compiler setting.
[20:56:41] <SWPadnos> so two things likely happen. 1, instructions that exist on the P4 are all usable (which may include some that aren't on the P3 or some AMD chips) and 2, the instruction ordering may be optimized for speed on the P4 pipeline
[20:56:44] <SWPadnos> nope
[20:56:54] <SWPadnos> wondering what the implications of -march=prescott were
[20:57:02] <ehj> k
[20:58:52] <alex_joni> SWPadnos: btw, they released the Nehalem-EX Xeon today
[20:58:58] <alex_joni> 8 cores
[20:59:04] <SWPadnos> yay
[20:59:07] <alex_joni> 2.3 billion transistors
[20:59:14] <SWPadnos> and the AM3 CPUs should be out also, I think
[20:59:24] <alex_joni> yeah, that was a couple days ago
[20:59:50] <alex_joni> "This large number of cores and caches led Intel to introduce a new technology called Core and Cache Recovery. "
[21:00:01] <alex_joni> who wants to bet that affects latency (negatively..)
[21:00:08] <ehj> A billion here, a billion there, pretty soon you are talking real speed. :)
[21:01:02] <SWPadnos> a few billion transistors * a few billion Hz clocks and you get a gajillion thingies done every second
[21:01:16] <skunkworks_> I remember - what was it - the 486 hit 1 million - or was it the pentium 60?
[21:02:44] <jepler> skunkworks_: wikipedia says it was the 486 (1.2M transistors, compraed to 275k in 80386)
[21:03:14] <skunkworks_> ah - so my memory isn't that bad today. ;)
[21:03:20] <SWPadnos> probably due in large part to tthe inclusion of the FPU on chip
[21:03:26] <SWPadnos> -t
[21:03:30] <alex_joni> wonder how many transisters skunkworks' memory has
[21:03:35] <skunkworks_> not enough
[21:03:57] <alex_joni> "Like other Nehalem-class processors, this eight-core beast will use Intel's unfortunately named Turbo Mode to borrow power from idle cores and use it to boost the clock speed of active ones"
[21:03:58] <skunkworks_> and some are fuzzy\
[21:04:11] <alex_joni> now that fscks up RT things for good
[21:05:14] <alex_joni> "yeah, well.. you shouldn't have stopped your glxgears test.. you did, and now your RT stuff runs faster.."
[21:08:13] <alex_joni> * alex_joni heads to bed
[21:08:16] <alex_joni> good night all
[21:08:21] <seb_kuzminsky> see ya alex
[22:12:43] <BJT-Hardy> here is another comp that has me confused
http://pastebin.ca/1333136
[23:27:10] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gcode/main.lyx: add info on rapids after a tool change
[23:27:11] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gui/axis.lyx: add info on rapids after a tool change
[23:45:54] <CIA-2> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/common/Stepper_Diagnostics.lyx: reword sometime ago but forgot to commit
[23:47:46] <jepler> BJT-Hardy: how big is your tool T1?
[23:48:25] <BJT-Hardy> it is set on the first line
[23:48:43] <jepler> oh hey look at that!
[23:48:43] <BJT-Hardy> the G10 L1 sets it at R.25
[23:48:54] <jepler> I see it now
[23:48:55] <BJT-Hardy> cool heh
[23:52:54] <jepler> yeah
[23:53:08] <jepler> here's what I see in axis using sim/axis.ini:
http://emergent.unpy.net/index.cgi-files/sandbox/133136.png
[23:53:25] <jepler> I duplicated your path and then did one without G42 to show the uncompensated path
[23:53:54] <jepler> is that like what you're seeing?
[23:54:03] <BJT-Hardy> take out the y0.5 and run it
[23:54:13] <BJT-Hardy> or set the Y to less than .5
[23:57:30] <BJT-Hardy> this
http://imagebin.ca/view/lA1BAHG.html
[23:58:56] <BJT-Hardy> and this
http://imagebin.ca/view/aJr7C8aL.html
[23:59:28] <jepler> so the path with Y0.5 you think is OK, it's smaller Y that you don't get?
[23:59:42] <jepler> what I get when I set Y0.20, and yes it's puzzling:
http://emergent.unpy.net/index.cgi-files/sandbox/133136-0.20.png
