Back
[01:48:54] <jmkasunich> LawrenceG: I am around now
[02:18:07] <CIA-48> EMC: 03cmorley 07TRUNK * 10emc2/docs/man/man1/pyvcp.1: add info about new geometry option to man page
[02:39:01] <jepler_> jepler_ is now known as jepler
[06:44:00] <CIA-48> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/utils/meter.c: add option to set the initial position of halmeter window with -g xpos ypos
[08:01:39] <micges1> micges1 is now known as micges
[08:09:13] <micges> I think this is related to G0 problem described on emc-list:
http://imagebin.ca/view/caNDU7X.html
[08:14:59] <micges> and this too:
http://imagebin.ca/view/Ik6brs4.html
[08:15:47] <micges> two different machines (steppers vs servo)
[08:16:42] <micges> second showed up after 20h of milling :|
[12:27:24] <micges1> micges1 is now known as micges_plasma
[12:58:31] <cradek> micges_plasma: that looks serious, and 20 hours will make it very hard to find
[12:58:46] <cradek> no arcs are involved?
[13:06:47] <micges_plasma> nope
[13:08:47] <cradek> was naive cam active?
[13:10:05] <micges_plasma> it was G61
[13:11:05] <cradek> http://imagebin.ca/view/caNDU7X.html was not G61
[13:11:18] <cradek> you can very clearly see the blending
[13:11:59] <micges_plasma> cradek: that's why I've asked you about your arc skipping bug tracing
[13:12:52] <micges_plasma> cradek: on that one also was G61 but it was reset (look at my last interp commit trying to fix it)
[13:19:56] <micges_plasma> cradek: sorry on that
http://imagebin.ca/view/caNDU7X.html was G64 P0.01
[13:21:34] <micges_plasma> cradek: few minutes ago:
http://imagebin.ca/view/UgcI_Wri.html
[13:22:12] <micges_plasma> before it was like 3 G0 moves was skipped
[13:22:35] <micges_plasma> after that I've added G4 P0.001 after each G0 and result was the same
[13:50:13] <micges> program for 3rd error:
http://www.pastebin.ca/1462175
[14:04:36] <cradek> hm, he left. I'm running his program now.
[14:20:10] <cradek> it completed, and by looking in the X and Y views, I can see that there are no incorrect diagonal moves
[14:20:53] <CIA-48> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py:
[14:20:53] <CIA-48> EMC: don't redraw the big dro when showing plot window, and vice versa
[14:20:53] <CIA-48> EMC: also get rid of some extra polls that don't seem to be doing anything
[14:25:56] <CIA-48> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py:
[14:25:56] <CIA-48> EMC: in big dro, avoid doing some expensive operations every redraw
[14:25:56] <CIA-48> EMC: the font size can be computed only once, and the text widget reconfigured
[14:25:56] <CIA-48> EMC: for the new size only when the size changes. This lowers the percent
[14:25:56] <CIA-48> EMC: CPU spent in X by quite a bit on my system
[14:26:26] <cradek> ooh nifty
[14:27:06] <SWPadnos> I wonder if that's at least part of the "general slowdown" several people have noticed
[14:27:29] <SWPadnos> huh - could there be a memory leak somewhere in that DRO code?
[14:27:31] <cradek> jepler: what do you think about making the backplot history limit shorter?
[14:27:53] <jepler> I don't know how to gather the information to make a right decision
[14:28:20] <cradek> do we know it still works right? I'm not sure I've ever seen it clearing the path
[14:32:46] <jepler> I set the value down to 100 and yes it works
[14:32:57] <jepler> "joint 0 amplifier fault"
[14:33:13] <cradek> ?
[14:33:17] <SWPadnos> are you channeling micges?
[14:33:31] <jepler> oh, I left something from an earlier test
[14:34:41] <jepler> amplifier fault when some condition was detected, so that I could both trigger on it and be sure to still have the backplot
[14:37:35] <jepler> cradek: drop it by half or 90% or whatever .. we'll see if people complain, or if they don't notice, or if they like it
[14:38:45] <jepler> 100 (.1% of the original?) is way too low
[14:39:05] <cradek> is that inches or something? points?
[14:39:08] <jepler> points
[14:39:13] <jepler> so it has no real relationship to distance or time
[14:39:22] <jepler> I was running flowsnake which is basically a worst case
[14:39:26] <cradek> but it does relate to how hard it is to draw
[14:39:30] <jepler> yes
[14:39:43] <jepler> arcspiral would be another one to test to see what "1000" or "10000" means..
[14:39:49] <cradek> and size in memory
[14:40:22] <cradek> wonder if it's memory size or drawing of many points that makes it slow
[14:40:30] <jepler> I assume it's the drawing of it
[14:41:05] <jepler> a "logger point" is about 28 bytes, so 100k of them is less than 3 megs
[14:41:33] <SWPadnos> I bet you'd see it nicely on Jon Elson's circle torture test
[14:41:58] <cradek> is 100k the current number?
[14:42:06] <jepler> cradek: yes I think so
[14:42:15] <jepler> 1675 #define MAX_POINTS (100000)
[14:42:17] <jepler> emcmodule.cc
[14:42:18] <cradek> SWPadnos: a regular old arc would give the very same backplot
[14:42:27] <SWPadnos> hmm - actually, is there any guarantee that a motion segment will cause one or more points to appear on the backplot?
[14:42:31] <jepler> no
[14:42:33] <SWPadnos> yeah - I was just thinking that through
[14:43:26] <cradek> jepler: if we want to reduce MAX_POINTS maybe we could compensate somewhat by relaxing the colinear test
[14:43:36] <cradek> it may be much tighter than necessary
[14:44:10] <cradek> we don't know how many points are used in a typical blended corner, for instance - it may be a lot
[14:44:14] <jepler> units are always inches here, right?
[14:44:19] <cradek> yes
[14:49:08] <jepler> maybe make the colinearity test 1e-5 then?
[14:50:00] <cradek> I don't know the number that is as loose as possible but will still give a decent display
[14:50:27] <jepler> it should probably be based on an axis SCALE
[14:52:46] <cradek> I don't think so, since it's like an angle
[14:53:12] <jepler> maybe I don't understand what the test is
[14:53:14] <cradek> micges: I ran your program and it worked correctly. have you ever reproduced the problem on an unmodified sim?
[14:53:57] <cradek> jepler: I think it's dot product (cos angle)
[14:55:49] <micges> cradek: I've never reproduced error even after hours of tests :|
[14:56:06] <cradek> jepler: if you wanted a 1 degree deviation to cause a new point, I think you'd make epsilon 1 - cos 1 = 1e-4
[14:56:25] <cradek> ... I think
[14:57:37] <cradek> I think 1e-8, the current value, gives a corner every 0.008 degrees
[14:58:29] <jepler> hm, I have a suspicion about that code
[14:58:30] <cradek> micges: yuck.
[14:58:45] <jepler> * jepler tries to figure out a test
[15:00:01] <cradek> micges: if you turn on floating point exception traps and run in the debugger, you may see when uninitialized memory is used. (that was what caused the previous arc-skipping behavior)
[15:00:13] <cradek> of course you can't do this for the realtime parts, only task
[15:00:42] <jepler> Run time: 1602.2 minutes
[15:00:49] <jepler> maybe this test will turn out to be impractica
[15:00:51] <jepler> l
[15:01:39] <cradek> micges: see comment in emctaskmain.cc
[15:01:47] <cradek> jepler: yeah, that sounds bad
[15:02:14] <micges> cradek: I see it
[15:04:47] <jepler> ok, nevermind -- if there's a problem with the colinearity test in the backplot, it's not as simple as I thought
[15:04:53] <jepler> bbl
[15:04:59] <micges> cradek: jepler: take look at this patch:
http://www.pastebin.ca/1462247
[15:06:11] <cradek> jepler: it looks right to me - can you describe what you think is wrong?
[15:09:27] <cradek> micges: what am I looking for?
[15:10:54] <micges> are there initial values correct there
[15:11:42] <micges> there are not all zeros there so I'm asking
[15:26:24] <micges> bbl
[15:33:39] <jepler> curse C++ for its decision to never implicitly initialize scalar values in structures
[15:35:24] <SWPadnos> if it did, you (or someoen) would curse it for being slow and bloated :)
[15:35:27] <SWPadnos> someone
[15:35:31] <cradek> micges: sorry, I don't know enough to say whether it's right
[19:54:08] <CIA-48> EMC: 03micges 07TRUNK * 10emc2/src/emc/nml_intf/ (emc.hh emc_nml.hh emcops.cc): initialized all fields of main nml structures when created
[20:25:14] <jepler> multi-statement macros:
http://www.rtems.com/ml/rtems-users/2001/august/msg00086.html
[20:26:26] <SWPadnos> if that's in reference to the latest commit - there's also the option of making a zero constructor / member function
[20:26:45] <jepler> yes it is, but that macro is useful in C code too
[20:26:52] <jepler> (many uses of the pose structure are in C, not C++)
[20:28:03] <SWPadnos> true
[20:29:08] <CIA-48> EMC: 03jepler 07TRUNK * 10emc2/src/emc/nml_intf/ (emc.hh emcpos.h): C code would nice to use ZERO_EMC_POSE too. Also, use a safer form of multi-statement macro
[20:31:13] <CIA-48> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc:
[20:31:13] <CIA-48> EMC: Decrease total number of backplot points shown, and increase maximum angle
[20:31:13] <CIA-48> EMC: permitted between points to be treated as colinear for purposes of the backplot
[20:31:45] <CIA-48> EMC: 03jepler 07TRUNK * 10emc2/src/emc/motion/ (command.c control.c): Use pose-clearing macro instead of individual assignments
[20:34:43] <CIA-48> EMC: 03jepler 07TRUNK * 10emc2/src/emc/motion/motion.c: use pose-clearing macro
[20:35:21] <CIA-48> EMC: 03jepler 07TRUNK * 10emc2/src/emc/kinematics/tp.c: use pose-clearing macro
[20:35:22] <CIA-48> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/ (halui.cc shcom.cc): use pose-clearing macro
[20:36:37] <CIA-48> EMC: 03jepler 07TRUNK * 10emc2/src/emc/kinematics/tp.c: use pose-clearing macro
[20:54:43] <micges> jepler: cool. that was my next change :)
[21:40:15] <micges> jepler: does functionality of use SPINDLE_OFF_WAIT was/will be ever programmed ? (emcglb.c)
[22:10:59] <jepler> it's entirely possible that emc1 did something with it; I dunno
[22:11:16] <jepler> I'd look for a hal-based way (like spindle-at-speed) if you want to have a wait when stopping the spindle
[22:26:59] <CIA-48> EMC: 03micges 07TRUNK * 10emc2/src/emc/nml_intf/ (emc.hh emccfg.h emcglb.c emcglb.h): remove obsolete spindle related items
[22:59:52] <micges> good night all