Back
[00:15:34] <skunkworks> cradek: ?
[00:16:56] <skunkworks> very big radius arc
[00:20:44] <KimK> And cutting pretty fast, too!
[01:25:06] <cradek> skunkworks: heekscnc output that wasn't quite right
[01:25:39] <cradek> wonder if jt's mill is at ground level yet
[01:28:02] <skunkworks> yeck
[01:29:29] <skunkworks> did you find time to do your programing?
[01:30:18] <cradek> yep
[01:30:39] <cradek> customer said - cool, I tried it, it's great, now I want it to do something else too
[01:31:11] <skunkworks> nice!\
[01:32:09] <cradek> depending on how you look at it, I guess...
[01:32:31] <skunkworks> money is good.. ;)
[01:36:31] <skunkworks> even if it is the root of all evil ;)
[01:51:02] <KimK> No, there's nothing wrong with money. It's the *love* of money that
[01:51:40] <KimK> No, there's nothing wrong with money. It's the *love* of money that's the problem:
http://www.biblegateway.com/passage/?search=1%20Timothy%206:10&version=NKJV
[01:51:54] <KimK> (Sorry for the misfire, lol)
[01:52:19] <KimK> How's everybody this evening?
[01:53:46] <cradek> hi KimK
[01:54:53] <cradek> fine here
[01:54:59] <KimK> Hi cradek, sorry nothing to patch yet, but I'll try to find something in the next day or two, just as a test.
[01:55:00] <cradek> poor jt
[01:55:05] <cradek> cool
[01:55:41] <KimK> Yeah, congrats to JT on his new machine, I saw some (maybe not all) of the pictures.
[07:34:43] <micges_work> patch for review for master: removing redundant checks from convert_probe()
http://pastebin.com/yBpFCctp
[07:46:49] <alex_joni> huh, line 19 and 22 are really twice?
[07:47:19] <micges_work> looks like
[07:49:46] <micges_work> proposed patch for 2.4: fixing probe error message when using g38.2 or g38.4:
http://pastebin.com/iM9ZyUxH
[11:59:44] <jepler> micges_work: I can't get git to apply those patches
[11:59:51] <jepler> error: patch failed: src/emc/rs274ngc/interp_convert.cc:3062
[11:59:51] <jepler> error: src/emc/rs274ngc/interp_convert.cc: patch does not apply
[12:01:25] <alex_joni> jepler: both?
[12:04:35] <jepler> alex_joni: yes, but obviously with different filenames
[12:04:48] <jepler> $ wget -O- -o/dev/null '
http://pastebin.com/download.php?i=yBpFCctp' | git apply
[12:04:51] <jepler> fatal: corrupt patch at line 37
[12:05:10] <jepler> first problem: no trailing newline
[12:05:12] <jepler> $ (wget -O- -o/dev/null '
http://pastebin.com/download.php?i=yBpFCctp'; echo) | git apply
[12:05:15] <jepler> error: patch failed: src/emc/rs274ngc/interp_convert.cc:3062
[12:05:17] <jepler> error: src/emc/rs274ngc/interp_convert.cc: patch does not apply
[12:05:17] <jepler> second problem: patch is broken anyway
[12:05:20] <jepler> error: patch failed: src/emc/rs274ngc/rs274ngc_return.hh:187
[12:05:22] <jepler> error: src/emc/rs274ngc/rs274ngc_return.hh: patch does not apply
[12:06:42] <alex_joni> one's for master, one for 2.4..
[12:07:14] <alex_joni> but anyways, micges_work should probably know :D
[12:07:29] <jepler> anyway, the downside for changing a message in 2.4 "for the better" is that it breaks translations of the message until someone retranslates it
[12:07:46] <jepler> in this case it looks like there's only one translation of the message (pt_BR), which surprises me
[12:08:43] <jepler> alex_joni: I tried in a 2.4_branch and master both
[12:08:54] <alex_joni> yeah, thought you might have
[12:10:40] <jepler> it might still be something pastebin is doing to the patch; I don't really trust them for patches
[12:11:54] <jepler> bbl, time to go to the office
[12:13:04] <Jymmm> why using pastebin instead of codepad.org
[12:28:45] <micges_work> jepler: will fix patches later
[12:28:51] <micges_work> *I'll
[14:04:05] <jepler> it is possible to check that the interpreter rejects snippets of gcode that it should:
http://emergent.unpy.net/files/sandbox/test-bad-gcode-is-rejected.mbox
[14:05:26] <jepler> I'm thinking of adding that to 2.4, since it can't affect the correctness of the software, and runtest errors are caught right away so if I got it wrong we'll notice
[14:08:03] <cradek> jepler: can it test a multiline program, or just individual lines?
[14:08:38] <cradek> g41 / ... / g40 / g2 ... should be rejected
[14:08:41] <cradek> for instance
[14:09:02] <jepler> cradek: yes, it can (just embed \ns in the test)
[14:09:08] <cradek> aha
[14:09:09] <jepler> I was going to add a gouging test, actually
[14:37:03] <jepler> http://emergent.unpy.net/files/sandbox/test-bad-gcode-is-rejected-v2.mbox
[14:37:39] <jepler> I checked again and found a bug in runtests that made my new test not work right. Also, I added a few more tests including some multiline ones.
[14:47:30] <ries_> ries_ is now known as ries
[16:13:15] <cradek> jepler: could tests=[ ] be a list of files instead? I think it'd be better because they'd look like gcode programs, the diffs would make more sense, and you could load them in AXIS to preview/manipulate
[16:13:35] <jepler> cradek: good idea
[16:13:51] <cradek> and you could call them no-feed-rate.ngc, no-axis-letters.ngc
[16:16:39] <jepler> should I add 'm2' to them, like I do in the current version?
[16:16:59] <cradek> no, I think the programs should be complete (the .ngc file should contain the m2)
[16:17:02] <jepler> OK
[16:18:20] <jepler> since this doesn't test that the error message matches, that means if you forget m2 in your test, then the gcode becomes accepted, the test won't catch it
[16:18:47] <cradek> bleh
[16:19:13] <cradek> I guess we can watch for that
[16:19:46] <jepler> or you could have to embed the current non-translated error message in the test
[16:19:50] <jepler> e.g., in a comment on the first line
[16:19:50] <cradek> on the other hand, the best test would see if it gets the expected error, not just any error
[16:20:08] <cradek> sure, that sounds fine
[16:34:40] <jepler> http://emergent.unpy.net/files/sandbox/test-bad-gcode-is-rejected-v3.mbox
[16:35:03] <jepler> (only change is in 4/4)
[16:40:56] <cradek> yes I like it!
[16:42:59] <jepler> micges: btw feel free to push that master-only interpreter change
[16:43:22] <jepler> anybody but me have an opinion about changing that message in v2.4_branch?
[16:44:02] <micges> jepler: ok
[16:45:50] <micges> jepler: in 2.4 there isn't translatable emcmot messages
[16:46:58] <jepler> micges: ah
[16:47:40] <jepler> hm, is it accurate to say "tripping probe" for G38.4?
[16:48:14] <micges> probably not
[16:48:44] <cradek> "Probe fail!"
[16:48:54] <cradek> I can't come up with the right words
[16:49:09] <jepler> I think it's probably affordable to have two distinct messages if we want it
[16:49:17] <cradek> there you go
[16:50:56] <jepler> not sure if I got the test right, but I'm thinking something like this:
http://emergent.unpy.net/files/sandbox/0001-motion-improve-G38.4-error-message.patch
[16:52:28] <micges> I like it
[16:52:44] <Jymmm> what does "without clearing probe" mean? like clear the probed values?
[16:53:10] <jepler> Jymmm: G38.2 probing starts off the material and ends when the probe touches the material (the probe is tripped)
[16:53:15] <cradek> Jymmm: it means the probe changes from touching something to not touching something
[16:53:26] <jepler> Jymmm: A G38.4 probe starts on the material and ends when the probe is no longer touching the material (the probe is cleared)
[16:53:37] <cradek> maybe "without probe clearing" is better
[16:53:57] <cradek> but I can't explain why I think that's clearer...
[16:54:14] <jepler> cradek: is "without probe tripping" clearer too?
[16:54:47] <cradek> "Probe is still touching something at the end of programmed move"
[16:54:55] <Jymmm> contact
[16:55:15] <jepler> "move finished without probe contact" and "move finished with probe still in contact"?
[16:55:16] <Jymmm> probe contact established, probe contact ___________
[16:56:06] <cradek> jepler: I like those
[16:56:13] <cradek> with your wording, you can put the gcode in there too
[16:56:25] <Jymmm> (I keep getting images of alien probes and "first contact" stuff LOL)
[16:56:26] <cradek> "G38.4 move finished with ..."
[16:57:14] <jepler> you mean change "probe move" -> "move"?
[16:57:21] <Jymmm> "move finished with probe maintaining contact"?
[16:58:07] <cradek> Jymmm: I like the form "... without [thing you wanted]" better
[16:58:37] <Jymmm> breaking contact, maintaining contact
[16:58:40] <jepler> except G38.4 isn't worded "without"
[16:58:47] <cradek> I'm so lost
[16:59:01] <jepler> I may have missed something too
[16:59:02] <jepler> right now I have
[16:59:08] <cradek> I miss lunch
[16:59:14] <jepler> reportError("G38.4 move finished with probe still in contact.");
[16:59:15] <jepler> reportError("G38.2 move finished without probe contact.");
[16:59:30] <jepler> do you have a 'without' wording for G38.4 that you like?
[16:59:57] <Jymmm> s/reportError("G38.4 move finished with probe still in contact.");/ reportError("G38.4 move finished without probe breaking contact.");/
[17:01:14] <Jymmm> breaking -or- making as fits the criteria
[17:01:40] <Jymmm> "losing contact"?
[17:02:11] <cradek> yes I think breaking or losing would be fine
[17:02:34] <cradek> wonder what the docs call the operation
[17:03:01] <jepler> > The move stops (within machine acceleration limits) when the programmed point is reached, or when the requested change in the probe input takes place.
[17:03:17] <jepler> there's a table with the heading "target state" and the values are "contact" and "no contact"
[17:03:42] <cradek> oh ok, that sounds very clear
[17:04:09] <jepler> yeah, but I can't write "without no contact" in the message :-/
[17:05:33] <jepler> bbl, lunchtime here
[17:06:33] <cradek> there's precedence for making/breaking being the things a switch does, and if you use those you can phrase them both "without [making/breaking] contact"
[17:06:56] <jepler> yeah, I think make/break is a good pair of words to use here
[17:07:23] <jepler> reportError("G38.4 move finished without breaking contact.");
[17:07:27] <jepler> reportError("G38.2 move finished without making contact.");
[17:07:29] <cradek> thanks Jymmm, that was a good idea
[17:07:48] <cradek> the symmetry is breathtakingly beautiful
[17:07:52] <cradek> :-)
[17:07:53] <jepler> now I've lost any form of the word "probe",t hough
[17:30:54] <alex_joni> http://dl.maximumpc.com/galleries/DreamMachine2010/mobo_full.jpg
[17:31:12] <alex_joni> no parport though
[17:32:45] <alex_joni> works with this:
http://www.newegg.com/Product/Product.aspx?Item=N82E16820231392
[17:34:56] <mozmck> alex_joni: can you buy me a few sets of those?
[17:58:53] <alex_joni> mozmck: I'll get the mobo's you get the memory sticks
[18:00:51] <moopy> what does this mean: ERRkineInverse(joints: -62.158975 -49.435607 11.435234 -67.403403 106.710052 -34.638991), (iterations=100)
[18:01:41] <jepler> moopy: just guessing from a glance at the source, but it seems to mean the inverse kinematics function didn't converge to a solution after 100 attempts
[18:02:31] <moopy> should i try increasing the number of iterations?
[18:03:40] <moopy> i get the feeling that the reason that axis and pyvcp positions do not follow the tooltip motion maybe because the realtime processe times out?
[18:04:04] <moopy> if i get a faster machine it may work?
[18:05:47] <moopy> anyone have any advice on hacking into genserkins?
[18:06:05] <jepler> I have never looked at that code before, I don't know much about it in detail
[18:07:00] <moopy> i have no idea how the kins hook into emc??
[18:09:00] <alex_joni> moopy: if you increse the iterations you will probably lock up RT
[18:09:25] <alex_joni> I doubt that the reason for axis and pyvcp positions is because of rt timeouts
[18:09:37] <cradek> well there's no such thing as a rt timeout
[18:09:55] <alex_joni> but if your kins don't converge, then surely the world position is busted, and you won't have proper axis and pyvcp positions
[18:09:55] <moopy> if i increase the servo_period and base_period it should be okay in simulation?
[18:10:03] <cradek> if your kins aren't converging, they're broken
[18:10:03] <jepler> Assuming that the algorithm of kinematicsInverse is good, it should almost always converge in a very small number of iterations (e.g., 2 or 3) and always converge within a modest number of iterations if it will ever converge
[18:10:06] <alex_joni> moopy: you won't accomplish anything
[18:10:21] <alex_joni> right, in any case less than 10 steps
[18:10:50] <jepler> it may be that your kinematics description is incorrect or inconsistent, or it just can't reach the location in question (e.g., the working volume is all within 100mm of the origin but you're asking to go to z200)
[18:11:56] <alex_joni> or you're in a singularity
[18:12:15] <alex_joni> where there are an infinity of solutions for kin_inverse
[18:14:13] <moopy> i notice in rtapi_app_main it looks like the dh params are read in using hal_pin_float_newf.. but the they seem to be over riden by some defines.. A(0) = DEFAULT_A1;
[18:15:07] <moopy> does that mean that the dh params for A,ALPHA,and D are not being used??
[18:15:38] <moopy> maybe the theta read from the joint is not scaled correctly?
[18:18:18] <cradek> yes units problems (deg vs rad, in vs mm) are all possible trouble - you should check everything carefully
[18:18:45] <moopy> i have managed to get the puma560 config to run without crashing by running in simulation --enable-simulator mode, but the arm seems limit and stop
[18:19:43] <moopy> am i right about the params being over written by the defaults??
[18:19:50] <alex_joni> no
[18:19:56] <jepler> the assignments are just setting initial values. Any values from 'setp' should take precedence.
[18:19:59] <jepler> A(0) = DEFAULT_A1;
[18:20:02] <alex_joni> the parameters are set to default values
[18:20:08] <alex_joni> like jepler said
[18:20:19] <alex_joni> but later on they are replaced with the setp hal values
[18:21:39] <moopy> where in the code are the values changed with setp?
[18:21:58] <moopy> i cannot see anything in genserkins.c?
[18:22:08] <jepler> hm, I notice that genser_kin_init doesn't happen until inside genser_kin_fwd, but before that there's a call to compute_jfwd
[18:22:15] <jepler> moopy: assignments to the parameters happen by magic
[18:22:45] <jepler> moopy: halcmd 'setp' has access to the memory where a[], alpha[] and d[] are stored -- so it updates the value simply by writing a new value there
[18:23:09] <moopy> oops, i think i see, hal_pin_float_newf passes a pointer to the location
[18:24:00] <moopy> so emc handles it behind the scenes
[18:26:10] <moopy> okay i will have to look a little deeper at the code
[19:39:20] <CIA-5> EMC: 03jepler 07v2.4_branch * r19b60670ee48 10/scripts/runtests: testsuite: fix checking exit values
[19:39:21] <CIA-5> EMC: 03jepler 07v2.4_branch * r3f116eab7600 10/src/emc/motion/control.c: motion: improve G38.4 error message
[19:39:23] <CIA-5> EMC: 03jepler 07v2.4_branch * rdeb305e11e15 10/ (scripts/runtests tests/README): testsuite: allow tests written in scripting langs
[19:39:24] <CIA-5> EMC: 03jepler 07v2.4_branch * rd7ee56fb9e32 10/tests/interp/bad/ (9 files): testsuite: check that invalid gcodes are rejected
[19:39:32] <CIA-5> EMC: 03jepler 07v2.4_branch * r5aa42c9a61e8 10/tests/overrun/test.sh: testsuite: fix overrun test
[19:41:07] <micges> cool
[19:46:49] <jepler> feel free to add more invalid gcode checks
[20:01:56] <Al_Smt> I a'm wondering if this would be a better way to access these arrays in tkemc
http://pastebin.ca/1935265
[20:02:45] <Al_Smt> and add a little padding to the offset widget
[20:29:13] <moopy> i have (i think) just worked out what is going wrong with my configuration!!
[20:30:56] <moopy> It seems if all the joints are homed at 0 the joints do not follow axis, but if i home them, then increment all joints so they are not zero, then all joints and dials follow the axis gcode motions
[20:31:15] <moopy> is there a possible divide by zero error????
[20:32:01] <moopy> of course i have made a few changes to the config, but i dont think it was the config at all
[21:14:15] <alex_joni> moopy: I mentioned 'singularity' earlier
[21:14:31] <alex_joni> that happens when you have more than one solution to the kins
[21:14:40] <alex_joni> quite usually around joints 0 locations
[21:15:16] <alex_joni> check the puma560 config, you'll see the home for joint4 (if joint0 is the first one) is not in 0
[21:15:33] <alex_joni> joint4 = 0 is a singularity for that kind of configuration
[21:15:53] <alex_joni> because joint3 and joint5 are perfectly parallel when joint4 is at 0
[21:16:05] <alex_joni> so there are an infinity of solutions for the same tool position
[21:16:39] <alex_joni> (imagine j3=0, j5=0; j3=1, j5=-1; j3=2, j5=-2; ...)
[21:18:01] <moopy> aaaah i am almost understanding now
[21:18:48] <moopy> thanks for humoring my lack of knowledge alex
[21:20:26] <moopy> I have at least maybe done something of use tonight, as I think I have implemented a loadtime setting for the number of joints in genserkins
[21:21:10] <moopy> if you are interested I can pastebin my hack to you code alex
[21:21:45] <alex_joni> sure, can't hurt
[21:23:39] <alex_joni> moopy: hopefully more than 6, not less
[21:24:25] <moopy> http://pastebin.ca/1935311
[21:24:42] <moopy> please be aware my code is normally pretty shit
[21:25:24] <moopy> and also i have changed the driver name to dhkins so i dont lose the working version of genserkins
[21:25:55] <moopy> just do a find/replace of dhkins to genserkins
[21:26:57] <moopy> oooh and you will need to change the GENSER_MAX_JOINTS define to infinity in genserkins.h
[21:27:55] <moopy> and when you loadrt genserkins add cfg='l,l,l,l,l,l,l.....' to define the number of joints and their joint type
[21:28:25] <moopy> l=linear r=revolute
[21:29:12] <moopy> the joint type is not actually of any use at present so any number of commas will be enough
[21:29:41] <alex_joni> I've been meaning to add this to genserkins, but things came up :)
[21:30:06] <alex_joni> moopy: the code needs some massaging ;) but it's on the right track
[21:31:01] <moopy> most of it looks like good work to me, but i really dont know enough about kinematics or robotics to say, im just learning at the moment
[21:31:33] <alex_joni> http://failblog.files.wordpress.com/2010/09/829cffdc-4c3d-4b70-ba03-2126911ffa18.jpg
[21:32:25] <moopy> hehehehehe
[21:32:51] <moopy> is that park run by the catholic church?
[21:38:45] <moopy> well i think I must be off, if i get some more time i may try adding linear joints to genserkins, though i will get back to my python genserkins configurator first now i have worked out why it was not working.
[23:23:12] <KimK> cradek: OK, I may have found a minor disagreement that needs fixing for me to practice on. I noticed that the lathe-sim tbl says ...I, J, Q. Whereas the User Manual lathe-specifics says ...Q, I, J. Since you're a lathe user, any comments or advice?
[23:32:39] <KimK> cradek: No, nevermind, my mistake. No disagreement, I was looking at the 2.4.3 manual, it's already fixed in docs.
[23:33:19] <KimK> So ...I, J, Q is correct.
