Back
[00:56:22] <justin_> justin_ is now known as Twingy
[01:39:28] <jmkasunich> stuste: around?
[01:39:33] <jmkasunich> cradek: how about you?
[01:39:54] <jmkasunich> how come nobody noticed that screw comp was only filtering one direction?
[01:42:52] <jepler> good question
[01:43:04] <jepler> screw comp only, or backlash comp too?
[01:43:20] <jmkasunich> well, stuart's scope traces are for screw comp
[01:43:42] <jmkasunich> although I'm 98% sure that both pass thru the same filter code
[01:44:30] <jepler> I used backlash comp recently
[01:44:38] <jmkasunich> I have backlash comp on my machine
[01:44:41] <jepler> If I didn't notice that it was only backlashing one way I'd be ashamed
[01:44:43] <jmkasunich> and screw comp
[01:44:53] <jepler> though if it was going from +lash/2 to 0, instead of to -lash/2, maybe not
[01:45:08] <jepler> (I didn't look at the trace)
[01:45:11] <jmkasunich> its comping both ways, but its only ramping the comp one way
[01:45:33] <jepler> hm!
[01:45:58] <jmkasunich> on a stepper machine if the comp amount is less than the ferror limit you wouldn't notice, since stepgen would apply its own ramping
[01:46:08] <jmkasunich> http://www.mpm1.com:8080/cinci/pos-neg.png
[01:46:33] <jmkasunich> what confuses me is that both stuart and cradek immediately started looking elsewhere after seeing this pic
[01:46:47] <jmkasunich> makes me wonder if I don't understand what I'm looking at
[01:49:21] <SWPadnos> I can think of two possible buglets that might cause that
[01:49:37] <SWPadnos> one is that the comp in one direction is zero, which may be handled as a special case
[01:50:12] <SWPadnos> oh wait, it isn't. nevermind that one :)
[01:51:44] <SWPadnos> the other is that there could be something of the form if (xx<EPSILON), where there should be a fabs somewhere
[01:53:41] <jmkasunich> I should be looking into this
[01:53:53] <jmkasunich> or I should be doing what I was gonna do this evening, a bit of machining
[01:54:02] <jmkasunich> instead I'm doing nothing....
[01:54:03] <SWPadnos> I'm scanning the code on webCVS right now, but I'm not sure I'm really thinking about it enough
[01:54:05] <jmkasunich> clever, eh?
[01:54:09] <SWPadnos> heh
[01:54:19] <SWPadnos> http://cvs.linuxcnc.org/lxr/source/src/emc/motion/control.c#1558
[01:54:21] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/backlash-comp-scoped.png
[01:54:46] <jmkasunich> jepler: thats what it ought to look like
[01:54:56] <jepler> this is BACKLASH only
[01:55:08] <jmkasunich> which is symmetrical about zero
[01:55:16] <jepler> indeed
[01:55:24] <jmkasunich> I wonder if SWP is onto something with the "correction is zero going one way" thought
[01:55:53] <SWPadnos> hmmm
[01:55:54] <jmkasunich> stuart's file:
[01:55:56] <jmkasunich> -0.5 -0.502 -0.4972
[01:55:56] <jmkasunich> 0.0 0.000 0.0043
[01:55:56] <jmkasunich> 0.5 0.5005 0.5052
[01:56:09] <jmkasunich> note that the correction is zero at zero (in one direction)
[01:56:27] <SWPadnos> actually, there's not really an absolute value in the code - it just subtracts in the opposite direction (a-b vs b-a)
[01:56:54] <SWPadnos> note that the 0.5 entry has a positive number for both directions
[01:57:08] <SWPadnos> you'd expect one to be below the nominal and the other above
[01:57:08] <jmkasunich> yeah
[01:57:25] <jmkasunich> I bet that file is exploring some untested corners of the operating envelope
[01:57:39] <SWPadnos> well, we've got a tester now ;)
[01:58:04] <SWPadnos> if nobody gets to it before tomorrow afternoon, I'll take a look while I'm waiting for my mother
[01:58:28] <jmkasunich> I should look this evening - realistically I'm not gonna do the milling
[01:58:32] <SWPadnos> heh
[01:58:41] <jmkasunich> in fact I should close the garage door before a skunk wanders in there
[01:59:18] <jmkasunich> the filtering code starts at line 1618
[01:59:26] <jmkasunich> and unfortunately I don't understand it
[02:01:05] <SWPadnos> wow - the indexing code has no protection at all on indexing into the comp array
[02:01:11] <jepler> is that 3-line comp file the one to test with? I tried with the one from his "missing = sign" tar and I don't see anything "funny"
[02:01:31] <SWPadnos> while ( joint->pos_cmd < comp->entry->nominal ) {
[02:01:33] <SWPadnos> comp->entry--;
[02:01:35] <SWPadnos> }
[02:01:36] <jmkasunich> I'm gonna start with the three liner
[02:01:36] <SWPadnos> while ( joint->pos_cmd >= (comp->entry+1)->nominal ) {
[02:01:38] <SWPadnos> comp->entry++;
[02:01:39] <SWPadnos> }
[02:01:52] <jepler> I think it's supposed to be ensured that the last entry is "infinity"
[02:01:57] <jepler> there's a leftover brain cell that tells me so
[02:02:02] <SWPadnos> and the first minus infinity
[02:02:03] <jmkasunich> SWPadnos: I bet I put sentry values in the table
[02:02:09] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/screw-comp-scoped.png
[02:02:24] <jepler> this also looks OK to me (but with a different comp file than the 3-liner jmk showed)
[02:02:47] <jmkasunich> I wish I knew more about exactly what stuart did to get those traces
[02:02:58] <SWPadnos> try making an entry with both numbers positive (like line 3 of jmk's sample)
[02:03:26] <SWPadnos> it sounded like he was making very tiny moves, which could have something to do with it
[02:03:32] <jepler> yes, with that other 3-line screw comp file I get weird behavior
[02:03:56] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/screw-comp-scoped-2.png
[02:04:17] <SWPadnos> can you try lines with both errors below nominal and both above nominal?, then change back to "expected" above/below and see if it gets better?
[02:06:45] <jmkasunich> SWPadnos: motion.c:
[02:06:47] <jmkasunich> 981 joint->comp.entries = 0;
[02:06:47] <jmkasunich> 982 joint->comp.entry = &(joint->comp.array[0]);
[02:06:47] <jmkasunich> 1.113 jmkasunich983 /* the compensation code has -DBL_MAX at one end of the table
[02:06:47] <jmkasunich> 984 and +DBL_MAX at the other so _all_ commanded positions are
[02:06:47] <jmkasunich> 1.76 jmkasunich985 guaranteed to be covered by the table */
[02:06:59] <SWPadnos> ok, thanks
[02:08:06] <jepler> SWPadnos: are you asking me to try the other kind of screw comp file?
[02:08:14] <SWPadnos> uh - no
[02:08:26] <jmkasunich> actually, other spots in the same file would do
[02:08:30] <SWPadnos> well, are you using one of the type that Stuart used?
[02:08:35] <SWPadnos> true
[02:08:46] <jmkasunich> for X < 0, I believe the comp values are on opposite sides of zero
[02:08:50] <SWPadnos> just haev one or two points where nominal == "actual" in both directions
[02:08:58] <jmkasunich> for X > 0, both values are on the same side of zero
[02:09:43] <jepler> OK, middle line 0.0 0.001 0.0043 -> bad behavior like for 0.000
[02:09:50] <jepler> middle line 0.0 -0.001 0.0043 -> OK behavior
[02:10:22] <SWPadnos> ok, I think I see the problem
[02:10:31] <jmkasunich> can you try with 0.0 -0.004 -0.001 ?
[02:10:41] <jmkasunich> (both negative instead of both positive)
[02:10:46] <SWPadnos> line 1655 expects to calculate a positive number (according to the comment anyway)
[02:11:09] <jepler> -0.001 -0.002 -> OK, -.001 -.001 -> bad, -.001 0.00 -> bad
[02:11:32] <SWPadnos> the next line is a check to see if the value is indeed positive, and if it isn't, the backlash_filt value is assumed to have overshot the target value, so it's clipped to backlash_corr (lines 1690-1694)
[02:12:01] <SWPadnos> same thing in the other direction, 40 lines later
[02:12:21] <jmkasunich> yeah, the outer if is the error
[02:12:48] <jepler> strangely (to me and my mental model), with this line I don't get any spikes in measured velocity: 0.00 0.002 -0.002
[02:13:13] <SWPadnos> that's kind of backwards, but maybe expected
[02:13:15] <jmkasunich> if the move crosses zero, it works
[02:13:17] <SWPadnos> the sign of the error flips
[02:13:30] <jmkasunich> if the move doesn't cross zero, it has issues
[02:13:37] <jepler> ah, hm
[02:14:05] <jmkasunich> 1655 and 1696 are computing the same thing, but with inverted sign
[02:14:15] <jmkasunich> cause the code tries to split the problem into two cases
[02:14:17] <SWPadnos> yep, there are a few of those
[02:14:42] <jmkasunich> dunno if the split is the proper way to do it or not, but I do know the split condition is wrong
[02:14:58] <jmkasunich> might want to split on the sign of the differnce between -corr and -filt
[02:15:15] <jmkasunich> oh, that won't work either
[02:15:37] <SWPadnos> it's the difference between the current correction value and the necessary correction value that should determine what branch to take
[02:15:39] <jmkasunich> the whole "overshoot" thing depends on knowing which way you were going in the first place
[02:15:41] <jepler> yep, 0 -.002 -.002: bad; 0 .002 .002 -> bad
[02:16:02] <jmkasunich> jepler: I'm a little confised by that
[02:16:08] <SWPadnos> no, it makes sense
[02:16:19] <jmkasunich> 0 -.002 -.002 means that toe correction would be -0.002 regardless of which way you move
[02:16:24] <SWPadnos> the correction value has to cross zero
[02:16:35] <jepler> 0 .002 -.002: good; 0 -.002 .002: good
[02:16:36] <jmkasunich> so there shouldn't be any change in -corr at all
[02:16:55] <jmkasunich> s/toe/the
[02:17:09] <SWPadnos> except that the direction of travel is different, so the correction needs to be subtracted in one direction and added in the other
[02:17:16] <jmkasunich> no
[02:17:17] <SWPadnos> (or something like that ;) )
[02:17:43] <jmkasunich> the numbers are (in a type 0 table): nominal position, actual pos when going fwd, actual when going rev
[02:18:05] <jmkasunich> if both actuals are the same (even if non-zero) that means there is no direction-dependent term
[02:18:19] <jmkasunich> error, but no lash
[02:18:42] <jepler> maybe I screwed up my test, forgot to write the buffer or something
[02:18:43] <SWPadnos> yes, but to get to -0.02, you have to add distance in one direction and reduce it in the other
[02:18:44] <jmkasunich> so the only change in corr as you move would be due to interpolation between adjacent points
[02:18:55] <jmkasunich> SWPadnos: no
[02:19:04] <jmkasunich> position is position
[02:19:17] <jmkasunich> and you add a correction to it to get a new position
[02:19:49] <SWPadnos> true
[02:20:10] <jmkasunich> jepler: you are only tweaking the middle line in the file, right?
[02:20:28] <jepler> jmkasunich: yes
[02:20:47] <jmkasunich> ok, that probably explains why you still see some change in -corr when you reverse
[02:21:00] <jmkasunich> -corr is interpolated between points in the table
[02:21:20] <jmkasunich> its unlikely you are at exactly the spot where you are telling it that forward and reverse error are the same
[02:21:52] <jmkasunich> if you want a fool-proof test, use a two line file:
[02:22:02] <jmkasunich> -1000 -1000.002 -1000.002
[02:22:15] <jmkasunich> 1000 999.998 999.998
[02:22:32] <jmkasunich> that means that the correction in both directions is -.002, over a huge range
[02:22:46] <jmkasunich> you can also make it easier by using a type 1 file
[02:22:53] <jmkasunich> -1000 -.002 -.002
[02:22:59] <jmkasunich> 1000 -.002 -.002
[02:24:06] <cradek> oh did I miss something obvious? darnit
[02:26:10] <SWPadnos> well, pseudo-obvious
[02:26:33] <SWPadnos> a conjecture about where the problem is caused us to look at the code, and there's definitely a problem :)
[02:26:33] <cradek> I didn't know what those traces represented - I didn't look at the code - so I didn't look for obvious problems
[02:26:40] <cradek> excellent
[02:26:53] <jmkasunich> the -corr trace is supposed to step (both ways)
[02:27:02] <jmkasunich> the -filt trace is supposed to be smoothed (both ways)
[02:27:05] <jmkasunich> its only smoothed one way
[02:27:14] <cradek> bonk
[02:27:20] <SWPadnos> I'd call it an optimization bug - using subtraction in different orders depensing on the sign of something, instead of using fabs or other tools
[02:27:30] <SWPadnos> depending
[02:28:43] <jmkasunich> the code would sure be shorter if we could eliminate that conditional
[02:28:52] <jmkasunich> I just have a hunch that it won't be that easy
[02:29:55] <jmkasunich> this is at least the third place in EMC where we attempt to solve the problem of "hit a possibly arbitrarily moving target, while obeying accel and vel limits"
[02:30:10] <jmkasunich> I did the other two, and pulled out a lot of hair in the process
[02:30:30] <jmkasunich> I think thats why I didn't look too closely when baslaarhoven did this one
[02:31:44] <jmkasunich> oh!
[02:31:51] <jmkasunich> I know how to fix this
[02:32:03] <jmkasunich> and to reduce the number of times we solve the same problem
[02:32:08] <jmkasunich> http://cvs.linuxcnc.org/lxr/source/src/emc/motion/simple_tp.h
[02:32:26] <jmkasunich> simple_tp does exactly what we need
[02:32:38] <jmkasunich> (at the time bas did this, it didn't exist)
[02:32:42] <SWPadnos> heh
[02:33:02] <cradek> is that used for jogging yet?
[02:33:06] <jmkasunich> yes
[02:33:17] <cradek> oh right, just not for teleop yet
[02:33:23] <jmkasunich> the original implementation in control.c was moved to simpletp
[02:33:46] <jmkasunich> the third version is in stepgen, and that one is a bit more "peculiar" because of the quantization of step feedback
[02:34:38] <jmkasunich> should I add simple_tp structs and calls, or is someone (jepler) way ahead of me already?
[02:34:44] <cradek> not me
[02:34:59] <cradek> I'm busy breaking something entirely unrelated
[02:35:19] <jmkasunich> hmm, I bet simpletp isn't in 2.2
[02:35:20] <jmkasunich> * jmkasunich looks
[02:35:20] <SWPadnos> these damned CPU databooks are useless
[02:35:27] <SWPadnos> no instruction execution times
[02:35:58] <jmkasunich> hmm
[02:36:14] <jmkasunich> 7 months jmkasunich still not tested, but at least it compiles
[02:36:21] <jmkasunich> maybe its not being invoked yet....
[02:37:51] <jepler> I'm not coding anything
[02:37:59] <jepler> I'm about to call it a night
[02:38:04] <jmkasunich> wellll....
[02:38:32] <jmkasunich> since it looks like simple_tp isn't being invoked yet (even in trunk), I don't want to just throw something out there tonight
[02:38:46] <jmkasunich> it certainly makes sense to solve the problem only once
[02:38:53] <jmkasunich> so I think that is the right approach
[02:39:01] <jmkasunich> but not tonight
[02:39:43] <jmkasunich> I will send a message to the list acknowledging the bug, and describing the workaround (skew the comp data by some constant, so it spans zero at all points)
[02:40:07] <jmkasunich> and I'll work on the fix over the next few days
[02:40:50] <jmkasunich> ah, now I remember
[02:41:03] <jmkasunich> I _did_ change control.c to use simple_tp
[02:41:07] <jmkasunich> but not in the trunk
[02:41:30] <jmkasunich> it is on one of the joint/axis branches
[02:41:38] <cradek> ah
[02:42:12] <jmkasunich> I was starting to wonder there, cause I distinctly remembered making the change. but grep in my checkout said no
[02:43:43] <jmkasunich> the good new is, I can't think of a good reason not to move simple_tp into trunk
[02:44:02] <jmkasunich> test it here, then let the people who are running trunk test it and build confidence in it
[02:44:15] <jmkasunich> the bad news is, we probably don't want to backport something that big to 2.2
[02:44:26] <cradek> no I bet not.
[02:44:57] <cradek> at this stage I think 2.2 should only be getting one-liner fixes unless something is very serious
[02:45:08] <SWPadnos> there are a lot of changes in 2.3~pre already. I think we're getting close to the time to release it
[02:45:13] <cradek> (but that's up to jeff, not me)
[02:45:20] <jmkasunich> I suppose we could copy simple_tp.c (and .h) to 2.2, and invoke it ONLY for the lash/comp, keeping the old jogging code
[02:45:43] <jmkasunich> I definitely want to get simple_tp into 2.3, for both jogging and comp
[02:46:02] <cradek> isn't it simpler and safer to fix the code that's there? an application of fabs or something?
[02:46:05] <jmkasunich> its looking like joints/axes will be 2.4, but so be it
[02:46:15] <jmkasunich> cradek: have at it
[02:46:26] <cradek> bah
[02:46:52] <jmkasunich> (that particular task is one that I don't want to solve again, nor do I want to vet a fix of someone elses solution that I don't totally understand
[02:46:55] <SWPadnos> I'll take a look tomorrow afternoon
[02:47:37] <SWPadnos> I think
[02:48:06] <jmkasunich> http://cvs.linuxcnc.org/lxr/source/src/emc/motion/simple_tp.c
[02:48:29] <jmkasunich> ^^^ that is my preferred solution to the "hit a moving target, within limits" problem
[02:48:32] <SWPadnos> yep, saw that. it's pretty simple
[02:48:37] <SWPadnos> sure
[02:49:07] <SWPadnos> are you thinking of doing that for the correction value, or the whole position?
[02:49:11] <jmkasunich> simple, but tricky
[02:49:17] <jmkasunich> for the correction value only
[02:49:20] <SWPadnos> ok
[02:49:47] <jmkasunich> I'll do exactly what bas did - allocate 50% of max accel, etc for the comp
[02:50:22] <jmkasunich> basically gonna keep lines 1651 and 1652, and replace 1653 thru 1734 or so with an invocation of the simple_tp
[02:50:58] <jmkasunich> for 2.2 I agree that it might be more prudent to tweak the existing code
[02:51:11] <jmkasunich> but I'm not volunteering to do that, cause it hurts my brain
[02:51:41] <SWPadnos> I'll take a look tomorrow afternoon ;)
[02:51:52] <SWPadnos> there's coffee and wifi at the hospital :)
[02:53:58] <SWPadnos> but I'd say it's bedtime for tonight. night guys
[02:54:05] <jmkasunich> goodnight
[02:54:05] <jmkasunich> I
[02:54:19] <jmkasunich> I'm writing a reply to stuart, then I'm goodnight too
[02:54:34] <SWPadnos> oh right. thanks
[02:54:55] <SWPadnos> I'll try any changes on TRUNK first, hopefully it won't be too big a change for 2.2.x
[02:55:04] <SWPadnos> it is a bugfix after all
[02:55:18] <jmkasunich> for TRUNK, I am going to implment the simple_tp
[02:55:45] <SWPadnos> I'm pretty sure our tester is on TRUNK, so that's where the change should be tried first
[02:56:01] <SWPadnos> assuming I come up with a fix I'm reasonably confident in
[02:56:18] <jmkasunich> I'm gonna use simple_tp for both jogging and for comp (two instances of the simple_tp object)
[02:56:34] <jmkasunich> if you are making a simple fix to the existing code, do it in 2.2.x CVS
[02:57:00] <jmkasunich> you can test before you commit, and even after you commit, it only affects people who are running 2.2.x from CVS
[02:57:11] <jmkasunich> until we test some more and issue the next 2.2.x bugfix release
[02:57:33] <SWPadnos> I think the best way to get testing done is to change whichever version Stuart is using
[02:57:53] <jmkasunich> we can replicate the problem here
[02:58:02] <SWPadnos> it's easy enough to fix both, and I won't feel bad if you rip out the change in TRUNK and replace it with simple_tp ;)
[02:58:25] <jmkasunich> ok, I'll sit tight then
[02:58:49] <jmkasunich> (it doesn't make sense for me to touch the code until your commit is done, otherwise I'll have cvs conflicts when I update
[02:59:29] <SWPadnos> heh - ok. if I haven't committed by tomorrow at ~5:00, then it's not coming until the weekend anyway
[03:00:04] <jmkasunich> ok
[03:00:15] <jmkasunich> I won't be touching it till after then anyway
[03:00:19] <jmkasunich> day job and all that you know
[03:00:32] <SWPadnos> yep
[03:09:42] <toastyde1th> spaaaace ghooooooost
[03:55:02] <tomp3> yay i fixed the microwave :)
[04:18:35] <tomp3> toastyde1th: the herman schmidt vise
http://imagebin.org/28320
[04:19:26] <toastyde1th> cool man
[04:19:27] <toastyde1th> ty!
[05:46:55] <gezar> howdy yall
[10:35:40] <sar1> Does any one know of a way to make EMC only use angular units?
[10:36:53] <BigJohnT> use only rotary type joints???
[10:36:59] <sar1> I currently have a spherical machine for which x and y axes make no sense on but can't get a configuration to work with out x and y axes.
[10:37:47] <BigJohnT> I think you have to change something in the ini file...
[10:38:31] <archivist> sar1, use A axis etc
[10:38:47] <archivist> A,B,C
[10:39:32] <BigJohnT> naw, must be in the hal file
[10:42:20] <archivist> * archivist looks at stepconf, that has no ABC, infact its somwhat crippled for odd configs
[10:42:35] <BigJohnT> look up kinematics in the Integrator manual
[10:42:39] <sar1> I thought the ini file too but if I try to use only A B C things get a bit upset. I'll look closer at the hal files then.
[10:43:51] <sar1> Ok thanks BigJohnT. I'll study the kinematics stuff.
[10:44:04] <BigJohnT> Non-trivial kinematics is what your looking for
[10:45:23] <sar1> The reality is that there is so much information on what is really a quite complex system that knowing where to look is half the struggle.
[10:46:27] <BigJohnT> I agree so much with that...
[10:47:20] <archivist> then we need an easy search to find (hence my XML comment to the docs)
[10:50:49] <sar1> Been looking at how to effectively control individual movements remotely for a couple of weeks on and off an finally figured out emcrsh does what is needed.
[10:51:42] <BigJohnT> archivist stepconf is for basic types of configs anything beyond that the integrator needs to understand EMC enough to not need a wizard IMHO
[10:52:21] <BigJohnT> sar1: like a remote arm or something?
[10:54:56] <sar1> BigJohnT: It is Photometer for measuring lights and lamps. It has two radial axes, actually a third as well but it just follows one of the others.
[10:55:36] <BigJohnT> cool
[10:55:52] <archivist> interesting application
[10:56:10] <BigJohnT> so you move it with a joystick or knob?
[10:56:49] <archivist> didnt someone do a microwave antenna measurement application with rotary axis as well
[10:56:50] <sar1> No the intent is to have it fully automated.
[10:57:25] <BigJohnT> ok
[10:57:56] <sar1> One computer does all the measurements and the EMC one moves the mechanics to where the measuremenst are to be taken.
[10:58:50] <BigJohnT> yep, you need to study kinematics then
[11:02:22] <sar1> The microwave application would be similar, however they would be interested in a couple of degrees accuracy where we need and over all uncertantity of less than 0.5deg.
[11:03:38] <archivist> accuracy for microwaves could need higher depends on beam width
[11:05:52] <sar1> Actually your right. When you get gains of 20db+ the beam widths do become rather narrow.
[11:06:15] <archivist> yup I have played with microwaves
[11:06:46] <archivist> long distance work with 30db dishes needs some effort
[11:07:49] <archivist> a quick google found this based on EMC2
http://linux.softpedia.com/get/Science/Enhanced-Machine-Controller-based-Antenna-Range-37079.shtml
[11:08:11] <archivist> I remember seeing something else
[11:09:06] <archivist> here is his sourceforge
http://emcar.sourceforge.net/
[11:09:29] <archivist> his gcode may help/hinder you
[11:12:24] <sar1> Thanks archivist. That lots to digest for a couple of days.
[11:12:43] <archivist> :)
[11:14:24] <archivist> I wonder how many hidden projects are out there that we dont know of
[11:15:42] <micges> many :)
[11:16:44] <archivist> I think that antenna measurement system should be linked on the wiki
[12:04:28] <JymmmEMC> archivist Make it so
[12:07:40] <micges> JymmmEMC: I add this already
[12:09:44] <JymmmEMC> http://www.google.com/search?q=angular+units+site%3Alinuxcnc.org
[12:15:12] <JymmmEMC> Oh, someone was complaining the other day about receiving mailing list pots days later.... SF had upgraded the mailing list software, which had a misconfig, so the queue was backed up. but since fixed
[12:15:21] <JymmmEMC> s/pots/posts/
[13:15:39] <archivist_ub> archivist_ub is now known as archivist
[15:41:43] <lewin1> lewin1 is now known as lewing
[16:24:06] <toastydeath> apparently on my carrier, using blackberry as a tethered modem is free
[16:24:34] <toastydeath> now if wireless would just be stable enough for me to get the drivers
[16:44:05] <alex_joni> lol
http://cgi.ebay.com/Moller-International-M200x_W0QQitemZ250302131552QQcmdZViewItem
[18:38:18] <Anastasia> Sigh, ubuncrap has some problems, sigh.
[18:41:19] <skunkworks> Like what? Works great here..
[18:43:03] <cradek> Anastasia: is that your way of asking for help?
[18:44:00] <Anastasia> cradek: No, just expressing frustration with xorg being screwed up :-)
[19:05:14] <SWPLinux> stustev, stuste1: could you test the backlash correction correction?
[19:31:29] <Paragon_> Hello All.... Just started my first cut a compressor wheel the tool is following the correct path but it is taking off to much material on edges. I just notices emc shows tool dia as 0 but the tol is 4mm what do I need to change to compensate?
[19:32:29] <SWPLinux> change the tool radius
[19:32:33] <cradek> if the tool is 4mm you need to program 2mm outside the edge you want to cut, or else use cutter diameter compensation
[19:33:05] <cradek> to use cutter diameter compensation you will have to code nice entry and exit moves, as well as make sure your path has no concave corners the tool can't fit into
[19:34:21] <Paragon_> the srange thing is the program i used to generate post asks all these questions before generation so i presumed that the offset was calculated at this point. but it seem otherwise. how do i composate from within emc?
[19:34:59] <SWPLinux> add a 4mm cutter to your tool table, and edit the program to use that tool, plus G40/G41
[19:35:16] <SWPLinux> err - G41/G42
[19:35:48] <SWPLinux> if the program wasn't generated with those codes, you're better off re-POSTing it, or you have to figure out (for every move) whether the cutter is to the right or the left of the desired edge
[19:36:00] <SWPLinux> and add the appropriate G41 or G42
[19:36:27] <SWPLinux> and entry/exit moves
[19:37:12] <Paragon_> So I can't just compensate by telling emc that the cutter is 4mm dia?
[19:37:57] <SWPLinux> no. EMC doesn't know which side of the object it's on unless you tell it
[19:39:09] <Paragon_> I see. Still very strange that when the cam program simulated it with the 4mm cutter all was well?
[19:39:32] <SWPLinux> are there G41 and/or G42 codes in the program?
[19:39:47] <Paragon_> just looking now.
[19:39:48] <SWPLinux> if so, it may just be that you need to edit the tool table to match what the CAM program expects
[19:40:44] <Paragon_> No G41 / G42 codes in the program?
[19:40:58] <Paragon_> RhinoCam
[19:40:59] <SWPLinux> hmmm. then the path should be compensated already
[19:41:15] <SWPLinux> I haven't used RhinoCAM before
[19:41:28] <tomp3> compd for ball cutTer, normal cutter?
[19:41:41] <Paragon_> Normal
[19:42:30] <pjm> pjm is now known as Guest8404
[19:44:48] <Paragon_> OK back to the cam prog.... :-(
[19:46:08] <tomp3> Paragon: I dont know rhino, but maybe trying a simpler test than a turbine blade will show up the bugger sooner
[19:47:06] <tomp3> maybe beware of radius/diameter questions
[19:47:49] <Paragon> Yeah into to the fire ... that me all over ... lol
[19:50:49] <Paragon> Here is the bugger ...
http://192.168.2.8/public/cnc/compressor2.jpg
[19:50:53] <Paragon> oopss
[19:51:35] <Paragon> http://srg.hobby-site.com//public/cnc/compressor2.jpg
[19:54:05] <fragalot> looks like fun.
[19:55:02] <cradek> I bet tomp is right (radius/diameter) or something like that
[19:55:04] <fragalot> I'm assuming you aren't expecting those hard edges where the blades meet the main cylinder?
[19:55:35] <toastydeath_> is there an open source project to turn the input from multiple video sources into a 3d scene?
[19:55:42] <fragalot> I'm also assuming it's getting late and I should go to bed :o
[19:55:59] <fragalot> toastydeath_: if you find one, lemme know :p
[19:56:23] <Paragon> lol... this is just a test run then I intend to refine it as I go. :-)
[19:56:58] <SWPLinux> toastydeath_: how do you mean?
[19:57:34] <SWPLinux> there was software several years ago that could look at visual cues in a scene, and adequately map 3D models into the scene on the fly
[19:58:13] <SWPLinux> I think that was done by some university (MIT media lab maybe?)
[19:58:30] <Paragon> Just looking through the post processor creator and the G40 - G43 is greyed out ... Wonder why?
[19:58:44] <SWPLinux> I haven't seen anything that will take multiple live sources and create a model of the scene from them (or multiple stills for that matter)
[19:58:45] <toastydeath_> I mean getting a very rough 3d environment constructed based on fixed cameras
[19:58:50] <Paragon> Dinner is calling .... back soon
[19:59:05] <fragalot> toastydeath_: you mean the type of thing they use for games with the IR cameras?
[19:59:08] <toastydeath_> hmm
[19:59:21] <toastydeath_> frag: no idea
[19:59:34] <toastydeath_> I more mean the google earth type thing
[19:59:56] <SWPLinux> it depends on whether you want to make models of things, or just get enough info so you can map CGI stuff into the scene
[20:00:10] <SWPLinux> it takes more work to make actual models
[20:00:15] <fragalot> I see. Well... I have no idea ;)
[20:00:33] <SWPLinux> there is software that will do that, but I'm pretty sure it's not open source, and it works on stills
[20:00:43] <SWPLinux> (will create models, that is)
[20:00:51] <toastydeath_> Not making models, just enough to establish where things are in the scene
[20:01:12] <toastydeath_> like motion tracking but in 3d
[20:01:27] <SWPLinux> if I think of it when I get home, I'll look for the info I had a few years back
[20:01:36] <toastydeath_> cool, ty
[20:01:42] <SWPLinux> yes, that exists, but probably not as open source
[20:01:48] <SWPLinux> sure
[20:03:02] <SWPLinux> ok, time to see if I can go home yet. bbl
[20:03:10] <toastydeath_> I know I've seen it at my dad's work, but I was just curious
[20:03:17] <toastydeath_> oops
[20:17:19] <pjm> pjm is now known as Guest40088
[20:31:00] <Guest40088> Guest40088 is now known as pjm
[20:31:05] <pjm> pjm is now known as pjmm
[21:15:16] <Paragon> Just looked at the cam program and it say that cutter compensation is only required if the tool in the machine is of a different size then the one used in the post processing. In this case they are the same size?
[21:23:19] <ChanServ> [#emc] "This is the #emc channel - talk related to the Enhanced Machine Controller and general machining. Website:
http://www.linuxcnc.org/, wiki at
http://wiki.linuxcnc.org/"
[21:24:43] <toastydeath_> cutter comp is also necessary if you expect the cutter to wear
[21:31:43] <alex_joni> good night all
[21:43:46] <toastydeath> arrrr
[21:43:50] <tomp3> Paragon: sorry, I have no info on rhino, but you can see what emc thinks about the tool in use
[21:44:00] <toastydeath> where is the cam/gcode stuff for qcad
[21:45:14] <tomp3> maybe dxf2gcode (no native gcode output from free version afik)
[21:45:43] <Paragon> Hey tomp, didn't understand what you mean by 'but you can see what emc thinks about the tool in use'
[21:46:38] <tomp3> toastydeath
http://christian-kohloeffel.homepage.t-online.de/dxf2gocde.html#mozTocId664520
[21:46:51] <toastydeath> Oh... So what are people using for gcode, other than by hand?
[21:46:54] <tomp3> Paragon
[21:46:57] <tomp3> YOU DESCR
[21:46:59] <tomp3> IBE A
[21:47:00] <tomp3> POSSIBL
[21:47:01] <tomp3> E
[21:47:01] <tomp3> CON
[21:47:02] <tomp3> F
[21:47:02] <tomp3> LI
[21:47:07] <tomp3> ??
[21:47:19] <tomp3> weird sorry
[21:47:22] <Paragon> Yes ... lol
[21:47:39] <Paragon> It's getting late here ....
[21:48:16] <tomp3> you describe a possible conflict. you can look at what emc is doing (examine its tool table and data about dia & len) then look at what rhino is 'thinking' to compare the 2
[21:48:50] <tomp3> ( a cable was neat the num pad enter key... doh)
[21:49:34] <Paragon> Arhh yes I see. That is what I am attempting todo at the moment.
[21:49:46] <fenn> i bet rhino does tool comp in the first place
[21:50:49] <tomp3> thats a good point, a pre-offset might occur, but the observation is 'tips clipped' and no mention of 'walls too narrow'
[21:51:20] <tomp3> he's making a turbine wheel
[21:52:28] <Paragon> Yes it does. But it is not working correctly. The tool paths are correct but the cutter is cutting into the fins too leave nothing to show. here is an image of what I am cutting on a 3 axis machine.
http://srg.hobby-site.com/public/cnc/compressor2.jpg
[21:53:03] <tomp3> sorry. 'yes it does what'?
[21:54:08] <Paragon> OK one gives rhino tool information it then uses the tool information ie dia / height etc and factors this into the post.
[21:55:01] <Paragon> Yes it does. Was in answer to fens comment 'i bet rhino does tool comp in the first place'
[21:55:11] <tomp3> (oh boyoboyoboy ubu emc2 live is up to detecting hdwr on the 2nd of these dual celerons )
[21:55:53] <tomp3> ok, and rhibo speaks in diameter, and cutter comp is radial. does that lead you anywhere?
[21:57:23] <Paragon> There is no g41 etc in the code generated by the post processor. As far as EMC is concerned the tool is 0 compensated.
[21:59:09] <tomp3> ok, maybe try a simple test ( maybe a rect pocket not much bigger than the tool, to exaggerate the error )
[22:00:00] <tomp3> or rectangular standing stock may be easier to interpret
[22:00:15] <Paragon> I agree tomp3. I should keep it simple at this stage.
[22:00:40] <tomp3> i am easily confused ymmv ;)
[22:00:42] <Paragon> Until I see what is going wrong.
[22:01:26] <Paragon> Are there any good gcode simulators that are compatable with EMC?
[22:02:14] <tomp3> AXIS ;)
[22:02:53] <Paragon> Only shows tool paths right? Or at least it does on my system.
[22:03:54] <anonimasu> Yes, that's right
[22:05:05] <tomp3> do you want simulated cutting? then I dont know of any, there have been good beginnings made but not a final program afik
[22:08:11] <fenn> Paragon: gdepth shows 2.5d cutting:
http://axis.unpy.net/01169521961
[22:09:35] <fenn> not animated or anything
[22:09:52] <tomp3> help me... "gdepth was written for emc 2.1 alpha 1 or later. It is reported not to work with emc 2.2." isnt 2.2 later than 2.1
[22:09:54] <Paragon> Look pretty good Fenn
[22:10:44] <Paragon> The page says it is reported that it does nopt work with EMC2 2.2
[22:10:48] <skunkworks> http://www.cncsimulator.com/
[22:11:52] <tomp3> .exe? hey anonimasu: "Implements new interpreters for Fanuc and Heidenhain" (the just posted link)
[22:12:51] <Paragon> skunkworks: Look nice.
[22:12:53] <tomp3> i just swapped vid cards on this new install. whats the magic re-config command?
[22:14:29] <fenn> dpkg-reconfigure xserver-xorg
[22:14:30] <skunkworks> dapper or hardy? dapper dpkg-reconfigure xserver-xorg
[22:14:39] <skunkworks> hardy doesn't work that way - iirc
[22:15:04] <Paragon> "/etc/X11/xorg.conf"
[22:15:19] <tomp3> thx
[22:15:40] <Paragon> That the config file not the commands ;-)
[22:16:07] <tomp3> argh howto in hardy?
[22:18:27] <skunkworks> you will probably have to inquire on
http://ubuntuforums.org/
[22:18:40] <skunkworks> or re-install ;)
[22:19:00] <fenn> definitely, re-install
[22:19:15] <fenn> and make sure you do a lot of rebooting too
[22:19:27] <skunkworks> of cource ;)
[22:21:00] <Paragon> Is emc based on ISO, Fanuc or Heidenhein? It mentions RS4 somthing or other in the manual. (Not Audi ;-) )
[22:21:20] <fenn> emc was an attempt to come up with a common g-code standard
[22:21:31] <fenn> it shares a lot in common with fanuc supposedly
[22:22:14] <fenn> note that NIST is also a standards organization
[22:22:52] <Paragon> OK
[22:24:21] <toastydeath> most machine controls try to be faunc-compliant, with a couple notable exceptions
[22:26:03] <toastydeath> faunc, in of itself, is sometimes one of those exceptions
[22:26:31] <Paragon> I see
[22:29:29] <tomp3> i changed the video card, i need to reinstall linux, thats sad
[22:30:34] <jmkasunich> tomp3: I find that hard to believe
[22:31:52] <tomp3> change 'need' to the best advice i can find so far, abd i been lookin
[22:35:58] <toastydeath> change the driver in xorg and if necessary module-assistant
[22:36:04] <toastydeath> ?
[22:37:06] <tomp3> xorg.conf no longer tells you the driver , it sez something like the default with no indication of the real file. its already being trashed. i been here before
[22:40:08] <fenn> at worst you should apt-get install --reinstall xserver-xorg
[22:40:18] <fenn> i wish i knew how to fix your problem but i dont use hardy
[22:40:44] <tomp3> np thx
[22:43:03] <toastydeath> does anyone actually use dxg2gcode for anything
[22:43:24] <tomp3> havent used it, hope you'd report ;)
[22:44:17] <toastydeath> Maybe I'm retarded and there are hidden options, but I wouldn't use this for anything
[22:44:45] <toastydeath> I am holding out hope for apt360
[22:46:25] <Paragon> Just ran the the gcode for the compressor in the cncSimulator it appears to show exaclty what EMC physical does. Where as the Cam sim showsthe part as intended. I think it must be Cam / post processor that has the problem.
[22:46:29] <tomp3> apt is concerned with path, not form
[22:47:29] <tomp3> Paragon maybe look at the post, maybe ask at #rhino if it exists
[22:48:32] <Paragon> Will do..
[22:50:34] <toastydeath> tomp: I am looking for usable gcode first and foremost
[22:50:57] <toastydeath> just trying to see what's out there at the moment
[22:52:47] <tomp3> toastydeath: ah, the code i made with apt360 ran fine, give it a try, it needs to be used and feedback given to its authors.
[22:53:31] <toastydeath> I see some advantages to writing some of our parts in apt
[22:53:42] <toastydeath> with respect to engineering changes
[22:55:15] <tomp3> re no video after switching cards, it looks like ATI has as many issues as NVidia, now swapping cards back to agp nvidia, it gave me video and it seems the ati wont (besides a terminal)
[23:03:57] <stuste1> toastydeath: from my evaluation of apt360 you should be able to use it for a lot of 2 1/2 axis stuff
[23:04:13] <jepler> tomp3: I blame nvidia for that -- installing their proprietary drivers seems to be poison for most other graphics cards.
[23:04:28] <jepler> if you installed them with the package manager, uninstall them the same way and file bugs at ubuntu if that doesn't give you a working system
[23:09:06] <tomp3> i agree that NV should open up but System|Hardware Drivers reports 'no proprietary drivers are in use on this syetm" with the NVidia 5200 agp card.
[23:10:02] <tomp3> and any installation was auto by the ubuntu -emc2.2 live cd. i dont even know how to change it to vesa driver. xorg.conf is 'ubiquitous'
[23:11:17] <tomp3> monitor "Configured Monitor" device "Configured device" how informative
[23:12:03] <tomp3> excuse me, i'm just bitchin sorry
[23:44:47] <toastyde1th> woot home
[23:45:09] <toastyde1th> stuste1: ty, all we do is 2 1/2 and 2 1/2 + 1
