Back
[01:43:07] <cradek> it is not my night!!
[01:43:13] <cradek> anyone have a spare servo motor?
[01:49:33] <cradek> ah forget it! (yayyy!)
[01:50:27] <cradek> but W!T!F!
[01:50:36] <cradek> what kind of wear/failure would cause the motor shaft to get shorter?
[01:51:11] <jmkasunich> what happened?
[01:51:24] <cradek> the back of the pulley dug into the front of the motor and it froze
[01:51:43] <jmkasunich> this is on your bp?
[01:51:51] <cradek> yes
[01:52:04] <jmkasunich> how much clearance was there before?
[01:52:19] <jmkasunich> (are we talking about it moveing a few thou, or a quarter inch?
[01:52:42] <cradek> I wish I new that
[01:53:06] <cradek> it ground .012 off the front of the motor before it finally stuck
[01:53:13] <cradek> so >= .012
[01:53:15] <jmkasunich> how much is the pulley now misaligned with the other pulley?
[01:53:39] <cradek> I haven't put it back on yet
[01:54:02] <jmkasunich> are you sure the pulley didn't just move on the shaft?
[01:54:10] <cradek> it was pretty tight
[01:54:32] <cradek> but I'd definitely like to believe that's what happened
[01:54:39] <jmkasunich> but you don't have any positive evidence, like dirt lines on the shaft or something?
[01:54:45] <cradek> the motor shaft seems short now. It doesn't come up flush with the pulley
[01:55:02] <cradek> I wish I had noticed how long it was before I took it off.
[01:55:06] <cradek> dangitall
[01:55:18] <jmkasunich> what is on the other end of the shaft? encoder or something? if the shaft moved, you'd see it there
[01:55:27] <cradek> yes encoder
[01:55:32] <jmkasunich> (no way it actually got shorter, but maybe it shifted in the bearings
[01:55:48] <cradek> right
[01:56:01] <cradek> you'd think the encoder would fail without too much movement
[01:56:17] <jmkasunich> right
[01:56:47] <jmkasunich> these are brush servos, right?
[01:56:48] <cradek> I could pull a brush... the wear line would be shifted
[01:56:54] <jmkasunich> read my mind
[01:56:55] <cradek> ha, great minds and all that
[01:59:50] <jmkasunich> the only thing worse than cutting sheet steel with a jigsaw is cutting it by hand
[01:59:57] <jmkasunich> and sometimes I'm not even sure about that
[02:01:24] <cradek> if it moved, it didn't move much.
[02:02:07] <jmkasunich> how is the pulley held on the shaft? keyway and setscrew? two setscrews?
[02:02:37] <cradek> that bridgeport collet thing
[02:03:00] <jmkasunich> got me at a loss there
[02:03:12] <cradek> it's a collet
[02:03:22] <jmkasunich> lol
[02:03:26] <cradek> clamps onto the round of the shaft
[02:03:28] <jmkasunich> and a thing
[02:03:30] <cradek> taper inside the pulley
[02:03:34] <jmkasunich> oh, ok
[02:03:43] <cradek> and a thingy to clamp it on the front
[02:03:46] <cradek> very neat actually
[02:03:56] <jmkasunich> bushing that is tapered on the OD and cylinder inside, with a slit (or slits)
[02:04:01] <jmkasunich> and a tapered hole in the pulley
[02:04:09] <cradek> yes
[02:04:16] <cradek> you know, a collet :-)
[02:04:22] <jmkasunich> :-P
[02:04:34] <jmkasunich> those usually don't shitf
[02:04:37] <jmkasunich> ft either
[02:04:44] <cradek> you wouldn't think so.
[02:04:57] <cradek> I would not be able to tell .012 on the brush wear
[02:05:12] <cradek> but I can tell it's not (say) .03
[02:05:18] <jmkasunich> which axis is this?
[02:05:30] <cradek> Y, the easy one to work on
[02:05:47] <jmkasunich> so the motor is down and right, pointing out at your knees
[02:06:06] <cradek> no it's straight down, sticking back under the table
[02:06:17] <jmkasunich> oh, must be thinking of some other machine
[02:06:30] <cradek> this one has both motors underneath which is very nice
[02:06:38] <jmkasunich> the pulley end is pointing at your knees tho
[02:06:43] <cradek> yes
[02:07:15] <jmkasunich> did you remove the motor, or just the pulley?
[02:07:47] <cradek> whole motor
[02:08:02] <jmkasunich> and then the pulley (its not still on there is it?)
[02:08:17] <cradek> I'm putting it back on now
[02:10:27] <cradek> I'm going to assume the pulley moved on the shaft until other evidence shows something more sinister
[02:10:31] <jmkasunich> damn, only I could manage to damage myself with a file
[02:11:26] <cradek> fortunately you're made of auto-regenerating meat
[02:11:42] <jmkasunich> yep
[02:12:07] <cradek> assuming your damage is within the auto-regeneration limitations
[02:12:20] <jmkasunich> it is
[02:12:29] <jmkasunich> just annoying
[02:12:33] <cradek> good
[02:12:41] <cradek> I bet this should be VERY tight
[02:13:03] <cradek> I made a puller to get the pulley off, but it didn't take much pulling.
[02:13:22] <jmkasunich> how is it tightened? three bolts that jack the bushing into the pulley?
[02:13:31] <cradek> yes setscrews
[02:14:26] <jmkasunich> if you backed them off, then all you needed to do with the puller is break the friction grip (like a morse taper)
[02:15:00] <cradek> yeah but when I took them off the first time (a while back) it was very hard
[02:15:19] <cradek> of course they had probably been on for 20+ years
[02:15:33] <jmkasunich> oh, you've had this off before?
[02:15:55] <cradek> yes
[02:16:06] <cradek> which makes it much more likely it was together incorrectly
[03:34:26] <jmkasunich> did you get it back together?
[03:35:08] <cradek> yes, working fine
[03:35:26] <jmkasunich> big sigh of relief?
[03:35:38] <cradek> yeah and back to work... I really want to get Z mounted tonight
[03:44:08] <cradek> yay, the part requiring the 1/4 x 3.5" end mill (of which I had only one) is done
[03:44:32] <cradek> it's like cutting aluminum with jello nailed to a stick
[03:45:00] <cradek> long stick
[03:49:56] <jmkasunich> you designed this part?
[03:50:05] <jmkasunich> why didn't you design something easier to machine?
[03:51:04] <cradek> good question
[03:51:29] <cradek> it sucks because I wanted it made out of one block. that's the real problem.
[03:51:45] <jmkasunich> ah
[03:52:19] <cradek> hard parts are done. now I only have to drill some more holes in the right places.
[03:52:32] <cradek> (haha)
[03:53:03] <jmkasunich> I'm down to my last half-dozen holes
[03:54:23] <cradek> that sounds very promising
[03:55:49] <jmkasunich> I decided to rebuild the PC mount, so it could use a standard mobo
[03:56:07] <jmkasunich> so there's no way I'll be moving things today, but I think I'll get the PC mounted in the boc
[03:56:08] <jmkasunich> x
[04:16:38] <cradek> that sounds like a nice accomplishment anyway
[04:18:09] <jmkasunich> everything cut and drilled, time for rivets
[04:44:47] <jmkasunich> case built, nothing in it yet
[04:56:38] <jmkasunich> arrgh
[04:57:11] <jmkasunich> one of the holes I want to mount it in the main box with is blocked now that I've riveted it together
[05:12:04] <jmkasunich> I don't fricking believe this
[05:12:23] <jmkasunich> the power supply hole patteren in this back panel doesn't clear the plug on my ps
[05:12:37] <jmkasunich> I thought those cutouts were standard
[05:12:51] <jmkasunich> the fan lines up, the screws line up, just can't plug the line cord in
[05:34:46] <jmk-st> well, the computer is in the new "case"
[05:34:52] <jmk-st> but the case isn't in the main box yet
[05:35:04] <jmk-st> and I'm fading fast
[05:35:08] <cradek> me too
[05:35:23] <jmk-st> how is your part going?
[05:35:29] <cradek> done! it's even upright
[05:35:41] <jmk-st> photo?
[05:35:43] <cradek> within about .002/foot
[05:35:47] <cradek> maybe tomorrow
[05:36:18] <cradek> I have to drill and tap 4 holes on the existing base and XYZB is done - only C to go
[05:37:23] <cradek> sucks about your holes
[05:37:36] <cradek> you'd think we'd have standard holes for motherboards and power supplies in 2007
[05:37:41] <jmkasunich> yeah
[05:37:57] <jmkasunich> I fixed that - took everything out, jigsaw and file, put it back together
[05:37:59] <jmkasunich> just annoying
[05:38:10] <jmkasunich> pics in a minute
[05:41:46] <jmkasunich> http://jmkasunich.com/pics/case-front-IMGP1751.JPG
[05:41:54] <jmkasunich> http://jmkasunich.com/pics/case-back-IMGP1754.JPG
[05:42:14] <jmkasunich> quite nice I think
[05:42:40] <cradek> yes very nice!
[05:42:55] <cradek> your yearly power supply replacement will be very easy now
[05:42:57] <jmkasunich> the side with the slots will be on top when I mount it in the box
[05:43:39] <jmkasunich> I hope so
[05:43:50] <jmkasunich> the next supply will probably have the plug somewhere else
[05:44:59] <cradek> heh
[05:45:06] <cradek> you'll just have to shop around
[05:45:43] <jmkasunich> or jigsaw and file some more ;-)
[05:46:13] <cradek> eventually any power supply will fit, or else they'll all fall through the hole
[05:46:25] <jmkasunich> yeah
[05:46:39] <jmkasunich> I have a large pile of shrapnel laying around the bandsaw
[05:46:56] <jmkasunich> this started out as a full tower gateway system
[05:47:20] <cradek> haha
[05:47:21] <jmkasunich> now its only 14 x 10-3/4 x 8-1/2
[05:48:27] <jmkasunich> well, the dog expects me to walk him before bed
[05:48:29] <jmkasunich> time to go
[05:48:33] <jmkasunich> goodnight
[05:49:12] <cradek> goodnight
[12:28:37] <tissf> hi
[13:02:28] <alex_joni> hello
[13:16:33] <jepler> good morning
[13:17:06] <jepler> tissf: if you have tested the link checker for the v2_2_branch and think it will help you, please go ahead and check it in.
[13:17:11] <jepler> sorry I didn't answer you before now.
[13:25:25] <skunkworks_> logger_dev: bookmark
[13:25:25] <skunkworks_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-12-10.txt
[14:14:24] <jepler> tissf: I notice that in the 2.2 documentation you have included g38.3,4,5 (LOGOPEN) (LOGCLOSE) and other items that are new features in TRUNK and not present in emc 2.2.
[14:15:49] <tissf> jepler: I removed?
[14:16:32] <jepler> you should remove them. (and I don't know if that's a full list of the items that should be removed -- just the ones I noticed right away)
[14:18:06] <jepler> the only other thing I see that is added in the english TRUNK version is G73, but I don't think you have that yet
[14:18:38] <tissf> jepler:ok
[14:19:45] <tissf> jepler: corrected for next commit
[14:20:28] <jepler> thank you!
[14:21:00] <tissf> jepler: no problem
[14:34:51] <CIA-42> EMC: 03tissf 07v2_2_branch * 10emc2/docs/html/gcode_fr.html: French translation removed G38.3,4,5 (LOGOPEN)(LOGCLOSE)
[14:34:52] <CIA-42> EMC: 03tissf 07v2_2_branch * 10emc2/docs/src/gcode/main_fr.lyx: French translation removed G38.3,4,5 (LOGOPEN)(LOGCLOSE)
[15:29:06] <jepler> I am getting demoralized by all the problem reports in stepconf
[15:32:37] <SWPadnos> have a cookie :)
[15:32:45] <SWPadnos> homemade, you bastard
[15:33:13] <cradek> meanie
[15:33:18] <SWPadnos> heh
[15:33:28] <SWPadnos> all I had was taht damned snickers bar
[15:33:35] <SWPadnos> and it wasn't even one of the dark chocolate ones
[15:35:06] <SWPadnos> jepler, do you have more reports that people have emailed you directly, or is it just the few on the users list?
[15:36:52] <jepler> the other day someone had brought some hershey's kisses to the office. damn if that isn't terrible chocolate. so I ate it anyway.
[15:36:59] <SWPadnos> heh
[15:37:00] <jepler> I am such stupid meat
[15:37:06] <SWPadnos> when in rome or something
[15:37:14] <jepler> SWPadnos: no, those are the only reports I have
[15:37:33] <SWPadnos> ok, it sounds like 3 or 4 then, not a lot
[15:38:32] <SWPadnos> it's a hard thing - making software that can tell when it needs to change from GIGO mode to GINO (garbage in, no output) mode
[15:46:03] <jepler> jmkasunich has a good point about BASE_PERIOD, but how do I choose one that is "low enough"?
[15:46:27] <jepler> I actually used 100000 as base_period on zenbot and I don't think I suffered any ill effects .. not that I've seriously used that machine yet
[15:47:18] <cradek> I thought we found all machines could run 25000. why not just make that the max?
[15:47:33] <cradek> I know that doesn't answer your question of course
[15:50:08] <jepler> the other thing I need is a rule for when to not enable doublestep .. I lean towards thinking it should only be disabled when the timings present a problem (e.g., 25000ns step time) while jmk seems to lean towards enabling it only when needed to obtain the requested step rate
[15:51:37] <cradek> if it's not needed to obtain the requested step rate is there another advantage to using doublestep?
[15:52:26] <jepler> not really
[15:52:35] <jepler> stepconf always uses it because having one "case" to generate is easier than two
[15:52:43] <cradek> sure
[15:53:39] <cradek> to configure it, you need more precise knowledge of the hardware. that seems like a drawback if you aren't getting some other benefit
[15:54:05] <jepler> true enough
[16:14:36] <SWPadnos> I think I'd lean toward using doublestep only when necessary
[16:15:11] <SWPadnos> stepconf actually loads the RT system and allows you to do a latency test, right? (or does the test automagically?)
[16:24:00] <jepler> no, it requires you to write down the number
[16:24:56] <SWPadnos> ok, but does it allow you to run the test from within stepconf?
[16:26:54] <SWPadnos> I guess I could boot up an EMC2-capable computer and look for myself :)
[16:36:25] <jepler> I added the button either in TRUNK or in a working tree that I haven't committed yet
[16:36:39] <jepler> you have to run latency-test separately in 2.2, and manually write the number in the appropriate field
[16:36:44] <SWPadnos> ok
[16:37:36] <SWPadnos> I was wondering because it would be possible to run the latency test twice, with different base periods, and try to figure out the fastest it should be set (more or less)
[16:38:18] <SWPadnos> though that's a pain, because you have to start/stop the RT system 2 or 3 times
[16:45:04] <jepler> looks like adding a call to interp.close() in gcodemodule.cc may fix it
[16:45:33] <cradek> cool
[16:45:41] <SWPadnos> cool
[16:45:45] <cradek> that may fix a whole class of possible bugs?
[16:46:19] <jepler> maybe
[16:49:20] <cradek> maybe you should put it on the 2.1 branch too
[16:49:50] <jepler> are we going to build another 2.1 ever?
[16:49:53] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/src/emc/rs274ngc/gcodemodule.cc: make 'touch off' work when the loaded file uses percent signs
[16:50:05] <jepler> there are a few other fixes there iirc
[16:50:22] <SWPadnos> hmmm. how does the interp handle parsing errors? especially when it's called from the touch-off dialog
[16:51:03] <cradek> jepler: we sure could...
[16:51:14] <cradek> although I know that's not what you asked
[16:51:48] <SWPadnos> if there are relevant bug fixes, it might be nice. 2.1 runs on breezy, doesn't it?
[16:51:56] <cradek> yes
[16:52:10] <jepler> SWPadnos: it uses the embedded interpreter to check that the expression is valid, and also to compute its actual value to show to the user
[16:52:31] <SWPadnos> ok, so it would be nice (though I'm not pushing, since I'm not the one doing the work) to keep releasing 2.1 until it becomes terribly annoying
[16:52:41] <jepler> SWPadnos: basically, it does an MDI M199 P[expression] in the embedded interpreter, then looks at the value that was passed to the custom M code
[16:53:09] <SWPadnos> jepler, right. I guess I'm wondering whether there's something that makes certain errors "sticky"
[16:53:39] <SWPadnos> when you'd normally get an error dialog and dismiss it (in the course of a g-code run)
[16:54:46] <jepler> in theory, interp::reset and interp::close (which calls interp::reset) clear those flags. but I wasn't calling interp::close when I was done reading a part program for preview. In that case, the percent flag was sticking and causing the problem I saw.
[16:55:35] <SWPadnos> oh - sorry, I was thinking of the "invalid number" errors - I didn't make that clear
[16:56:19] <CIA-42> EMC: 03jepler 07v2_2_branch * 10emc2/src/emc/rs274ngc/gcodemodule.cc: merge from TRUNK: make 'touch off' work when the loaded file uses percent signs
[16:56:44] <CIA-42> EMC: 03jepler 07v2_1_branch * 10emc2/src/emc/rs274ngc/gcodemodule.cc: merge from TRUNK: make 'touch off' work when the loaded file uses percent signs
[16:57:13] <cradek> yay
[16:57:16] <CIA-42> EMC: 03jepler 07v2_1_branch * 10emc2/debian/changelog: note new fix
[16:57:42] <CIA-42> EMC: 03jepler 07v2_2_branch * 10emc2/debian/changelog: note new fix
[16:58:28] <jepler> SWPadnos: I don't know why "invalid number" errors would stick, but it's possible that calling .close() would unstick that too
[16:58:32] <jepler> * jepler shrugs
[17:00:42] <SWPadnos> I hope it works out that way :)
[17:01:47] <cradek> too bad we don't have jack's gcode.
[17:02:31] <SWPadnos> what happens if there's an M199 script on the system?
[17:02:43] <SWPadnos> does it actually run, or is that hijacked somewhere?
[17:02:51] <jepler> SWPadnos: no, it's thoroughly hijacked
[17:03:03] <SWPadnos> ok (I figured you'd have thought of that :) )
[17:03:19] <jepler> the interpreter only makes a certain canon call when M1xx is encountered; in task, this leads to a call to the external program during program execution. in axis, it doesn't.
[18:59:56] <CIA-42> EMC: 03tissf 07TRUNK * 10emc2/docs/src/ (Master_HAL_fr.lyx Submakefile index.tmpl index_fr.tmpl): French translation
[18:59:56] <CIA-42> EMC: 03tissf 07TRUNK * 10emc2/docs/src/hal/rtcomps_fr.lyx: French translation
[19:23:00] <seb_kuzminsky> ok hello
[19:23:02] <SWPadnos> hello again :)
[19:23:11] <cradek> we try to keep it less technical in #emc so new users aren't scared to ask more basic questions
[19:23:21] <seb_kuzminsky> right... makes sense
[19:23:31] <cradek> I looked through your patch and everything looks good to me, but I'm not an expert on drivers
[19:23:39] <seb_kuzminsky> great!
[19:23:46] <cradek> is that zip file something that comes from peter w?
[19:24:02] <seb_kuzminsky> yep, that's all his vhdl code
[19:24:11] <cradek> I think the patch didn't include the zip because it is binary
[19:24:28] <cradek> is there a gpl statement in his code?
[19:24:43] <seb_kuzminsky> oops!
[19:24:53] <SWPadnos> not that I've seen, but he seems OK with adding them (in general)
[19:25:05] <cradek> yes I think last time we only had to ask him and he added it
[19:25:12] <seb_kuzminsky> there is no copyright statement or license statement, but i have an email from pcw saying he wants to release it dual licensed, bsd & gpl
[19:25:39] <cradek> it would be nice if he would add that statement to the files for us
[19:25:44] <seb_kuzminsky> the zip file isn't needed to build, but I'll add it anyway
[19:25:52] <jepler> yes it is important that each source file have a notice that the file is available under the GPL v2
[19:25:55] <seb_kuzminsky> i'll ask him to put it in there (or offer to do it for him)
[19:26:15] <cradek> I think he (the author) should do it
[19:26:25] <seb_kuzminsky> yes you're right
[19:26:29] <jepler> verilog source files are just the same as C/C++ source files
[19:28:52] <jepler> aside from this issue of the firmware license, I don't see any problems with including this driver in a future release
[19:29:19] <seb_kuzminsky> I just emailed pcw asking him to add the copyright and the GPLv2 license
[19:29:55] <seb_kuzminsky> AFter he does that I'll update the driver and release 0.5
[19:30:02] <cradek> seb_kuzminsky: I will add you as a cvs committer, so when the license thing is worked out you can go ahead
[19:30:08] <seb_kuzminsky> thanks!
[19:30:13] <cradek> what is your sourceforge login?
[19:30:25] <jepler> when you eventually add the verilog source code to the emc2 source tree, it should be as individual .v (or whatever extension) files, not as a .zip file
[19:30:51] <jepler> that way, if the individual files are revised, cvs will help track the revisions
[19:31:39] <seb_kuzminsky> jepler: i agree, i'll do that for the next version
[19:32:04] <seb_kuzminsky> chris: i had one a long time ago but it looks like it's expired, i can make a new one if you really need it
[19:32:44] <cradek> all of the project except cvs is hosted on sf - the bug tracker and mailing lists
[19:33:35] <cradek> I think everyone else has a sf id so they can be added to the project there. it would be nice if you did too
[19:34:30] <cradek> is skuzminsky ok for a login?
[19:34:51] <cradek> it's nice, but not required, that they match on cvs and sf
[19:36:39] <seb_kuzminsky> I prefer "seb" if it's all the same to you. Hm, it looks like y'all's standardized on that pattern though so if you like i'll conform
[19:36:55] <fenn> ffff
[19:36:59] <seb_kuzminsky> Peter Wallace asks if it's ok if he just includes a comment in the vhdl with a pointer to the license file?
[19:38:05] <SWPadnos> I think a few line comment saying that he's the author and that he's releasing it under the GPLv2 would be sufficient. there may need to be a pointer to fsf.org or something, but the requirements are pretty small
[19:38:09] <jepler> seb_kuzminsky: it should be the standard block shown in the GPL in the section "How to Apply These Terms to Your New Programs".
[19:38:24] <cradek> we can use 'seb', no problem
[19:39:12] <jepler> we have an occasional troll who likes to claim that there are (usually unspecified) "license problems" in the software; by not including the entire block, it gives the troll something new to troll about.
[19:39:37] <SWPadnos> hmmm. is the license block in this sufficient?
http://cvs.linuxcnc.org/cvs/emc2/src/hal/components/blocks.c?rev=1.26
[19:40:05] <SWPadnos> it doesn't have any pointers to the full GPL, though it does list the author, a claim of copyright, and the GPL as the license
[19:40:58] <cradek> seb_kuzminsky: you should be able to get a developer checkout now
[19:41:34] <fenn> maybe we should make emc output a "short notice" and force the user to type "yes, i understand" every time they run the program
[19:41:44] <jepler> SWPadnos: let me put it this way: I wouldn't turn down a patch that makes the author's intent to GPL the software more clear.
[19:41:51] <SWPadnos> heh
[19:41:55] <cradek> seb_kuzminsky: (fenn isn't the usual troll)
[19:42:05] <fenn> just today
[19:42:14] <cradek> we all have our days
[19:42:22] <SWPadnos> I'm just not too familiar with the marking requirements of the GPL
[19:42:29] <fenn> i blame cairo's lack of an arc_to command
[19:44:33] <seb_kuzminsky> ok, "seb" and "skuzminsky" were both taken, i'm seb_kuzminsky at sf.net now.
[19:45:01] <jepler> SWPadnos: According to the license itself, it applies to any "work which contains a notice placed by the copyright holder saying that it may be distributed under the terms of this General Public License". The "How to Apply" section is what standards people call "non-normative"
[19:45:04] <cradek> ok I will add you to the project there too.
[19:45:34] <cradek> if you can, try your cvs access while we're both around
[19:46:07] <seb_kuzminsky> I've been doing anon cvs checkouts for a few months, i'll try developer now, hold on
[19:46:09] <SWPadnos> jepler, err. I understood up until the non-normative part :)
[19:47:03] <fenn> http://en.wikipedia.org/wiki/Normative
[19:48:16] <fenn> so i guess that means you can put a license block in if you want to, but it doesn't really matter
[19:48:59] <cradek> Dec 10 13:48:48 cvs sshd[57976]: Accepted publickey for seb
[19:49:06] <seb_kuzminsky> chris: yes it looks like its working :-)
[19:49:24] <cradek> we are done. welcome to the team
[19:49:34] <seb_kuzminsky> thanks!
[19:49:53] <seb_kuzminsky> I'll be hacking on the 7i43 driver, hoping to add hostmot2 in the next month or so
[19:50:08] <seb_kuzminsky> i prolly wont get too deep into the rest of the code at this point
[19:50:10] <SWPadnos> hmmm. I never got around to ordering a few of those
[19:50:29] <cradek> that's ok, work on whatever part you like.
[19:50:54] <seb_kuzminsky> of course :-)
[19:52:11] <seb_kuzminsky> ah one thing i had been thinking about is an internal parport infrastructure in rtai/hal like linux has
[19:52:39] <seb_kuzminsky> seems like there's a couple of implemetations of epp i/o in src/hal/drivers, maybe unify & abstract that
[19:53:52] <seb_kuzminsky> may not be worth it...
[19:54:23] <fenn> i think it's worth it
[19:54:43] <seb_kuzminsky> i've also been talking to pcw about writing yet another driver for the 5i2x cards...
[19:54:53] <fenn> epp/parport is basically the only commonly available rt interface to custom hardware (unless you go with a pci card)
[19:55:47] <fenn> there's bound to be more drivers that use epp
[19:57:46] <SWPadnos> have you looked at the work that's been done on the new 5i2x driver infrastructure?
[19:59:10] <fenn> epp is 32 bit, so you could have an epp-parport hal driver with u32 signals in/out of it (perhaps a useless idea)
[19:59:46] <SWPadnos> I don't think you can abstract it at that level - there's no guarantee that a single 32-bit address contains a single piece of HAL data
[19:59:57] <SWPadnos> or that you can individually read/write all the addresses
[20:00:10] <SWPadnos> or that the addresses mean the same thing when read vs. written ...
[20:00:17] <fenn> not the address, it sends 32 bits per transfer
[20:00:44] <seb_kuzminsky> swpadnos: the 5i2x infrastructure is the stuff in src/hal/drivers/mesa_5i2x?
[20:01:03] <SWPadnos> seb_kuzminsky, yes, I think it's there. there's a separate CVS branch for it as well
[20:01:13] <seb_kuzminsky> fenn: is that true? i thought the epp spec required only 8 bits, and the 16- and 32-bit extensions were optional or non-standard (though very widely supported)
[20:01:55] <fenn> uh, well epp is rather useless if you're only sending 8 bits
[20:02:17] <SWPadnos> no, it allows you to use a single CPU I/O instruction instead of 3 or more
[20:02:26] <seb_kuzminsky> i disagree, the hardware-supported interlocking handshaking of epp is excellent even for 8 bit transfers
[20:02:30] <SWPadnos> the handshake is done in hardware instead of polling in software
[20:04:09] <fenn> ok, but if you're only sending 8 bits, using a 32 bit hal signal should still work
[20:04:28] <fenn> there would be some param to select 8,16,32
[20:05:17] <SWPadnos> the trouble is that different hardware may have different packing for data, and may have different setup that needs to be done before starting a read or write cycle
[20:05:37] <fenn> all the better to have that in one place
[20:05:40] <jepler> when you look at the epp signals, it doesn't differentiate between 8- 16- or 32-bit transfers; they're just sequential byte transfers.
[20:05:56] <jepler> some existing epp hardware is oriented around 24-bit words (pico)
[20:07:17] <jepler> but now that we have several drivers to look at (pico, pluto, mesa) we have a pretty good idea of the variations
[20:08:02] <SWPadnos> yeah - I think it would be great to have a single library at least, and a single kernel module at best
[20:08:05] <jepler> personally, I saw a library more than a series of HAL pins or parameters, so I pulled out some routines into "pluto_common.h" -- it wasn't abstract enough to be used in the mesa driver, though.
[20:08:36] <seb_kuzminsky> an epp abstraction would need methods something like this: init(), check_timeout(), clear_timeout(), write_addr(), read_data(), and write_data()
[20:08:46] <jepler> the code is small, it's unlikely to have more than one copy loaded in a running system anyway, and we have poor support for (un)loading non-HAL modules, so using a "header" file seemed pretty natural
[20:09:20] <seb_kuzminsky> with a parport_t struct to keep everythign neat & organized
[20:09:37] <seb_kuzminsky> basically ripping off the parport architecture in linux
[20:09:38] <SWPadnos> init() and cleanup() would probably need to be callbacks
[20:09:59] <SWPadnos> though I should look at the relevant code befor emaking such a statement
[20:10:05] <fenn> are you saying it's unlikely to have more than one epp-parport being used in the same machine?
[20:10:27] <seb_kuzminsky> fenn: not at all, i plan to support multiple 7i43 boards in a single system RSN
[20:10:37] <SWPadnos> more than one parport-connected device would be somewhat odd, but not outside the realm of possibility
[20:10:40] <jepler> fenn: I think it would be odd to mix & match one pluto and one mesa (for example)
[20:10:45] <SWPadnos> err - more than one type of device, that is
[20:11:03] <jepler> out of laziness, the pluto driver only supports one device as well
[20:11:29] <jepler> seb_kuzminsky: happen to know if 7i33 can have more than one device per epp bus, like pico?
[20:11:40] <jepler> it presents a problem for firmware uploading, that's for sure
[20:18:19] <seb_kuzminsky> jepler: the current 7i43 supports only one device per parport afaik :-(
[20:18:28] <seb_kuzminsky> but parports are only like $15 at frys
[20:19:13] <SWPadnos> and there are apparently PCIe parallel port cards now ...
[20:22:13] <seb_kuzminsky> jepler: the 7i43 has a cpld talk to the parport when the fpga is not initialized, so that's potentially a place to multiplex boards
[20:25:22] <seb_kuzminsky> aight, i'mma go do some of the work that actually pays, see you all later
[20:42:56] <CIA-42> EMC: 03tissf 07v2_2_branch * 10emc2/docs/src/ (Master_HAL_fr.lyx Submakefile index.tmpl index_fr.tmpl): French translation
[20:42:56] <CIA-42> EMC: 03tissf 07v2_2_branch * 10emc2/docs/src/hal/rtcomps_fr.lyx: French translation
[23:03:45] <CIA-42> EMC: 03tissf 07TRUNK * 10emc2/docs/src/ (4 files): French translation
[23:03:46] <CIA-42> EMC: 03tissf 07TRUNK * 10emc2/docs/src/ladder/ladder_intro_fr.lyx: French translation
[23:05:09] <tissf> good night all
