so what happens is the move ends up going the wrong way once the endpoint is offset, which is the error case that gives this message normally
but if you go a little farther along the line (k2=0.1 instead of k2=0) it doesn't gouge
right, you can see in my picture just how far you need to go to make a corner where compensation can fit the tool
I think you'll find that it's when you get up tangent to the tool where I've placed it in my picture
i'm not really able to follow what you're saying
sorry, maybe I'm rambling
this is what i don't get: if you go a little farther along the line (k2=0.1 instead of k2=0) it doesn't gouge
the summary is your program gives an impossible case for compensation in this corner, and it's an undetected error
I understand (but I haven't managed to set k2 yet and have it take effect - how do I do that?
oh on line 21?
yes, got it
[00:05:10] <cradek> http://timeguy.com/cradek-files/emc/exit.png
[00:05:14] <cradek> http://timeguy.com/cradek-files/emc/exit-ok.png
ok these are the two cases
in the second one, see how the tool fits in the corner made by the bottom line and the short one going up
the tool fits in the corner with both lines touching it
now go back to the first picture, and see how the tool can't fit in there because the top line is too short
it's an error case, but because it's the last corner made before g40, it goes undetected
subroutines only know about #1,#2 etc as calling parameters, but I equate them to named parameters to make the body easier to read
ok, I figured out how to change it
(did you see what I said above - last 10 or so lines?)
there was some kind of interruption here so i'm not sure; myconnectivity is poor today
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-10-24.txt
jepler and I tried to get probing to work, but we haven't figured it out yet
it sort of latches randomly
Just wanted to say that I got the hardware tested, works for me (naturally)
aha, that's good to know
5i20 with the same 8_3P firmware you sent me?
we'll keep working at it.
is it right that you set the latch-enable bit when you want a latch, and it clears when the latch triggers?
Just poking at registers, I was too dim to use an output bit to check the polarity so i just shorted the input pullup with a wire
Olly clears if JustOnce is set, but you want latch on probe (bit 13)
yes, we set JustOnce, just like for index
(and latch on index must be clear)
wish jepler was here - I don't have the code
right, we had that
dgarr: ^ simple test case that shows the problem
dgarr: I'm trying to figure out how I can detect it and error
read back -- now i get it -- sorry to be so dense
nah, it's baffling - I only see it because I know the algorithm
I just connected an encoder and poked at registers:
it's just an error - can't get in the corner - it's undetected
write CCR with 0x2040 = JustOnce | LatchOnProbe
read encoder count, say 0xTTTT1234
read CCR/LATCH = 0x0000204x
ground probe input
read CCR/LATCH = 1234004x
ok so it cleared 0x2000
pretty sure that's what we were doing and expecting - we must just have something wrong
Yep cleared LatchOnProbe as it should
also tried with JustOnce clear so it latches every probe edge
that seemed ok also
Its pretty simple, the probe stuff is just copy-pasted from the index logic
heh, and we did the same in the driver
hm, one thing unusual is I have two 5i20 and we were on the second one
loaded 8_3P firmware on both
I can do a loopback test Monday, but I think the firmware is OK (famous last words)
Maybe a glitch catcher on GPIO would help
I know I don't have noise that is triggering it - one wrongness we saw was that it would capture randomly but only after we touched the probe
let us work on it some more - I didn't mean to drag you into it yet - but it's good to know that you have tried it on hardware.
Is your quad counter filter on? (15 counts vs 3)
probe uses the same as the counter
how would I see that? I'm pretty sure I did not change the default
Its a HAL parameter
digging in the manpage...
no, it is not changed in my file, so it is on (15)
OK that good (anything shorter than .5 usec ignored)
Anyway I guess more data is needed
time to go home and bring in the lawnmower sheep
cradek: i can calculate it i guess: if the acute angle is phi, the distance you have to go up the second leg is rtool /tan(phi/2) i think
[00:45:29] <dgarr> http://www.deweygarrett.com/stuff/goodexit.ngc
cradek: thans for your help
short of calculating it, the only safe move is the entire move, because it passed the test earlier
I am working on how to detect this problem case
it really bugs me if there's an undetected error - I thought this was perfect
EMC: 03cradek 07random_toolchange * rb9080e3db4a0 10/ (20 files in 9 dirs): Merge branch 'master' into random_toolchange
hm, that is not what I meant to do
EMC: 03cradek 07master * rc63a4c862f50 10/src/emc/rs274ngc/ (interp_convert.cc interp_queue.cc): fix undetected gcode error when using cutter comp
that is what I meant to do
dgarr: fixed, thank you for finding it
sure is one way to do it..
[01:20:27] <skunkworks> http://www.youtube.com/watch?v=l0x4djsI4Ps&feature=channel
people and their stepper fetish - I just don't know.
people and their stepper fetish - I just don't know.
still only 10-15 seconds to traverse the table... not too bad.
880 full steps per inch
cradek: git pulled, tested -- amazed as usual at your speed -- thanks
will the change allowing partport_pc to be used with the rtai kernel make it in the next release?
mozmck: no, it will not be a part of 2.3.4.
ok, just wondering
dgarr: thanks for testing it
[18:13:08] <alex_joni> http://www.cncecke.de/forum/attachment.php?attachmentid=11662&d=1256403198
You have to be logged in to see what-ever you are trying to show
[18:16:14] <alex_joni> http://imagebin.org/69006
* skunkworks wonders why he hyphenated whatever..
neat - have you showed them chris's gui?
got a screenshot?
Here is a halscope screenshot of an interesting problem I am now experiencing: http://www.mattshaver.com/problem/Screenshot-2.png
This occurs during one of the thread cutting passes of a G76 cycle on a lathe.
As the scope display shows, the spindle speed is relatively constant, and the spindle position changes in a linear fashion, yet there is a pause in the Z axis motion which I can't explain.
Changing the spindle speed interactively sometimes results in more than one pause during the coordinated move.
encoder.00 is the spindle?
I'm having trouble understanding the plots (doesn't help that they are messed up from being screengrabbed while they were moving)
why does encoder.00 reset while axis.2 is moving? I don't think that's ever how it's supposed to work
can you give me more context or make a screenshot that shows more context?
cradek: it's not a reset -- it's on "roll", and that's where the data cuts off
I now know what's wrong.
In a G76 block, if L1 or L3 is programmed, the motion is "choppy". L0 and L2 are OK.
The test program is basically examples/G76.ngc. Change L2 to L3 or L1.
It's line #102.
Sorry, yes. encoder.00 is the spindle, axis2 is Z.
so - whenever there is a enter taper?
heh - yes captain obvious
argh, I just noticed a problem with 2.3.4
too bad I just updated the repository
it's not serious: it just wants to install extra unneeded python packages
probably because of 3e7c5ea75690e46b4ebc9882084b3e83290fd1e4
and I have to walk out the door very shortly
OK, I took back the 2.3.4 packages and will build and upload 2.3.4-1 packages tomorrow