Back
[00:36:10] <cradek> mshaver: do you have G61 or G64 in effect?
[00:37:01] <cradek> and I was talking about the reset that's in the picture - I understand it's on roll
[00:40:57] <cradek> yay, jr finally has coolant circulating - what a job
[00:42:46] <mshaver> looking...
[00:43:35] <cradek> if you force blending off (G61) and then expect a blended exit move without stop, it might cause this (I haven't even tried it yet)
[00:44:03] <mshaver> g64
[00:44:07] <cradek> ok, hmm
[00:46:04] <cradek> building 2.3...
[00:47:00] <mshaver> Basically, it's g76.ngc from the examples with everything removed from g18 to (thread). I also changed the z-0.5 to z-2.0 in the g76 block to lengthen then thread. Finally, the (part) section was removed.
[00:47:21] <cradek> can you put your program on pastebin.ca?
[00:47:25] <cradek> (I'm still building)
[00:47:40] <mshaver> sure!
[00:51:34] <mshaver> http://pastebin.ca/1642191
[00:56:45] <cradek> yuck, I see what you mean
[00:57:40] <cradek> if I turn the spindle speed down, it settles and tracks nice
[01:04:33] <cradek> yeah the blend must be wrong. yuck.
[01:04:52] <mshaver> yep! spindle speed override varies the effect. I'm really glad you could confirm this!
[01:05:54] <cradek> it's pretty easy to see the effect in sim
[01:06:11] <cradek> was it better in an earlier version that you know of? I thought this used to work ok.
[01:06:31] <mshaver> bump the spindle speed up to 1500 and then set the override at 64%. if your setup responds like mine, you'll see severl pauses in each pass.
[01:07:03] <mshaver> well, I think it did work at one time.
[01:08:14] <mshaver> I just couldn't go back to an earlier version because I couldn't seem to get an older 5i20 firmware image and an older emc to co-habitate peacefully
[01:08:25] <cradek> oh yeah, yuck
[01:08:52] <mshaver> but since it's bad in sim also, it will be easier...
[01:09:55] <mshaver> we replaced just about everything trying to find this. we even changed the spindle encoder...
[01:10:55] <cradek> ugh, sorry you went through that. it's just broken software
[01:11:07] <mshaver> Dave our technician asked early on if there could be something wrong with the part program, and I assured him that there was nothing you could program that would cause this to happen :)
[01:11:25] <cradek> so many problems with threading lately - maddening
[01:11:44] <mshaver> it's a hard thing to do - just ask the Mach folks
[01:12:23] <mshaver> at least according to an earlier discussion I saw on here or #emc
[01:13:49] <mshaver> I'm happy it's a bug! It could have been some bizarre config issue that would keep me in Ann Arbor past the end of this month! I'm actually tickled to death!~
[01:14:14] <cradek> well I don't share your elation...
[01:14:36] <mshaver> no, I guess you don't...
[01:16:40] <cradek> 2.3.0 is no better...
[01:20:18] <mshaver> 2.2.8?
[01:20:24] <cradek> yeah, building it...
[01:21:36] <cradek> you get good motion if you don't do these tapers, right?
[01:22:56] <mshaver> L0 and L2 work fine.
[01:23:09] <cradek> L2 is exit only?
[01:23:18] <mshaver> yep
[01:23:27] <cradek> I think it's also bad, but so short you don't notice it
[01:23:38] <cradek> well not short - I mean near the end
[01:23:50] <mshaver> could be!
[01:24:05] <cradek> apparently I can't run 2.2.x on this OS
[01:25:19] <mshaver> not hardy?
[01:25:21] <cradek> aha, yes I can, I just have to comment out parts of AXIS
[01:26:13] <cradek> no, I think it's the J one
[01:28:02] <cradek> 2.2.8 is much better
[01:28:30] <mshaver> i wonder what changed
[01:29:03] <cradek> I "improved" it - changes to work better on low accel machines
[01:30:46] <cradek> sim/lathe is pretty high accel and it works fine (great) with the old algorithm
[01:31:45] <cradek> there's a little error blip and it very quickly catches up and tracks, same for the blend
[01:33:22] <mshaver> this is in tp?
[01:33:26] <cradek> yes
[01:54:25] <mshaver> I must now eat and sleep. Tomorrow will be here soon enough! Good night.
[03:10:36] <jepler> cradek: since I have to rebuild and reupload it anyway, let me know if you want 2.3.4 held for this issue.
[03:10:57] <jepler> 'night
[03:11:06] <cradek> jepler: I know a little more about it - can I let you know later tomorrow?
[03:11:19] <cradek> goodnight
[13:01:24] <steve_stallings> steve_stallings is now known as steves_logging
[13:15:50] <jepler> cradek: yes, that's fine.
[15:35:36] <skunkworks> logger_dev: bookmark
[15:35:36] <skunkworks> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-10-25.txt
[16:40:47] <skunkworks> cradek: yeck.
[18:19:13] <cradek> in the shower I realized that this has always been completely wrong
[18:19:20] <cradek> no wonder people keep having trouble with it not working right
[18:19:59] <skunkworks> heh - that is funny. (I do some of my best thinking in the shower.)
[18:20:01] <cradek> requested velocity = position error/time
[18:20:16] <cradek> if you ever get in exactly the right place, what should you do?
[18:20:26] <cradek> the answer is KEEP GOING, not stop
[18:20:35] <skunkworks> heh
[18:20:36] <cradek> wtf? who wrote that?
[18:21:03] <skunkworks> if anyone complains - you can slap them.
[18:25:07] <skunkworks> hard
[18:28:07] <skunkworks> I am sure it made perfect sense at the time.
[18:28:41] <cradek> well the real problem is putting something correct in its place
[18:47:11] <skunkworks> take another shower?
[18:47:15] <skunkworks> ;)
[18:59:26] <jmkasunich> you have a "PID" with only a P term
[18:59:48] <jmkasunich> it wants either an I, or (better), some feedforward
[19:01:33] <cradek> I think I found an answer that looks good in testing - wonder how it works on various machines with variously bad spindle feedback
[19:29:02] <jepler> cradek: hm, that's sounding like "don't add to 2.3.4 at the last minute" territory..
[19:39:04] <cradek> yeah, that makes me pretty uncomfortable
[19:39:53] <Dave911> cradek: I realized that this has always been completely wrong
[19:39:55] <Dave911> I was having a hard time understanding myself why the lack of a pulse would tell the controller to consider the spindle to be stopped! It makes sese as to why the symptoms appear but the basic logic is as you say - flawed.
[19:39:57] <Dave911> If the control change was based on more than one servo sample also - as in some type of Integration routine - ala the I in PID or something similar, or some type of adaptive feed forward routine, you could get around the need for the interpolated encoder usage.
[19:39:58] <Dave911> I haven't gotten to my lathe yet this weekend - I was hoping for yesterday - the wife had other plans.. :-(
[19:41:40] <Dave911> I'll try to get to it tomorrow - I have a 200 ppr encoder on the spindle - is that crappy enough ;-)
[19:42:53] <Dave911> I haven't looked at the TP code yet either.. but does the same routine "have" to be used for tapping as well as threading??
[19:43:21] <jepler> cradek: ok, thanks for looking at it
[19:53:01] <cradek> http://timeguy.com/cradek-files/emc/0001-fix-threading-oscillation.patch
[19:54:18] <jmkasunich> cradek: is it just me, or are you declaring spindle_vel and target_vel inside both branches of an if-else?
[19:56:08] <cradek> yes I guess so
[19:56:35] <jmkasunich> that means each set is independent, even tho they have the same names...
[19:56:44] <jmkasunich> I know it's legal, but it just seems so wrong to me
[19:57:20] <jmkasunich> of course, I like all decls at the top of the function - old school
[19:58:44] <cradek> generally I like scopes as small as possible, but this is a little silly.
[20:00:05] <cradek> when used for a temporary calculation, it's nice to show the reader where it's used, and then let the reader forget about it after he passes the }
[20:00:42] <cradek> but really the patch was for testing, not for style-warring
[20:02:32] <jmkasunich> yeah, forget I said anything
[21:52:09] <CIA-82> EMC: 03jepler 07v2_3_branch * r45469802c153 10/ (debian/changelog nc_files/M101): fix spurious addition of a python2.4 dependency
[21:52:09] <CIA-82> EMC: 03jepler 07v2_3_branch * r45d27a393866 10/ (VERSION src/configure): bump version for release
[21:52:10] <CIA-82> EMC: 03jepler 07v2_3_branch * r157e39583de4 10/VERSION: bump version after release
[21:52:15] <jepler> ok, 2.3.4-1 packages in repository
[21:52:17] <CIA-82> EMC: 03jepler 07v2_3_branch * r97b255c52a94 10/debian/changelog: note new fixes
[21:52:50] <alex_joni> dapper too?
[21:52:57] <jepler> no
[21:53:05] <jepler> and I have to run now, will do the release e-mail later
[21:54:17] <alex_joni> I'll do SF and linuxcnc.org announcements tomorrow morning
[22:37:37] <skunkworks> mshaver: I think cradek has a patch for testing..
http://timeguy.com/cradek-files/emc/0001-fix-threading-oscillation.patch
[22:42:04] <mshaver> hmmm....
[22:43:43] <mshaver> I'll have to see how things go tomorrow. The machine that spawned all this difficulty is to be shipped, and I haven't got another for a while.
[23:21:47] <skunkworks> http://imagebin.ca/img/7zdecui.jpg
[23:22:15] <skunkworks> just have to call the power company to hook up the garage and I can then hook the house up.
