Back
[00:39:17] <fenn_> fenn_ is now known as fenn
[00:52:35] <samco> samco is now known as skunkworks
[17:54:37] <alex_joni> cradek: when you'll have 4-5 minutes.. can you check if I used tpAbort() how I should..
[17:57:21] <cradek> where do I look?
[17:57:34] <cradek> oh I see, motion.c
[17:57:45] <cradek> control.c
[17:58:41] <alex_joni> control.c, but check the diff from the commit mail
[18:01:44] <cradek> that seems right
[18:01:52] <cradek> you want a jog to stop if the probe touches?
[18:02:30] <alex_joni> yeah
[18:02:42] <alex_joni> and an motion abort
[18:03:01] <alex_joni> reading through the code I noticed something strange..
[18:03:39] <cradek> since you have to decel after the probe touches, you're not going to stop where you want
[18:04:05] <alex_joni> MOTION_TYPE is one of (traverse, feed, arc, toolchange), and it might end up in tp like one of these..
[18:04:15] <alex_joni> I know.. I remember the position when it hits
[18:04:59] <cradek> yuck I wonder what happened to the commit list
[18:14:02] <cradek> so does probing work now with just that one change?
[18:15:24] <alex_joni> I think so..
[18:15:34] <alex_joni> it does work for me.. but I never used probing before...
[18:15:35] <cradek> that's great
[18:15:53] <alex_joni> I'll try to revive some tcl script from emc1 and see
[18:15:54] <cradek> some day we should work on fixing synchronized digital IO too
[18:16:02] <alex_joni> that does work
[18:16:08] <alex_joni> I fixed it quite a while ago
[18:16:13] <cradek> really?
[18:16:14] <alex_joni> M65 & co..
[18:16:16] <cradek> since the new tp?
[18:16:17] <alex_joni> yeah
[18:16:25] <alex_joni> hmm.. does it matter?
[18:16:31] <cradek> probably :-)
[18:16:37] <alex_joni> I mean.. I thought you moved the stuff along
[18:16:42] <cradek> umm
[18:16:49] <cradek> like I said, some day we should work on fixing synchronized digital IO too
[18:16:54] <alex_joni> lol
[18:28:04] <jepler> If I'm issuing a sequence of outb/inb instructions to the parallel port, without any timing in between, how fast will they go?
[18:28:33] <jepler> conversely, is there any function in rtapi to delay a very short time, on the order of 25ns?
[18:28:49] <alex_joni> asm nop; ?
[18:29:09] <alex_joni> I think the outb/inb to ISA take about 1 usec
[18:29:38] <jepler> will that rule also hold for a parallel port on a PCI card?
[18:29:40] <jepler> (1 usec)
[18:30:12] <alex_joni> I think so..
[18:30:26] <alex_joni> I have a 2port PCI parport card
[18:30:31] <alex_joni> and it isn't any faster
[18:30:52] <alex_joni> I think it actually has some 82c.. (forgot which one the parport is) inside
[18:31:49] <cradek> a few ins and outs would take up a lot of a base period then
[18:32:02] <jepler> I'm looking at expanding the number of inputs by using two 74xx157s to multiplex 10 inputs onto the 5 input pins
[18:33:08] <jepler> so I would OUT (some of the outputs and the input select bit), IN (the first half of the input), OUT (inverted select bit), IN (the second half of the input)
[18:34:06] <alex_joni> sounds pretty ok..
[18:34:21] <alex_joni> but BASE_PERIOD should go up a bit (15-20 should be safe)
[19:10:36] <alex_joni> cradek: one question about tpAddLine
[19:10:44] <alex_joni> I see the PROBE stuff uses it:
[19:10:50] <alex_joni> if (-1 == tpAddLine(&emcmotDebug->queue, emcmotCommand->pos, emcmotCommand->motion_type)) {
[19:11:05] <cradek> ok
[19:11:19] <alex_joni> now.. the motion_type in there might be some weird value
[19:11:21] <alex_joni> let me find it
[19:11:39] <cradek> tpAddLine has a different prototype now
[19:11:44] <cradek> that code must not work
[19:12:38] <alex_joni> well.. it kinda does!?
[19:13:00] <alex_joni> I just snooped over it.. motion_type is not initialized to some sane value
[19:13:30] <cradek> I can't find the defines
[19:13:37] <cradek> I intended there to be a motion type specifically for probing
[19:13:37] <alex_joni> what defines?
[19:13:48] <alex_joni> ahh.. they are in emc.hh ;)
[19:13:49] <cradek> of the motion types
[19:13:50] <alex_joni> nicely hidden
[19:14:06] <alex_joni> #define EMC_MOTION_TYPE_TRAVERSE 1
[19:14:07] <alex_joni> #define EMC_MOTION_TYPE_FEED 2
[19:14:07] <alex_joni> #define EMC_MOTION_TYPE_ARC 3
[19:14:07] <alex_joni> #define EMC_MOTION_TYPE_TOOLCHANGE 4
[19:14:14] <cradek> yeah that's it
[19:14:15] <alex_joni> nothing regarding probing though
[19:14:21] <cradek> make a new one then
[19:14:32] <alex_joni> think it's needed?
[19:14:42] <alex_joni> FEED should be OK imo
[19:14:42] <cradek> sure why not?
[19:14:51] <cradek> those are used to give the user more info in the gui
[19:14:56] <cradek> there's no reason not to add it
[19:15:15] <cradek> I think it's a very different operation from feed/traverse
[19:15:28] <alex_joni> ok, I'll add it..
[19:15:34] <alex_joni> can you check the TP part of it?
[19:15:37] <alex_joni> even later..
[19:15:51] <cradek> I'm worried about your tpAddLine call, it's very wrong
[19:16:01] <cradek> I bet jepler didn't fix probing when he changed the tp api
[19:16:21] <jepler> no, I didn't touch probing
[19:16:24] <alex_joni> it was there already
[19:16:27] <cradek> now vel and accel are set in that one call
[19:16:35] <alex_joni> oops ;)
[19:16:59] <cradek> * cradek goes to get some tea while you two decide who has to fix it :-)
[19:17:08] <jepler> I was pretty sure probing was broken so I left the code alone
[19:17:13] <jepler> ooh tea
[19:17:26] <cradek> haha
[19:17:33] <alex_joni> * alex_joni is busy hacking NML & canon
[19:44:49] <alex_joni> jepler: it seems you did change the tpAddLine call
[19:45:10] <alex_joni> I just changed the stuff above it (NML & taskintf & canon)
[19:52:33] <alex_joni> cradek: you sure nothing happened to the commit script?
[19:52:40] <alex_joni> both CIA and the commit list are icky..
[20:01:31] <cradek> I didn't change anything
[20:04:28] <jepler> I made a commit to axis earlier, and cia didn't say anything about it
[20:04:47] <alex_joni> CIA is getting lazy
[20:04:52] <alex_joni> maybe we should switch to NSA
[20:05:38] <cradek> Subject: Your message to Emc-commit awaits moderator approval
[20:05:41] <cradek> The reason it is being held:
[20:05:45] <cradek> Too many recipients to the message
[20:06:04] <cradek> seems sf and cia have two separate problems
[20:06:11] <jepler> how many recipients would that be?
[20:06:17] <cradek> 1
[20:06:37] <cradek> well I don't know how many are subscribed to the list if that's what it means
[20:06:47] <cradek> but that's a stupid restriction for a mailing list
[20:07:59] <cradek> Jun 1 14:55:04 cvs sm-mta[83275]: k51Jt3Ia083273: to=<cia@cia.navi.cx>, ctladdr=<cvs-adm@cvs.linuxcnc.org> (1002/1002), delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=30598, relay=cia.navi.cx. [69.90.211.97], dsn=2.0.0, stat=Sent (Ok: queued as 729561D8004)
[20:08:09] <cradek> here's cia accepting the message
[20:08:27] <alex_joni> odd..
[20:15:57] <jepler> As of 2006-06-01 at 09:00 Pacific, Subversion (SVN) service is down for unplanned maintenance of unknown duration.
[20:16:01] <jepler> </sourceforge>
[20:16:30] <cradek> yeah but cvs is working now
[20:17:26] <jepler> s/now/for now/
[20:17:47] <cradek> right
[20:17:53] <cradek> wonder what they've done to the mailing lists
[20:18:25] <jepler> As of 2006-05-26 the migration of Mailing Lists to the new infrastructure has begun. Until complete (we'll update the site status when it is), list creation may be disabled and temporary downtimes may occur, and are anticipated. Mail, however, won't be lost. </sourceforge>
[20:19:12] <cradek> so they are messing with it
[20:20:52] <jepler> yeah I guess so
[23:40:53] <jmkasunich> hi filks
[23:41:18] <jmkasunich> cradek, whats this I hear about your motor being busted until you spat on it?
[23:47:33] <cradek> hi jmk
[23:47:57] <cradek> one of the encoders was bogus until I disassembled and reassembled it
[23:48:11] <cradek> unfortunately we started testing with that one so we figured it was our code or circuitry
[23:49:03] <cradek> jepler got it to sample at 450? kHz so it will work great
[23:49:06] <jmkasunich> any idea what was actually wrong with it?
[23:49:18] <jmkasunich> wow, 3 channels at 450KHz?
[23:49:42] <cradek> yes 3 channels
[23:49:49] <jmkasunich> pretty impressive
[23:50:00] <jmkasunich> something like 33-35 clocks
[23:50:21] <cradek> yes I think it was something like that
[23:50:30] <jmkasunich> btw, found an encoder connector that matches your encoder
[23:50:31] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/qq2.S
[23:50:43] <cradek> I suspect the encoder was either misaligned or dirty
[23:50:45] <jepler> I think this source matches what we programmed into the avr: ^^
[23:50:48] <jmkasunich> now I just have to pack and ship
[23:50:52] <cradek> it would count right one way but screwy the other
[23:51:06] <cradek> jmkasunich: slick, that's great, hopefully I'll need it soon
[23:51:38] <jepler> bbl
[23:51:47] <jmkasunich> trying to remember what else I was going to send you
[23:51:57] <jmkasunich> remembered
[23:52:04] <jmkasunich> connector, nutdriver, jogwheel
[23:52:58] <cradek> darn, seemed like there were 3 things without the nutdriver
[23:53:23] <cradek> maybe not, I can't think of anything else
[23:53:25] <jmkasunich> senility is kicking in
[23:53:29] <cradek> me too
[23:53:39] <jmkasunich> I seem to recall something else, but damned if I can remember
[23:53:46] <cradek> we'll think of it
[23:53:54] <jmkasunich> right after I mail the package
[23:53:59] <cradek> probably
[23:54:32] <cradek> do you want a copy of this board as-is or do you want to make some custom changes first?
[23:54:39] <jmkasunich> I dunno
[23:54:48] <jmkasunich> its not real high on my priority list to be honest
[23:54:50] <cradek> I assume you want the encoder dividers too
[23:54:55] <cradek> I understand
[23:55:05] <jmkasunich> hold off for a while
[23:55:06] <cradek> it's not so interesting if you don't plan to run a machine with it
[23:55:32] <cradek> it's very interesting to me because of that
[23:55:37] <jmkasunich> right
[23:56:24] <jmkasunich> I'm back on the PWM component (after IRC distraction Tues and not being around yesterday)
[23:56:30] <cradek> great
[23:56:41] <cradek> I'll definitely use it when you get it done
[23:56:46] <jmkasunich> hopefully I'll commit something tonight
[23:57:41] <jmkasunich> I think I have a PWM algorithm that can do three kinds of PWM/PDM
[23:57:57] <jmkasunich> pure PWM (fixed period and fixed on time for any given command)
[23:58:05] <jmkasunich> that has the problem of low resolution
[23:58:44] <jmkasunich> "jittery" PWM (fixed period, on time alternates between adjacent values to maintain the proper output over the long term)
[23:59:09] <jmkasunich> and PDM (pulse density modulation) like the existing freqgen type 1
[23:59:37] <cradek> I haven't heard anyone ask for pure pwm, is there some time it's needed?
[23:59:44] <cradek> it seems pdm is superior in every way