Back
[12:49:33] <rayh> Hi guys.
[12:49:57] <rayh> It's beautiful in the north woods today.
[12:50:07] <BigJohnT> hi Ray
[12:53:01] <rayh> How you doing today.
[12:53:47] <BigJohnT> good, I'm cooking some crawfish this afternoon
[12:54:42] <BigJohnT> I noticed while running my plasma cutter that EMC almost stops between a line and an arc at speeds above 25IPM
[12:54:58] <BigJohnT> and the faster you go the more pronounced it is
[12:55:50] <BigJohnT> when it is all lines it is smooth as silk as high as 400IPM (as far as I tested)
[12:57:25] <BigJohnT> would anything help reduce the slow down between an arc and a line?
[12:57:44] <BigJohnT> like more memory or faster processor
[13:03:27] <rayh> I doubt it. What proc are you using know?
[13:03:34] <rayh> now
[13:04:10] <BigJohnT> I don't know off the top of my head but it's about a p4 1000 or something like that
[13:04:17] <BigJohnT> its out in the shop
[13:04:31] <rayh> Okay.
[13:04:58] <rayh> You can get an easy answer from a terminal. "cat /proc/cpuinfo"
[13:05:49] <rayh> I saw some of the discussion about this yesterday and don't have a good answer.
[13:06:24] <rayh> I'd think though that a 1g proc should have enough throughput to handle the stream of canonical commands.
[13:06:56] <BigJohnT> it is smooth as silk up to 25 IPM after that it starts to jitter
[13:07:32] <rayh> That seems odd.
[13:07:50] <BigJohnT> cat/proc/cpuinfo didn't work on this termial it said no such file or directory
[13:08:16] <rayh> put a space between cat and /
[13:08:42] <BigJohnT> you can see the speed in Axis start to bounce up and down
[13:08:45] <BigJohnT> the space did it
[13:08:53] <rayh> Good.
[13:09:17] <rayh> I love Linux.
[13:09:17] <BigJohnT> I'll go out to the shop and see what it is
[13:09:24] <rayh> k
[13:15:53] <BigJohnT> well it is a Pentium 4 2.4GHz
[13:16:08] <BigJohnT> faster than I thought
[13:17:07] <rayh> Okay.
[13:17:20] <rayh> That should not be the problem.
[13:17:42] <BigJohnT> circles are smooth as silk up to 400 IPM as well
[13:17:57] <rayh> Okay.
[13:18:12] <rayh> So it is an accel/decel issue.
[13:18:21] <BigJohnT> also when I did the ellipse with about 450 lines it was smooth to
[13:18:25] <rayh> Refresh me on the drives you use.
[13:18:33] <BigJohnT> gecko 203v
[13:18:52] <rayh> Okay
[13:19:05] <rayh> What value for accel?
[13:19:10] <BigJohnT> I changed the acceleration in my ini from real low to real high with not much change
[13:19:26] <BigJohnT> 200 is what I normally have
[13:19:37] <rayh> * rayh throws out that idea.
[13:19:55] <BigJohnT> I went as high as 400 to test
[13:20:10] <rayh> Wow more than a G.
[13:20:24] <rayh> How heavy is that head?
[13:20:43] <BigJohnT> about 20 pounds
[13:21:36] <rayh> let me read for a minute
[13:21:41] <BigJohnT> it seems to me that EMC throws a pause in between the line and the arc move
[13:21:45] <BigJohnT> ok
[13:23:05] <rayh> G64P0.010 didn't make any difference?
[13:23:35] <BigJohnT> no, I was told by cradek (I think) that it only works on lines
[13:23:47] <BigJohnT> I did a G64P1 to test
[13:24:00] <rayh> Okay.
[13:24:09] <BigJohnT> with all lines a G64P0.001 did fine
[13:24:54] <rayh> When cradek was working up the interpreter we did a lot of testing. This combination may have gotten past us.
[13:25:46] <rayh> Did you try the four arc approximation of an ellipse?
[13:26:00] <BigJohnT> no
[13:26:21] <rayh> I used eight when I programmed the elliptical beam splitter.
[13:26:39] <BigJohnT> it was not just the ellipse but the letters I cut out too
[13:26:49] <rayh> Oh.
[13:27:22] <rayh> Do you see any difference between going from arc to line and line to arc?
[13:27:33] <BigJohnT> I didn't test that
[13:27:57] <BigJohnT> but I will after breakfast
[13:28:01] <rayh> How about sending me some samples that show what you are seeing.
[13:28:12] <BigJohnT> of the g code?
[13:28:14] <rayh> or pastbin em
[13:28:17] <rayh> yes
[13:28:23] <BigJohnT> brb
[13:28:59] <BigJohnT> I just happen to have the two examples on a floppy
[13:29:18] <rayh> sneakernet!
[13:30:20] <BigJohnT> http://pastebin.ca/1027924
[13:32:04] <BigJohnT> http://pastebin.ca/1027925
[13:32:38] <BigJohnT> don't know why pastebin threw in a blank line between each line....
[13:34:15] <rayh> I see that. Don't think it will make a difference.
[13:34:26] <cradek> the arcs are .001-.002" long. it has to nearly stop to be sure to hit them. if you just remove the arc lines it will work much better and make no difference.
[13:34:32] <rayh> How did you generate this program?
[13:34:40] <BigJohnT> sheet cam
[13:35:18] <BigJohnT> even on the letters that have longer arcs I can see the pause between arc and line
[13:35:19] <cradek> it is not a problem blending line-arc or arc-line, it's a problem with blending very short moves (and this is worked around for lines but not arcs)
[13:36:03] <cradek> which paste is that?
[13:36:16] <BigJohnT> brb
[13:37:47] <cradek> can you tell sheetcam a tolerance so it doesn't output so many tiny moves? some of these are way under .001 long which seems silly
[13:38:20] <rayh> I took the first one.
[13:38:21] <BigJohnT> I thought it was set for 0.005
[13:38:57] <cradek> in the second paste I'm looking at line 136-138, it is .0006
[13:39:24] <rayh> Could this be caused by sheet cams eol?
[13:39:50] <cradek> for all lines that's ok, emc can handle it (it ignores the useless moves) but with arcs this bites you
[13:40:10] <cradek> what is eol?
[13:40:30] <BigJohnT> end of line?
[13:40:35] <cradek> 120-122 is also .0006
[13:40:47] <cradek> maybe your setting is .0005 not .005
[13:41:24] <cradek> no, blank lines don't hurt anything
[13:42:02] <BigJohnT> my circle recognition limit is 0.1"
[13:42:51] <BigJohnT> in my post the minArcSize is set at 0.5
[13:43:05] <BigJohnT> I wonder if it is in mm
[13:43:14] <cradek> but in the first paste the arcs are under .001 long. look at line 24-26
[13:44:34] <cradek> these short moves are what is hurting you, if you can get the cam to not generate them, it would be good. otherwise, use all lines and G64P and emc will combine the unnecessary moves for you
[13:44:59] <BigJohnT> ok
[13:46:04] <BigJohnT> breakfast calls
[13:46:22] <cradek> me too
[13:46:36] <rayh> How big is your table, BigJohnT?
[13:47:49] <cradek> rayh: I think
http://www.youtube.com/watch?v=KvhvQu5Xxtk is BigJohnT's machine
[13:48:53] <cradek> can't tell for sure but it looks maybe a yard wide
[13:49:27] <rayh> Okay. I built a bigjohn-stepper.ini
[13:49:45] <rayh> I do see a lot of the jerking
[13:50:37] <cradek> yes I don't doubt it, looking at the gcode. I hope he can try the things I suggested.
[13:51:04] <rayh> You were suggesting changes to sheet cam's output?
[13:51:37] <rayh> I should try to reproduce with Synergy.
[13:51:41] <cradek> yes. he has to get rid of the tiny moves somehow. if he uses lines only, G64P can do this for him. otherwise, he needs to change the output.
[13:52:49] <rayh> Could we remodel the traj or interp to handle this sort of case.
[13:53:06] <cradek> sure, it would be ideal if we could make G64P handle arcs too. but that is harder than the line case of course.
[13:53:51] <rayh> I understand the "load" carried with my question.
[13:54:52] <cradek> it's hard to gracefully handle arbitrarily bad cam output. but we did g64p because one very common form of cad output is a zillion tiny tiny G1 moves
[13:55:01] <cradek> that case is handled pretty well
[13:55:32] <cradek> but BigJohnT's case where there are reasonable lines with tiny tiny arcs sprinkled between each of them, is one we haven't worked around yet
[13:56:27] <cradek> it looks like if he just deletes the G2 and G3 lines from that file, it will run fine with G64P. (assuming all the arcs are tiny tiny, I can't tell)
[14:00:27] <cradek> cool, my high speed spindle is on the way.
[14:00:46] <cradek> a guy sells them on ebay, but I think he doesn't build them until he has a buyer
[14:00:55] <rayh> Seems like the curve fitting in sheet cam needs a bit of work
[14:01:17] <rayh> What sort of thing is it?
[14:01:38] <rayh> Oh. I got the box of boards from mesa for the raffle.
[14:02:17] <BigJohnT> ok I'm back
[14:02:18] <cradek> oh? I didn't know we had a mesa raffle. I might buy a ticket then.
[14:02:34] <rayh> 9 boards including several I want.
[14:02:48] <cradek> usually the raffle has stuff I don't care much about (like windows software)
[14:02:48] <BigJohnT> rayh: the table is 38 x 50 but I can use a 4x8 sheet
[14:03:13] <rayh> Okay. I made my test 100x100
[14:03:57] <BigJohnT> so is what I am seeing a result of the shear number of moves at that speed where as the one with lines is reduced in the actual amout of moves?
[14:04:13] <cradek> no!
[14:04:18] <rayh> gotta reboot to run synergy. been playing with fluxbox and blackbox on a new 8.04 install
[14:04:23] <cradek> the problem is the SHORT moves
[14:04:31] <cradek> I keep saying this
[14:05:08] <BigJohnT> ok, I was just trying to understand better
[14:05:23] <cradek> emc knows how to throw out useless short moves (the ones that don't affect the path within the G64P tolerance) but it does not know how to throw out unnecessary arcs
[14:05:59] <BigJohnT> ok, that makes sense
[14:06:16] <cradek> so your two solutions are: get sheetcam to use your tolerance and not put out short moves, or use all G1 so emc knows how to discard the unnecessary ones
[14:06:56] <BigJohnT> I just changed the post on sheetcam to see what the result is
[14:07:12] <cradek> if you tell sheetcam tolerance .005 but it generates moves .0006 long, it's not working right
[14:07:46] <cradek> did you change it to use all G1?
[14:07:59] <BigJohnT> that was a mastercam output
[14:08:11] <cradek> oh
[14:08:23] <BigJohnT> I just changed minArcSize to 1 and got all G1 moves
[14:09:00] <cradek> I don't have any of these products, so it's tough for me to guess how to get them to generate gcode that emc will like
[14:09:15] <cradek> maybe I should be thankful I don't have them :-)
[14:09:21] <BigJohnT> lol
[14:09:59] <BigJohnT> I created a post for it that EMC likes but this must be a mm value
[14:10:17] <cradek> ahhh .005mm could explain it
[14:10:27] <BigJohnT> I think Les (the developer) has some issues with mm/inch
[14:10:40] <cradek> don't we all
[14:11:11] <BigJohnT> that's why I keep working on an EMC CAM package...
[14:11:13] <cradek> I jump when the MPG readout on my car shows 25.4 because for so long I'd see those in EMC when there was a units bug
[14:11:37] <BigJohnT> or 0.03937
[14:11:40] <cradek> fortunately the EMC units bugs are all fixed now :-)
[14:11:44] <cradek> yep that's the other one
[14:11:52] <cradek> but fortunately I get better mileage than that
[14:12:43] <BigJohnT> I get 15-16 mpg in my truck
[14:12:57] <BigJohnT> gotta finish that electric motorcycle
[14:13:19] <cradek> that's good for a truck, but trucks are very bad for everyday driving
[14:13:56] <BigJohnT> yea, I gotta do something soon for driving back and forth to my machineshop
[14:13:56] <cradek> I bought a new motorcycle helmet this weekend. everyone was talking about gas mileage at the bike shop.
[14:14:12] <BigJohnT> what are motorcycles getting now
[14:14:14] <cradek> they must love it when the gas prices peak while the weather is perfect
[14:14:30] <cradek> because all these fool kids will buy bikes, forgetting that they're in nebraska :-)
[14:14:58] <cradek> mine only gets about 35-40, it is huge. you can probably get 75-100 on a little scooter
[14:14:58] <BigJohnT> I use to ride one when I lived in Alaska year round
[14:15:08] <cradek> my bike is not much better than my car
[14:15:14] <BigJohnT> but I was young and dumb
[14:15:30] <cradek> yeah I used to ride mine whenever there wasn't snow. I'm older/smarter now.
[14:16:07] <BigJohnT> I screwed sheet metal screws from the inside of the tires to ride on the snow and ice
[14:16:35] <cradek> wow, I've never been that "young and dumb"
[14:16:47] <cradek> sounds fun though :-)
[14:17:01] <BigJohnT> hey, I was 15 and had a honda 50 supersport
[14:17:30] <CIA-32> EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/drivers/hal_evoreg.c: this driver uses floating point math - label it accordingly
[14:17:42] <BigJohnT> well, the wife just announced that the construction crew (me) needs to get to work on the deck
[14:17:46] <rayh> I commuted year round in oregon on a honda 350 -- used up four rain suits.
[14:18:12] <rayh> Have a good day. I'll see if I can get synergy to spit out an ellipse.
[14:18:17] <BigJohnT> the good old days
[14:18:20] <BigJohnT> ok cool
[14:21:43] <CIA-32> EMC: 03jmkasunich 07v2_2_branch * 10emc2/src/hal/drivers/hal_evoreg.c: backport from trunk - driver uses floating point
[14:48:06] <SWPadnos> so, that guy who was having stepconf problems is now threading, but with some other problems:
http://pastebin.ca/1027962
[14:48:40] <SWPadnos> I suggested that he try threading passes at high and low speeds, to see if the "hunting" problem happens all the time
[14:49:32] <rayh> hunting, it isn't season yet! Fishing yes, hunting no.
[14:49:57] <SWPadnos> maybe it is where he lives, it's a Denford lathe ;)
[14:56:00] <CIA-32> EMC: 03swpadnos 07v2_2_branch * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: Backport fixes for lathe setups using counter mode for spindle feedback
[15:19:20] <jmkasunich> he doesn't actually describe the problem (or was that in an earlier message?)
[15:19:53] <SWPadnos> he couldn't thread at all before
[15:20:06] <SWPadnos> we got that fixed with some corrections to stepconf's setup in custom.hal
[15:20:19] <SWPadnos> (and I fixed stepconf so the rpoblem won't show up later)
[15:20:26] <jmkasunich> saw that
[15:20:32] <SWPadnos> but apparently the XZ motors "hunt" for the right speed
[15:20:56] <SWPadnos> I asked him to clarify what he means, and maybe post to the emc-users list rather than CCED
[15:21:23] <SWPadnos> he's got a 48-slot wheel on the spindle, so he's only getting position updates half the time (at 600 RPM)
[15:22:20] <jmkasunich> oh
[15:22:44] <SWPadnos> I don't know what kind of speeds he wants, but he used the g76.ngc sample to test
[15:22:45] <jmkasunich> so EMC is issuing position commands that say "stay where you are", "no, move", "no, stay", etc
[15:23:27] <SWPadnos> I think that could be it
[15:23:43] <SWPadnos> but then again, it would be doing that 500 times a second
[15:23:45] <jmkasunich> although that would be happening at 500Hz or so
[15:23:47] <jmkasunich> ;-)
[15:24:45] <jmkasunich> they way he said "i've still got the 'hunting for the exact speed' problem" makes it sound like a problem that he has previously described in more detail
[15:25:06] <SWPadnos> one sec - lemme look
[15:32:30] <SWPadnos> oh - here are the pastebins of his config (same as yesterday):
http://pastebin.ca/1027234 http://pastebin.ca/1027235 http://pastebin.ca/1027239
[15:32:44] <SWPadnos> though we fixed the spindle index connection
[15:34:33] <jmkasunich> that still doesn't describe what he is seeing
[15:35:05] <SWPadnos> no, just background info
[15:35:14] <skunkworks> Can I post that the developers are working on inproving this?
http://www.cnczone.com/forums/showthread.php?t=58418
[15:35:28] <jmkasunich> when I was doing my fusee I found and fixed a problem that resulted in a disturbance when going from one threading segment to another, but most people don't use multiple segments
[15:35:54] <SWPadnos> is that in v2_2_branch?
[15:35:54] <jmkasunich> I also saw some disturbances at the start of a thread, and I know the root cause, but not neccessarily a decent fix
[15:36:11] <SWPadnos> he's got the 8.04-aj07 disc, so he's on 2.2.5
[15:36:15] <jmkasunich> the workaround is to start your threading passes far enough in the air that it is over before you start cutting
[15:36:37] <jmkasunich> I dunno, its been a couple of months, I'll have to see if I can find the commit
[15:37:08] <jmkasunich> actually I think cradek found it (after a joint debugging session) but IIRC I tested and committed the fix
[15:37:12] <jmkasunich> lemme look
[15:37:36] <SWPadnos> 3/12/2008 at 11:59PM
[15:38:03] <SWPadnos> yep. it's in 2.2.5
[15:38:08] <jmkasunich> yep
[15:38:16] <jmkasunich> http://cvs.linuxcnc.org/cvs/emc2/src/emc/kinematics/tp.c?graph=1
[15:38:38] <SWPadnos> there already :)
[15:57:01] <alex_joni> skunkworks: yeah, sure.. why not?
[16:01:09] <skunkworks> I didn't know how far along that was or if it was still being thought about :)
[16:01:30] <alex_joni> well.. cradek started working on it
[16:01:40] <alex_joni> and he has a history of finishing things so far ;)
[16:01:53] <skunkworks> I suppose ;)
[16:02:08] <alex_joni> otoh it's not clear when it's "finished"
[16:02:14] <alex_joni> so he can just call it done at any time :D
[16:02:25] <alex_joni> which is also fine ;)
[16:21:56] <SWPadnos> I think it's working for 1 or 2 segment lookahead
[16:35:29] <skunkworks> * skunkworks wonders if he can find some of the screenshots
[16:36:02] <skunkworks> guess how much time I spent trying to get a dial up modem working on me.
[16:36:05] <skunkworks> ME
[16:36:25] <alex_joni> win ME?
[16:36:34] <SWPadnos> 14.73 hours
[16:36:37] <alex_joni> * alex_joni pukes loudly
[16:36:49] <alex_joni> http://pastebin.ca/1028026
[16:37:11] <skunkworks> SWPadnos: pretty close.. (I really didn't keep track)
[16:37:27] <SWPadnos> heh
[16:37:41] <SWPadnos> alex_joni, yeah, but how many seconds does it take to do a full kernel build? :)
[16:37:47] <alex_joni> no gcc on it
[16:37:53] <alex_joni> Timing cached reads: 8776 MB in 2.00 seconds = 4393.12 MB/sec
[16:38:03] <SWPadnos> oh, so it's a gaming machine? :)
[16:38:06] <alex_joni> Timing buffered disk reads: 288 MB in 3.01 seconds = 95.63 MB/sec
[16:38:13] <alex_joni> nope, it'll be a server :)
[16:38:19] <SWPadnos> bummer
[16:38:21] <alex_joni> that's from /dev/md0 (RAID1)
[16:38:31] <SWPadnos> RAID5 SATA?
[16:38:33] <alex_joni> it might make a nice gaming machine though
[16:38:38] <alex_joni> RAID1 sata
[16:38:38] <skunkworks> after trying various motorola, lucent, whatever.. a odd usb modem works. (finding drivers now for me is almost like finding dinasour bones)
[16:38:42] <alex_joni> but software raid
[16:38:51] <SWPadnos> with the right graphics card, I'm sure it would do fine for games
[16:38:58] <alex_joni> skunkworks: trust me.. I know how it feels
[16:39:15] <alex_joni> SWPadnos: 00:02.1 Display controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02)
[16:39:37] <alex_joni> guess this one doesn't really count.. does it?
[16:39:53] <SWPadnos> just upgrade the computer to Vista, then replace the computer with one that can use Vista, then do the same modem driver dance on VIsta, then notice that the machine performs worse than the old one did, then install Linux on both machines and be hapy
[16:40:13] <alex_joni> no thanks .. I'll save myself from doing that
[16:40:14] <SWPadnos> it'll do OK for wolfenstein, I think :)
[16:40:22] <skunkworks> heh - what started the problem, I think, was that the phone company changed thier equipment which made the original modem quit connecting.
[16:40:22] <SWPadnos> that was for skunkworks
[16:40:34] <alex_joni> well.. judging by the fact that I won't have X on it.. you might be right
[16:40:49] <alex_joni> skunkworks: talk about standards
[16:40:49] <SWPadnos> oh, just add the init string to the modem that prevents 4.92bis negotiation
[16:40:57] <SWPadnos> V.92bis, that was
[16:41:33] <skunkworks> Now you tell me :)
[16:41:40] <SWPadnos> well, you didn't ask before :)
[16:41:54] <alex_joni> hmm.. I wonder what's with people and USB..
[16:42:01] <alex_joni> this board has 11 ports
[16:42:04] <SWPadnos> heh
[16:42:13] <alex_joni> no PS2 though
[16:42:26] <SWPadnos> remember, everything should be USB, mice, keyboards, speakers, hard disks, motion controllers
[16:42:29] <SWPadnos> everything!
[16:42:45] <skunkworks> yep - most new stuff is like that. I use usb to ps2 style addaptors.
[16:42:48] <alex_joni> even usb
[16:43:43] <alex_joni> wtf.. I meant "even emc" :)
[16:45:53] <SWPadnos> heh
[16:46:01] <SWPadnos> I wondered what the heck you were trying to say :)
[16:46:10] <alex_joni> yeah, well.. me too
[16:46:17] <alex_joni> (reading some nice man pages.. )
[16:46:42] <SWPadnos> are you following the USB motion controller related discussion on the geckodrive list?
[16:46:47] <alex_joni> nope
[16:46:53] <SWPadnos> well, it's come up again
[16:47:01] <alex_joni> I read the geckodrive list only when I'm really bored
[16:47:13] <SWPadnos> heh
[16:47:29] <alex_joni> now I need to replace a server.. and it will be a _load_ of work to install everything before doing the switch
[16:47:36] <alex_joni> s/install/install & configure/
[16:48:09] <SWPadnos> mv //server1 //server2 ; apt-get --fixallthefuckups
[16:48:10] <alex_joni> the old one is 2.6.8 :D
[16:48:34] <alex_joni> throw some tar cvzf foo|configure && make in there
[16:48:41] <SWPadnos> right!
[16:50:15] <alex_joni> cat /etc/debian_version
[16:50:16] <alex_joni> 4.0
[16:57:54] <skunkworks> http://www.cnczohttp://www.cnczone.com/forums/showthread.php?p=455869#post455869ne.com/forums/showthread.php?p=455869#post455869
[16:58:07] <rayh> It's to bad there isn't a cat /proc/moboinfo command.
[16:59:01] <SWPadnos> hwinfo might do it
[16:59:14] <SWPadnos> hmmm
[16:59:24] <skunkworks> yeck. I ment
http://www.cnczone.com/forums/showthread.php?p=455869#post455869
[17:00:06] <alex_joni> skunkworks: that got a bit mangled
[17:03:23] <skunkworks> alex_joni: computer was running a but slow.. pasted too many times. Second url works.
[17:05:35] <SWPadnos> skunkworks, can you ask Andre' how his controls deal with multiple segments that would gouge (like having 4 segments that approximate a small 90-degree corner)
[17:06:05] <SWPadnos> ie, how much lookahead do they have
[17:28:16] <SWPadnos> ok - the guy was threading at 100RPM
[17:28:24] <SWPadnos> so only 80 position updates per second
[17:31:35] <alex_joni> that might be a bit slow
[17:31:54] <SWPadnos> yep
[17:32:37] <SWPadnos> 12 or 13 servo cycles between position updates, with each update = 7.5 degrees
[18:35:25] <jmkasunich> I guess I should get cracking on that interpolating encoder counter
[18:35:47] <SWPadnos> heh
[18:35:57] <SWPadnos> just make sure there's a scale input :)
[18:36:15] <jmkasunich> there will be - it will be a canonical encoder
[18:36:22] <SWPadnos> I wonderif it would make sense to add it to encoder, with a parameter like "interpolate-position"
[18:36:37] <jmkasunich> I thought a bit about that
[18:37:00] <jmkasunich> undecided at the moment, but I think I'm in favor if keeping it separate
[18:37:06] <SWPadnos> the velocity estimates are quite good, if I remember the plots you did
[18:37:08] <jmkasunich> I could probably be convinced
[18:37:21] <SWPadnos> well, it is an encoder reader ...
[18:37:25] <jmkasunich> the differences will be on the hardware interface side
[18:37:40] <SWPadnos> the count_pulses routine?
[18:38:00] <jmkasunich> not talking about implementation, talking about interface to the world
[18:38:08] <SWPadnos> hmmm
[18:38:23] <jmkasunich> encoder assumes quadrature, with or without intex, but has a counter mode that doens't do quad
[18:38:32] <jmkasunich> dunno if the counter mode does index or not
[18:38:37] <SWPadnos> yes, it does
[18:38:41] <jmkasunich> these low ppr things could be one of three flavors:
[18:38:45] <jmkasunich> 1ppr (index) only
[18:38:46] <SWPadnos> it's only counting that is affected
[18:38:57] <jmkasunich> N ppr with index (quad or single)
[18:39:04] <jmkasunich> Nppr without index (quad or single)
[18:39:19] <SWPadnos> you can't use anything without index
[18:39:21] <jmkasunich> the latter would benefit from the module being able to divide by N and fake an index
[18:39:25] <SWPadnos> sure
[18:39:37] <SWPadnos> but you would eliminate any ability to do multiple passes
[18:39:42] <jmkasunich> why?
[18:39:56] <SWPadnos> threading - you need to know where the spindle is so you hit the same thread on every pass
[18:41:03] <SWPadnos> I guess as long as the feedback is running continuously the fake index would still track
[18:41:03] <jmkasunich> if you have 48ppr with no index, but the driver knows you have 48 ppr, it can fake an index - with quadrature the "index" position would be valid from when you start the module running till you stop it - with single phase it would be valid as long as you don't go backwards
[18:41:13] <SWPadnos> right
[18:41:43] <jmkasunich> I can see the less astute users getting all fscked up by not understanding the real world implications
[18:42:43] <SWPadnos> I guess I'd separate the no index case from the only index case - they're two very different conceptual changes
[18:43:13] <jmkasunich> they're two different dimensions, but they can overlap
[18:43:15] <SWPadnos> synthesized index could be useful in some cases, position estimation between feedback events is useful in some cases
[18:43:18] <SWPadnos> yep
[18:43:38] <jmkasunich> they are both reasonable features for the encoder module to have
[18:43:38] <SWPadnos> they should be more or less independent, though they obviously touch the same files
[18:43:42] <SWPadnos> yep
[18:44:00] <SWPadnos> I'm just saying that to ease the actual implementation, they can be considered separately :)
[18:44:02] <jmkasunich> "interpolate position" and "synthesize index"
[18:44:10] <SWPadnos> yep
[18:44:39] <jmkasunich> and we already have counter mode
[18:44:46] <jmkasunich> which is also an independent dimension
[18:44:48] <SWPadnos> fr synthesize-index mode, I'd stick an input that lets you force the current position to be the index position
[18:44:50] <SWPadnos> yep
[18:44:54] <SWPadnos> s/fr/for/
[18:45:26] <jmkasunich> what are you thinking? manually rotate the chuck to some mark and hit a button?
[18:45:27] <SWPadnos> hmmm. actually, in synthesize-index mode, still reset on an incoming index pulse, but synchronize the internal counter to 0
[18:45:29] <SWPadnos> yep
[18:46:01] <SWPadnos> you can then hook up a pyvcp button to index for the manual mode
[18:46:28] <jmkasunich> I'm afraid the people who are using sync index will also be using single phase - if they touch the chuck after pressing the button and it turns even 1 count backwards they're screwed
[18:46:41] <SWPadnos> unscrewed ;)
[18:46:52] <SWPadnos> yes, that's definitely true
[18:47:08] <jmkasunich> the normal index input wouldn't work for that anyway - it only has an effect if "index-enable" is true, which won't be the case during setup
[18:47:18] <SWPadnos> true
[18:47:19] <jmkasunich> it only goes true right before each threading pass
[18:47:38] <SWPadnos> right. forgot about that
[18:47:41] <jmkasunich> I'm thinking that if you specify synthesize-index, it won't export the index input
[18:47:59] <jmkasunich> the master reset input could be used for what you have in mind though
[18:48:02] <SWPadnos> oh. that makes it a load-time option rather than a HAL parameter
[18:48:15] <jmkasunich> is counter-mode a load time option?
[18:48:30] <SWPadnos> I don't think so
[18:48:36] <jmkasunich> * jmkasunich reads the man page
[18:48:59] <jmkasunich> its a param
[18:49:05] <SWPadnos> right
[18:49:19] <jmkasunich> I suppose it would be nice of the two new features were also params
[18:49:37] <SWPadnos> yep
[18:49:48] <SWPadnos> can you take a look at adding "X2 mode" for counter?
[18:49:54] <SWPadnos> so it counts on rising and falling edges
[18:50:08] <SWPadnos> I didn't look at the mode arrays long enough to figure out how to do that
[18:50:31] <SWPadnos> (I'd use the x4 param for that, like quadrature mode does)
[18:50:48] <jmkasunich> just change the last line of the param description....
[18:51:18] <SWPadnos> heh - right :)
[18:51:26] <SWPadnos> plus add the functionality to the module ;)
[18:51:26] <jmkasunich> all those things seem possible
[19:44:49] <jmkasunich> I just remembered something about lathe threading that makes the initial disturbance worse
[19:45:49] <jmkasunich> EMC's "target" Z position is simply initialZ+spindle_revs*pitch
[19:46:32] <jmkasunich> that target is subjected to accel limiting, but the limiting only means that the command coming out of EMC will lag behind the internal "target", then overspeed to catch up to it
[19:47:24] <jmkasunich> if the internal target were more like "initialZ+accel_distance+spindle_revs*pitch" then it wouldn't have to overspeed to catch up, and much less "air threading" distance would be needed
[19:47:41] <skunkworks> I thought cradek said something about adding pid to that.. o
[19:48:06] <jmkasunich> pid (or whatever) is only about tracking the internal target
[19:48:51] <jmkasunich> as long as the target doesn't include an accel distance offset, the axis will have to go faster than the nominal threading speed to catch up
[19:49:16] <jmkasunich> the accel_distance fix is simple in theory, the trick is what to use for accel_distance
[19:49:54] <jmkasunich> you can't base it on the target axis speed (and thus on spindle speed) because if you did threading passes at different speeds they would have different offsets
[19:50:37] <jmkasunich> might have to base it on max axis speed and the axis accel limit, but that could get ugly
[20:17:14] <rayh> reboot brb
[20:26:53] <alex_joni> ha.. this looks familiar:
http://imagebin.org/18541