mshaver: do you have G61 or G64 in effect?
and I was talking about the reset that's in the picture - I understand it's on roll
yay, jr finally has coolant circulating - what a job
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)
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.
can you put your program on pastebin.ca?
(I'm still building)
[00:51:34] <mshaver> http://pastebin.ca/1642191
yuck, I see what you mean
if I turn the spindle speed down, it settles and tracks nice
yeah the blend must be wrong. yuck.
yep! spindle speed override varies the effect. I'm really glad you could confirm this!
it's pretty easy to see the effect in sim
was it better in an earlier version that you know of? I thought this used to work ok.
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.
well, I think it did work at one time.
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
oh yeah, yuck
but since it's bad in sim also, it will be easier...
we replaced just about everything trying to find this. we even changed the spindle encoder...
ugh, sorry you went through that. it's just broken software
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 :)
so many problems with threading lately - maddening
it's a hard thing to do - just ask the Mach folks
at least according to an earlier discussion I saw on here or #emc
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!~
well I don't share your elation...
no, I guess you don't...
2.3.0 is no better...
yeah, building it...
you get good motion if you don't do these tapers, right?
L0 and L2 work fine.
L2 is exit only?
I think it's also bad, but so short you don't notice it
well not short - I mean near the end
apparently I can't run 2.2.x on this OS
aha, yes I can, I just have to comment out parts of AXIS
no, I think it's the J one
2.2.8 is much better
i wonder what changed
I "improved" it - changes to work better on low accel machines
sim/lathe is pretty high accel and it works fine (great) with the old algorithm
there's a little error blip and it very quickly catches up and tracks, same for the blend
this is in tp?
I must now eat and sleep. Tomorrow will be here soon enough! Good night.
cradek: since I have to rebuild and reupload it anyway, let me know if you want 2.3.4 held for this issue.
jepler: I know a little more about it - can I let you know later tomorrow?
steve_stallings is now known as steves_logging
cradek: yes, that's fine.
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-10-25.txt
in the shower I realized that this has always been completely wrong
no wonder people keep having trouble with it not working right
heh - that is funny. (I do some of my best thinking in the shower.)
requested velocity = position error/time
if you ever get in exactly the right place, what should you do?
the answer is KEEP GOING, not stop
wtf? who wrote that?
if anyone complains - you can slap them.
I am sure it made perfect sense at the time.
well the real problem is putting something correct in its place
take another shower?
you have a "PID" with only a P term
it wants either an I, or (better), some feedforward
I think I found an answer that looks good in testing - wonder how it works on various machines with variously bad spindle feedback
cradek: hm, that's sounding like "don't add to 2.3.4 at the last minute" territory..
yeah, that makes me pretty uncomfortable
cradek: I realized that this has always been completely wrong
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.
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.
I haven't gotten to my lathe yet this weekend - I was hoping for yesterday - the wife had other plans.. :-(
I'll try to get to it tomorrow - I have a 200 ppr encoder on the spindle - is that crappy enough ;-)
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??
cradek: ok, thanks for looking at it
[19:53:01] <cradek> http://timeguy.com/cradek-files/emc/0001-fix-threading-oscillation.patch
cradek: is it just me, or are you declaring spindle_vel and target_vel inside both branches of an if-else?
yes I guess so
that means each set is independent, even tho they have the same names...
I know it's legal, but it just seems so wrong to me
of course, I like all decls at the top of the function - old school
generally I like scopes as small as possible, but this is a little silly.
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 }
but really the patch was for testing, not for style-warring
yeah, forget I said anything
EMC: 03jepler 07v2_3_branch * r45469802c153 10/ (debian/changelog nc_files/M101): fix spurious addition of a python2.4 dependency
EMC: 03jepler 07v2_3_branch * r45d27a393866 10/ (VERSION src/configure): bump version for release
EMC: 03jepler 07v2_3_branch * r157e39583de4 10/VERSION: bump version after release
ok, 2.3.4-1 packages in repository
EMC: 03jepler 07v2_3_branch * r97b255c52a94 10/debian/changelog: note new fixes
and I have to run now, will do the release e-mail later
I'll do SF and linuxcnc.org announcements tomorrow morning
mshaver: I think cradek has a patch for testing.. http://timeguy.com/cradek-files/emc/0001-fix-threading-oscillation.patch
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
just have to call the power company to hook up the garage and I can then hook the house up.