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