very big radius arc
And cutting pretty fast, too!
skunkworks: heekscnc output that wasn't quite right
wonder if jt's mill is at ground level yet
did you find time to do your programing?
customer said - cool, I tried it, it's great, now I want it to do something else too
depending on how you look at it, I guess...
money is good.. ;)
even if it is the root of all evil ;)
No, there's nothing wrong with money. It's the *love* of money that
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
(Sorry for the misfire, lol)
How's everybody this evening?
Hi cradek, sorry nothing to patch yet, but I'll try to find something in the next day or two, just as a test.
Yeah, congrats to JT on his new machine, I saw some (maybe not all) of the pictures.
patch for review for master: removing redundant checks from convert_probe() http://pastebin.com/yBpFCctp
huh, line 19 and 22 are really twice?
proposed patch for 2.4: fixing probe error message when using g38.2 or g38.4: http://pastebin.com/iM9ZyUxH
micges_work: I can't get git to apply those patches
error: patch failed: src/emc/rs274ngc/interp_convert.cc:3062
error: src/emc/rs274ngc/interp_convert.cc: patch does not apply
alex_joni: yes, but obviously with different filenames
$ wget -O- -o/dev/null 'http://pastebin.com/download.php?i=yBpFCctp'
| git apply
fatal: corrupt patch at line 37
first problem: no trailing newline
$ (wget -O- -o/dev/null 'http://pastebin.com/download.php?i=yBpFCctp';
echo) | git apply
error: patch failed: src/emc/rs274ngc/interp_convert.cc:3062
error: src/emc/rs274ngc/interp_convert.cc: patch does not apply
second problem: patch is broken anyway
error: patch failed: src/emc/rs274ngc/rs274ngc_return.hh:187
error: src/emc/rs274ngc/rs274ngc_return.hh: patch does not apply
one's for master, one for 2.4..
but anyways, micges_work should probably know :D
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
in this case it looks like there's only one translation of the message (pt_BR), which surprises me
alex_joni: I tried in a 2.4_branch and master both
yeah, thought you might have
it might still be something pastebin is doing to the patch; I don't really trust them for patches
bbl, time to go to the office
why using pastebin instead of codepad.org
jepler: will fix patches later
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
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
jepler: can it test a multiline program, or just individual lines?
g41 / ... / g40 / g2 ... should be rejected
cradek: yes, it can (just embed \ns in the test)
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
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.
ries_ is now known as ries
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
cradek: good idea
and you could call them no-feed-rate.ngc, no-axis-letters.ngc
should I add 'm2' to them, like I do in the current version?
no, I think the programs should be complete (the .ngc file should contain the m2)
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
I guess we can watch for that
or you could have to embed the current non-translated error message in the test
e.g., in a comment on the first line
on the other hand, the best test would see if it gets the expected error, not just any error
sure, that sounds fine
[16:34:40] <jepler> http://emergent.unpy.net/files/sandbox/test-bad-gcode-is-rejected-v3.mbox
(only change is in 4/4)
yes I like it!
micges: btw feel free to push that master-only interpreter change
anybody but me have an opinion about changing that message in v2.4_branch?
jepler: in 2.4 there isn't translatable emcmot messages
hm, is it accurate to say "tripping probe" for G38.4?
I can't come up with the right words
I think it's probably affordable to have two distinct messages if we want it
there you go
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
I like it
what does "without clearing probe" mean? like clear the probed values?
Jymmm: G38.2 probing starts off the material and ends when the probe touches the material (the probe is tripped)
Jymmm: it means the probe changes from touching something to not touching something
Jymmm: A G38.4 probe starts on the material and ends when the probe is no longer touching the material (the probe is cleared)
maybe "without probe clearing" is better
but I can't explain why I think that's clearer...
cradek: is "without probe tripping" clearer too?
"Probe is still touching something at the end of programmed move"
"move finished without probe contact" and "move finished with probe still in contact"?
probe contact established, probe contact ___________
jepler: I like those
with your wording, you can put the gcode in there too
(I keep getting images of alien probes and "first contact" stuff LOL)
"G38.4 move finished with ..."
you mean change "probe move" -> "move"?
"move finished with probe maintaining contact"?
Jymmm: I like the form "... without [thing you wanted]" better
breaking contact, maintaining contact
except G38.4 isn't worded "without"
I'm so lost
I may have missed something too
right now I have
I miss lunch
reportError("G38.4 move finished with probe still in contact.");
reportError("G38.2 move finished without probe contact.");
do you have a 'without' wording for G38.4 that you like?
s/reportError("G38.4 move finished with probe still in contact.");/ reportError("G38.4 move finished without probe breaking contact.");/
breaking -or- making as fits the criteria
yes I think breaking or losing would be fine
wonder what the docs call the operation
> The move stops (within machine acceleration limits) when the programmed point is reached, or when the requested change in the probe input takes place.
there's a table with the heading "target state" and the values are "contact" and "no contact"
oh ok, that sounds very clear
yeah, but I can't write "without no contact" in the message :-/
bbl, lunchtime here
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"
yeah, I think make/break is a good pair of words to use here
reportError("G38.4 move finished without breaking contact.");
reportError("G38.2 move finished without making contact.");
thanks Jymmm, that was a good idea
the symmetry is breathtakingly beautiful
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
no parport though
works with this: http://www.newegg.com/Product/Product.aspx?Item=N82E16820231392
alex_joni: can you buy me a few sets of those?
mozmck: I'll get the mobo's you get the memory sticks
what does this mean: ERRkineInverse(joints: -62.158975 -49.435607 11.435234 -67.403403 106.710052 -34.638991), (iterations=100)
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
should i try increasing the number of iterations?
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?
if i get a faster machine it may work?
anyone have any advice on hacking into genserkins?
I have never looked at that code before, I don't know much about it in detail
i have no idea how the kins hook into emc??
moopy: if you increse the iterations you will probably lock up RT
I doubt that the reason for axis and pyvcp positions is because of rt timeouts
well there's no such thing as a rt timeout
but if your kins don't converge, then surely the world position is busted, and you won't have proper axis and pyvcp positions
if i increase the servo_period and base_period it should be okay in simulation?
if your kins aren't converging, they're broken
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
moopy: you won't accomplish anything
right, in any case less than 10 steps
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)
or you're in a singularity
where there are an infinity of solutions for kin_inverse
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;
does that mean that the dh params for A,ALPHA,and D are not being used??
maybe the theta read from the joint is not scaled correctly?
yes units problems (deg vs rad, in vs mm) are all possible trouble - you should check everything carefully
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
am i right about the params being over written by the defaults??
the assignments are just setting initial values. Any values from 'setp' should take precedence.
A(0) = DEFAULT_A1;
the parameters are set to default values
like jepler said
but later on they are replaced with the setp hal values
where in the code are the values changed with setp?
i cannot see anything in genserkins.c?
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
moopy: assignments to the parameters happen by magic
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
oops, i think i see, hal_pin_float_newf passes a pointer to the location
so emc handles it behind the scenes
okay i will have to look a little deeper at the code
EMC: 03jepler 07v2.4_branch * r19b60670ee48 10/scripts/runtests: testsuite: fix checking exit values
EMC: 03jepler 07v2.4_branch * r3f116eab7600 10/src/emc/motion/control.c: motion: improve G38.4 error message
EMC: 03jepler 07v2.4_branch * rdeb305e11e15 10/ (scripts/runtests tests/README): testsuite: allow tests written in scripting langs
EMC: 03jepler 07v2.4_branch * rd7ee56fb9e32 10/tests/interp/bad/ (9 files): testsuite: check that invalid gcodes are rejected
EMC: 03jepler 07v2.4_branch * r5aa42c9a61e8 10/tests/overrun/test.sh: testsuite: fix overrun test
feel free to add more invalid gcode checks
I a'm wondering if this would be a better way to access these arrays in tkemc http://pastebin.ca/1935265
and add a little padding to the offset widget
i have (i think) just worked out what is going wrong with my configuration!!
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
is there a possible divide by zero error????
of course i have made a few changes to the config, but i dont think it was the config at all
moopy: I mentioned 'singularity' earlier
that happens when you have more than one solution to the kins
quite usually around joints 0 locations
check the puma560 config, you'll see the home for joint4 (if joint0 is the first one) is not in 0
joint4 = 0 is a singularity for that kind of configuration
because joint3 and joint5 are perfectly parallel when joint4 is at 0
so there are an infinity of solutions for the same tool position
(imagine j3=0, j5=0; j3=1, j5=-1; j3=2, j5=-2; ...)
aaaah i am almost understanding now
thanks for humoring my lack of knowledge alex
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
if you are interested I can pastebin my hack to you code alex
sure, can't hurt
moopy: hopefully more than 6, not less
[21:24:25] <moopy> http://pastebin.ca/1935311
please be aware my code is normally pretty shit
and also i have changed the driver name to dhkins so i dont lose the working version of genserkins
just do a find/replace of dhkins to genserkins
oooh and you will need to change the GENSER_MAX_JOINTS define to infinity in genserkins.h
and when you loadrt genserkins add cfg='l,l,l,l,l,l,l.....' to define the number of joints and their joint type
the joint type is not actually of any use at present so any number of commas will be enough
I've been meaning to add this to genserkins, but things came up :)
moopy: the code needs some massaging ;) but it's on the right track
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
is that park run by the catholic church?
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.
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?
cradek: No, nevermind, my mistake. No disagreement, I was looking at the 2.4.3 manual, it's already fixed in docs.
So ...I, J, Q is correct.