#emc-devel | Logs for 2007-07-09

[00:08:07] <jmkasunich_> jmkasunich_ is now known as jmkasunich
[01:18:11] <cradek> jepler: a while back you hacked truetype-tracer to use biarcs. Did you give me those changes and I lost them, or did you decide you didn't like it?
[01:26:31] <jepler> cradek: I don't know whether I gave you the changes
[01:26:57] <cradek> it did work better didn't it?
[01:27:22] <jepler> cradek: it seems like I was able to reduce the number of lines quite a bit while preserving the letter shapes
[01:27:35] <jepler> I dunno whether I have it anymore
[01:27:55] <jepler> but I may remember the biarc method well enough to implement it again .. in between all my other projects
[01:28:00] <cradek> no big deal, but if you run across it, it might be nice to integrate it
[01:28:29] <jepler> I'll look around
[01:28:44] <cradek> thanks, but don't lose any sleep
[02:09:05] <jepler> if you had two encoders on the same shaft, one with p counts and one with q counts can you compute a position of 1 part in lcm(p,q) per revolution?
[02:13:13] <jmkasunich> I don't think so
[02:13:38] <jmkasunich> assume for example p = 100 and q = 101
[02:26:41] <jepler> hm
[02:27:35] <jmkasunich> you can't know the position of the shaft to a resolution much finer than the lines on the encoder wheel
[02:28:22] <jmkasunich> in fact the main limit on encoder resolution is ambiguity in the location of the lines
[02:45:16] <jepler> oh well, another perfectly crappy idea shot down
[02:45:21] <jmkasunich> sorry
[12:30:14] <jepler> good morning all
[12:40:40] <skunkworks> morning jepler
[12:45:59] <alex_joni> hi
[13:45:21] <jepler> cradek: I don't think that arc version of ttt is going to turn up
[13:45:36] <cradek> ok, thanks anyway
[13:45:41] <jepler> maybe when I don't have any other projects going on I'll redo it
[13:47:03] <cradek> no big deal - but if it wasn't yet lost I didn't want it to get forgotten.
[13:47:50] <jepler> I have a feeling it was on 'india' before it was reinstalled
[13:48:20] <cradek> * cradek digs through old tapes...
[13:48:31] <cradek> woo
[13:48:44] <cradek> india rh9 final 2-22-07
[13:49:06] <jepler> I was posting on the axis blog about biarcs around 2-18
[13:49:15] <jepler> so it may be a good bet
[13:50:09] <jepler> another possibility would be to include the subroutines from http://axis.unpy.net/files/01171492370/biarcs.ngc and call them in ttt's generated gcode
[13:50:19] <jepler> it's not quite biarcs but it also gave good results
[13:54:30] <cradek> not seeing it - any idea where to look?
[13:55:06] <jepler> /usr/local/jepler/src ?
[13:55:59] <cradek> nope
[13:56:05] <jepler> I guess you can't run "locate" on a backup ..
[13:56:42] <cradek> dump really ought to have some kind of find in the index
[13:57:01] <jepler> seems like it doesn't require any information not already read from the tape
[13:57:05] <cradek> right
[13:57:33] <cradek> aha usr/src/ttt
[13:57:41] <cradek> (ls */*/*ttt* works)
[13:58:09] <jepler> I wonder if it's the right one .. I found half a dozen copies possibly with other modifications but not arcs
[14:47:07] <alex_joni> sebjames: hi
[14:47:13] <sebjames> hi
[14:47:23] <alex_joni> sebjames: look at NML_INTERP_LIST::append()
[14:47:33] <sebjames> I think the problem really is that the appends are out of order
[14:47:41] <alex_joni> lines 74,82,97,106
[14:47:47] <alex_joni> 106 should be before 97
[14:48:19] <alex_joni> right
[14:48:20] <sebjames> Yes
[14:48:25] <sebjames> That's right
[14:48:32] <alex_joni> now.. the problem is to figure out where this inversion comes from
[14:48:43] <alex_joni> emcTaskPlanCommand is called in the right order
[14:48:53] <sebjames> That is, the appends happen in the wrong order. Yes, where does it happen...
[14:50:37] <sebjames> First emcTaskPlanLine gets called in emctaskmain
[14:50:39] <sebjames> .cc
[14:50:47] <sebjames> Then emcTaskPlanCommand
[14:50:52] <alex_joni> emcTaskPlanCommand sends the read stuff to interp
[14:50:59] <sebjames> int emcTaskPlanLine()
[14:50:59] <sebjames> {
[14:50:59] <sebjames> return interp.line();
[14:50:59] <sebjames> }
[14:50:59] <sebjames> int emcTaskPlanCommand(char *cmd)
[14:51:00] <sebjames> {
[14:51:02] <sebjames> char buf[LINELEN];
[14:51:05] <sebjames> strcpy(cmd, interp.command(buf, LINELEN));
[14:51:07] <sebjames> return 0;
[14:51:08] <sebjames> }
[14:51:10] <sebjames> They're pretty simple...
[14:51:17] <alex_joni> yes
[14:51:27] <alex_joni> * alex_joni is hunting for interp.command
[14:52:20] <sebjames> char *command(char *buf, int len) { line_text(buf, len); return buf; }
[14:52:29] <sebjames> In rs274ngc.hh
[14:52:33] <alex_joni> yeah, found it too.. but that's a red herring
[14:52:39] <sebjames> ?
[14:52:47] <alex_joni> sebjames: open src/emc/task/emccannon.cc
[14:53:12] <alex_joni> and add some printf's in STRAIGHT_TRAVERSE()
[14:53:28] <sebjames> oK
[14:53:28] <alex_joni> sebjames: red herring = not what we're after
[14:53:52] <sebjames> Sorry, yes, knew that. Wasn't sure why you reckoned it was a red herring.
[14:54:19] <sebjames> Well, it just reads a line of text....
[14:54:20] <alex_joni> that's the default way of passing data to the interp
[14:54:35] <alex_joni> if it would be broken, we would have heard about it.. don't you think?
[14:54:36] <sebjames> Hang on - let me get those debugging msgs into STRA...
[14:54:36] <alex_joni> ;)
[14:54:47] <sebjames> I reckon so
[14:55:00] <alex_joni> add a debug message to src/emc/task/emctask.cc too
[14:55:10] <alex_joni> in user_defined_add_m_code()
[14:55:54] <sebjames> if(acc)
[14:55:54] <sebjames> interp_list.append(linearMoveMsg);
[14:56:03] <sebjames> In ecconnon.cc
[14:56:21] <sebjames> Seems to... oh that's only a message
[14:56:22] <alex_joni> STRAIGHT_FEED() is G1 .. sorry
[14:56:38] <sebjames> Oh, right.
[14:56:38] <alex_joni> STRAIGHT_TRAVERSE() is G0
[14:56:43] <sebjames> *nod*
[14:58:43] <sebjames> I just put a rcs_print ("%s called", __FUNCTION__) message in each of those.
[14:58:48] <alex_joni> right
[15:01:24] <sebjames> http://pastebin.ca/610540
[15:02:13] <sebjames> whoops missed some \n
[15:03:27] <alex_joni> ok, so the STRAIGHT_FEED() gets called in time
[15:03:35] <alex_joni> but the NML_INTERP_LIST::append doesn't
[15:03:45] <alex_joni> line 94
[15:04:00] <alex_joni> and 112 when the append() happens
[15:04:24] <sebjames> *nod*
[15:04:51] <sebjames> Updated the paste. 610545
[15:05:21] <sebjames> STRAIGHT_FEED isn't leading to an append()
[15:05:26] <alex_joni> * alex_joni pings jepler
[15:05:31] <alex_joni> sebjames: it is ;)
[15:05:39] <sebjames> Just late...
[15:05:46] <alex_joni> but only after trying to be smart about merging segments
[15:06:23] <alex_joni> we simply need to make see_segment()? understand that it can't link stuff with M1xx happening at the same time
[15:06:56] <alex_joni> that's why I'm pinging jepler, he understands more of this part :)
[15:07:25] <sebjames> ok
[15:07:48] <alex_joni> we need linkable() to return false for this case..
[15:08:03] <sebjames> You mean around where it says: chained_points().push_back(pos);
[15:08:12] <alex_joni> a bit earlier
[15:08:20] <alex_joni> if(!chained_points().empty() && !linkable(x, y, z, a, b, c)) {
[15:08:20] <alex_joni> flush_segments();
[15:08:20] <alex_joni> }
[15:08:43] <alex_joni> if linkable() is false, it flushes segments (appends the FEED right away)
[15:08:53] <sebjames> Right
[15:09:03] <alex_joni> at least I hope that :D
[15:09:05] <sebjames> I see
[15:09:09] <sebjames> I think that makes sense./
[15:09:50] <alex_joni> but I can't see any way to check this :-s
[15:10:36] <sebjames> Yes
[15:11:01] <alex_joni> sebjames: try adding flush_segments() to the m-code stuff in emctask.cc
[15:11:19] <alex_joni> user_defined_add_m_code()
[15:11:31] <sebjames> Ok.
[15:11:36] <alex_joni> at the beginning of the function, add the flush_segment() call
[15:11:49] <alex_joni> (without the spelling errors I did :)
[15:13:41] <alex_joni> yup.. I bet this one escaped jepler because it's in a different file than emccanon.cc
[15:14:03] <cradek> USER_DEFINED_FUNCTION() should be a canon call
[15:14:31] <alex_joni> cradek: it's worse ;)
[15:14:39] <sebjames> alex_joni: Can you have a sub-second pause in emc?
[15:14:39] <alex_joni> it's a canon array of calls
[15:14:49] <alex_joni> sebjames: G4 P.1 ?
[15:14:55] <sebjames> Yes
[15:14:58] <alex_joni> sure
[15:14:59] <sebjames> Great
[15:15:26] <alex_joni> cradek: canon has a table of function pointers which point to the USER_DEFINED_FUNCTION's
[15:15:51] <cradek> * cradek covers his eyes
[15:15:59] <alex_joni> cradek: task fills that array based on the M1xx it finds, but the prototype function is in emctask.cc
[15:16:08] <alex_joni> I agree it should be in emccanon.cc
[15:16:59] <alex_joni> sebjames: any luck?
[15:18:37] <sebjames> alex_joni: Hold on
[15:21:28] <sebjames> I'm going to have to #include emccannon.cc or something in emctask.cc
[15:21:45] <sebjames> or move flush_segments somewhere common.
[15:23:25] <alex_joni> put flush_segments into canon.hh
[15:23:46] <alex_joni> src/emc/nml_intf/canon.hh
[15:25:42] <sebjames> Great minds... That's waht I just did
[15:27:10] <sebjames> It's declared static in emccannon.cc
[15:27:27] <sebjames> So I need to change it to extern in cannon.cc
[15:29:55] <alex_joni> you could also call FINISH() :P
[15:29:59] <alex_joni> void FINISH() {
[15:30:00] <alex_joni> flush_segments();
[15:30:00] <alex_joni> }
[15:30:30] <alex_joni> * last segment to be output, if it has been held to do segment merging */
[15:30:32] <alex_joni> extern void FINISH(void);
[15:30:33] <sebjames> That worked
[15:30:45] <alex_joni> calling FINISH() ?
[15:30:51] <sebjames> Yahoo!
[15:30:56] <alex_joni> ;-)
[15:31:06] <sebjames> adding extern flush_segments(void); to cannon.hh
[15:31:18] <alex_joni> right..
[15:31:20] <sebjames> And removing the static keyword from flush_segments in emccannon.hh
[15:31:33] <alex_joni> * alex_joni doesn't really like this approach
[15:31:50] <alex_joni> it seems jepler already added a canon call called FINISH() to call flush_segments() only
[15:32:11] <alex_joni> anyways.. does it work in order now?
[15:33:16] <sebjames> Yes, works correctly
[15:33:34] <sebjames> Is FINISH available in emctask?
[15:33:37] <alex_joni> great.. so it was nothing serious
[15:33:42] <alex_joni> sebjames: yeah
[15:33:58] <sebjames> Ok, I'll call that then
[15:33:57] <alex_joni> the upper lettered canon calls are all available from the outside
[15:34:02] <sebjames> Ok
[15:35:20] <jepler> alex_joni: thanks for tracking down that problem
[15:35:25] <alex_joni> no problem ;)
[15:35:39] <alex_joni> not your fault it was defined in another file :P
[15:35:55] <alex_joni> I'll do that change here and commit
[15:36:06] <jepler> OK -- it probably warrants backporting to 2.1 as well
[15:36:05] <sebjames> Great.
[15:36:12] <sebjames> Definitely
[15:36:54] <alex_joni> will do :)
[15:37:30] <sebjames> I'm just trying the call to FINISH in user_defined_add_m_code
[15:38:11] <sebjames> Compiles fine.
[15:38:23] <alex_joni> one line fix :P
[15:38:34] <alex_joni> 1 hour searching for it :P
[15:40:42] <sebjames> ALway the way isn't it?
[15:41:08] <sebjames> Anyway - we got it in time. My boss/client was all for putting G04P.1 lines in all his programs
[15:41:31] <sebjames> Because they have the effect of breaking up the moves
[15:41:37] <skunkworks> you can be flexable when it is cheap ;)
[15:42:03] <cradek> or, you can fix the bugs and then not have to hack around them, when it's free software
[15:42:20] <cradek> (sorry, preaching to choir)
[15:42:25] <sebjames> :)
[15:43:03] <alex_joni> cradek: he helped fix the bug :P
[15:43:07] <sebjames> I just need to be able to comamnd a homing sequence from a M/G code now...
[15:43:37] <sebjames> I understand that's going to take some hacking
[15:43:40] <cradek> why do you want that?
[15:44:00] <alex_joni> strange machine ;)
[15:44:13] <sebjames> We don't Zero the X axis, we place a piece of metal in the machine and move the end of it to a position, and call that Zero
[15:44:16] <sebjames> Not that weird
[15:44:37] <sebjames> We feed a 6 to 7 metre length of plate through the machine, cutting it into pieces as we go.
[15:44:54] <sebjames> We need to set the X axis psoition to 0 before each run
[15:45:04] <alex_joni> sebjames: if I commit, can you test the latest TRUNK?
[15:45:17] <sebjames> alex_joni: Sure, but maybe not till tomorrow
[15:45:34] <skunkworks> couldn't you do a g10l2p1x0 or similar?
[15:45:53] <sebjames> Erm...
[15:46:04] <sebjames> Could I?
[15:46:15] <cradek> sebjames: I guess I don't understand - you can set zero anywhere along the axis. homing should give an absolute axis position and let you set the limits of travel of the axis, etc
[15:46:37] <alex_joni> if I understand it right, there are no limits of travel of the axis
[15:46:41] <cradek> homing is setting up the machine's travel, it has nothing to do with the workpiece origin
[15:46:46] <cradek> oh
[15:46:50] <cradek> I must not understand then
[15:47:02] <alex_joni> there is no actual machine moving, but part beeing fed through the machine
[15:47:09] <sebjames> Indeed - no limits of travel, but 0 has to be known
[15:47:12] <alex_joni> and the part can be quite long
[15:47:21] <cradek> ok, interesting
[15:47:22] <sebjames> alex_joni gets it I think
[15:47:23] <alex_joni> sebjames: then you can use some really big numbers in the ini
[15:47:37] <alex_joni> and use the workpiece origin to zero X
[15:47:53] <alex_joni> like skunkworks said
[15:48:04] <sebjames> I have a homing sensor already, which detects the end of the material
[15:48:12] <cradek> but I think you don't want the absolute axis positions to grow forever
[15:48:14] <sebjames> I just need to trigger 0 with that sensor.
[15:48:45] <sebjames> I can always reset the encoder counter with each job, as well, if there is likely to be an overflow problem
[15:49:28] <cradek> well I'm going to back up and say you might want homing
[15:49:29] <cradek> probably not from a gcode though
[15:49:38] <cradek> (wonder if halui can home an axis)
[15:49:52] <sebjames> Hmm.
[15:50:07] <cradek> halui could do it (if it doesn't)
[15:50:19] <sebjames> I really need it to happen from the program. I'm quite sure about that. If I could call a user M code that will initiate the sequence that would be great
[15:50:40] <cradek> will you want the program to run over and over, by itself?
[15:50:59] <alex_joni> cradek: I think halui can do that already
[15:51:06] <cradek> yes it can - I just looked too
[15:51:10] <sebjames> halui.joint.x.home
[15:51:24] <sebjames> Excellent!
[15:51:36] <alex_joni> sebjames: you need an M-code to toggle halui.joint.*.home
[15:51:51] <cradek> you could use classicladder to run your sequencing using halui
[15:52:04] <sebjames> Right.
[15:52:06] <cradek> then you could read any other sensors that would help you load the material, etc
[15:52:08] <sebjames> That's easy now.
[15:52:36] <sebjames> Thanks for all the help guys
[15:52:42] <cradek> or, you could use something like jdi (a script that just runs a program without any interaction)
[15:52:46] <sebjames> It's almost home time for me now.
[15:52:47] <alex_joni> the only problem is that M1xx doesn't hang iirc
[15:53:04] <cradek> (is jdi in cvs?)
[15:53:12] <sebjames> Doesn't hang the excution of the rest of the program you mean?
[15:53:26] <alex_joni> http://axis.unpythonic.net/01167419757
[15:53:35] <cradek> I think emc does wait for M1xx to finish
[15:53:55] <sebjames> ok, well, I'll experiment with this tomorrow.
[15:54:07] <alex_joni> cradek: I'll take your word for it :)
[15:54:11] <cradek> yeah, jdi could easily home too
[15:55:13] <sebjames> halui is useful - I have a few buttons on this machine that I can link to the hal via halui
[15:55:37] <sebjames> I think I need jdi too - we want to run our sequences without mini or tkemc
[15:55:46] <cradek> yes it's quite flexible for making control panels
[15:56:07] <alex_joni> cradek: I don't think it waits for M1xx to finish
[15:56:21] <cradek> I have used halui+ladder to set off sequences from button presses
[15:56:43] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/src/emc/task/emctaskmain.cc?annotate=1.90 line 296
[15:56:57] <cradek> (cycle start button: switch to auto mode, wait for auto mode confirmation, send program run)
[15:57:20] <cradek> you could do a similar thing with home, is-homed, etc
[15:57:51] <alex_joni> cradek: n/m.. I'm beeing obtuse today
[15:58:48] <cradek> see line 2113
[15:59:15] <cradek> err 2287
[16:00:21] <alex_joni> yeah, saw some code about that
[16:00:28] <alex_joni> so I guess it should work :)
[16:00:37] <cradek> you never know, it might
[16:01:15] <alex_joni> haha
[16:02:24] <sebjames> Thanks guys. See you later
[16:02:34] <alex_joni> bye sebjames
[16:02:34] <cradek> bye
[20:00:58] <alex_joni> hrmm.. did anyone try comp?
[20:02:55] <jepler> ??
[20:03:12] <jepler> bin/comp or comp.ko?
[20:03:25] <alex_joni> COMP_FILE = foo.cmp
[20:03:31] <jepler> oh
[20:03:37] <jepler> not me
[20:03:43] <jepler> there are too many "comp"s
[20:05:59] <alex_joni> heh
[20:19:54] <alex_joni> hmm.. it should only be in 2.1.x.. if he's using 2.0.x then compensation is not working
[20:27:48] <skunkworks> jepler: how fast of a period where you able to run the pluto?
[20:27:59] <skunkworks> or have tested?
[20:28:10] <alex_joni> 247 femtoseconds
[20:28:18] <skunkworks> nice
[20:28:24] <skunkworks> ;)
[20:28:37] <jepler> skunkworks: I haven't tried lower than .5ms
[20:28:49] <skunkworks> ok - that seems to be working fine for me.
[20:29:38] <skunkworks> now is there an issue with granularity<- not sure if that is the word - trying to do a velocity pid loop?
[20:30:12] <jepler> beats me
[20:30:13] <alex_joni> sure.. if you have regulation points too far apart (in time) you'll get a bouncy regulation
[20:30:13] <cradek> I think the problem would be getting a good measurement of the velocity
[20:30:21] <alex_joni> but .5ms should be plenty
[20:30:31] <skunkworks> the pluto has a velocity pin..
[20:30:43] <cradek> yeah but that's a crap estimate, because it's only counts/cycle
[20:30:44] <skunkworks> I would think that would be pretty acurite.
[20:30:50] <skunkworks> ah
[20:31:03] <cradek> nope (scope it and see)
[20:31:25] <jepler> the velocity estimate is (pulses per cycle) / (time per cycle)
[20:32:10] <jepler> do some back-of-the-envelope calculations and find out how few pulses per cycle you'll get going at a low speed
[20:33:26] <jepler> e.g., 6000 per inch times 1 inch per minute is .05 pulses per .5ms
[20:34:07] <cradek> seems like you really would need analog tachs (I have no idea how you would read them)
[20:34:40] <skunkworks> hmm - I do have 10 times that (60,960) per inch
[20:34:54] <jepler> OK, that's a half pulse per period
[20:35:06] <skunkworks> at 1 ipm
[20:35:09] <anonimasu> that's tough..
[20:35:37] <anonimasu> you probably need to have it carry over to the next period witht calcs when the speed is slow..
[20:36:30] <skunkworks> have 2 calculations - one for > 10 ipm - one for <=10ipm ;)
[20:36:36] <skunkworks> 2 different periods
[20:36:53] <anonimasu> skunkworks: why not let it carry over?
[20:37:11] <skunkworks> I don't know how to do either ;)
[20:37:22] <anonimasu> hehe
[20:37:23] <anonimasu> ok
[20:37:29] <jepler> of course, .5 counts per period will be tough on touch on position PID as well
[20:37:36] <jepler> er, "tough"
[20:37:44] <jepler> bbl
[20:38:34] <anonimasu> :)
[20:40:03] <jepler> hmm http://z2k.sourceforge.net/
[20:40:05] <jepler> bbl
[20:41:58] <skunkworks> steve would be interested in that I bet.
[21:10:33] <skunkworks> does anyone notice alex goes to bed earlier now that he is married?
[21:10:54] <anonimasu> :D
[21:10:58] <cradek> it is after midnight there I think...
[23:16:55] <skunkworks> I really got emc to hand
[23:16:57] <skunkworks> hang
[23:17:28] <skunkworks> I had closed a terminal that had halcmd open.
[23:18:07] <skunkworks> I have exited axis and the terminal that I had started it from is still acting as if emc is still running.
[23:18:24] <skunkworks> How do I kill it? or is a reboot easier?
[23:24:02] <cradek> the manpage says halrun -U might fix it
[23:24:10] <cradek> but I bet you'll end up rebooting :-)
[23:25:19] <skunkworks> all it says is 'realtime already running'
[23:25:34] <cradek> try /etc/init.d/realtime stop
[23:26:52] <skunkworks> reboot it is ;)
[23:27:23] <skunkworks> I was trying to do a velocity pid loop ;) it was acting odd to say the least.
[23:27:32] <skunkworks> just playing around
[23:49:09] <skunkworks> so - in a velocity loop - you don't use I ?
[23:50:47] <skunkworks> any I value and I get rotation without command