Back
[00:39:43] <Unit41> HAL:1: ERROR: Can't find program 'hal_manualtoolchange'
[00:41:31] <Unit41> i'll wait for my new laptop and put ubuntu on it
[00:41:40] <Unit41> that should help
[00:42:00] <Unit41> cya in a week! :P
[01:45:12] <Guest211> Guest211 is now known as skunkworks
[01:46:37] <jmkasunich_> jmkasunich_ is now known as jmkasunich
[07:06:11] <fenn> vim and all the kde stuff do automatic syntax hilighting for .ini files - what doesn't?
[13:01:57] <fenn> alex_joni: i copied this
http://www.linuxcnc.org/docs/devel/html/config/emc2hal/index.html
[13:02:11] <fenn> to a real man page
http://www.linuxcnc.org/docs/devel/html/man/man9/motion.9.html
[13:02:22] <fenn> and
http://www.linuxcnc.org/docs/devel/html/man/man9/iocontrol.9.html
[13:03:00] <fenn> i think it makes more sense as a man page, and it's still available online so a google search will find it
[13:03:28] <fenn> can i delete that section from the pdf manual so it's not getting out of sync?
[13:06:13] <alex_joni> is it somewhere else in the manual?
[13:06:38] <alex_joni> if not, then I'd like to keep it in the manual
[13:07:01] <alex_joni> some / quite a few / people don't know about man pages, or don't think they need to consult them besides the pdf manual
[13:08:21] <fenn> a lot of hal stuff is not in the pdf's
[13:08:29] <alex_joni> well. .it shoudl be
[13:08:41] <fenn> there is a .pdf version of the man pages too
[13:09:33] <fenn> eh, 'not in the user/integrator/dev pdf' i mean
[13:11:12] <jepler> I think it's best if the information is not duplicated, and "use man" is just a minor education issue that can be helped by a mention in the pdf manuals somewhere
[13:11:44] <jepler> though iocontrol.9 and motion.9 are not the only duplications of information in the pdf files
[13:12:20] <jepler> specifically, I think all the blocks-era components are documented in the pdfs
[13:12:26] <jepler> and stepgen and so on
[13:12:37] <jepler> sometimes they have better diagrams and so forth in the pdf manual (stepgen sure does)
[13:12:46] <fenn> yes
[13:23:21] <alex_joni> bbl
[13:29:54] <skunkworks_> interesting
http://cnczone.com/forums/showthread.php?t=43755
[13:37:50] <fenn> looks like he should be using f(x) not f(a)
[13:39:07] <fenn> i'd hate to try to do a hexapod in that
[13:41:31] <skunkworks_> heh
[14:04:01] <SWPadnos> jepler, 24" 1920x2400 LCDs are $349 at Costco
[14:04:06] <SWPadnos> err1920x1200
[14:05:18] <jepler> hmmm
[14:05:25] <SWPadnos> http://www.costco.com/Browse/Product.aspx?Prodid=11220706&whse=BC&Ne=4000000&eCat=BC|84|1680|62021&N=4018491&Mo=6&pos=0&No=5&Nr=P_CatalogName:BC&cat=62021&Ns=P_Price|1||P_SignDesc1&lang=en-US&Sp=C&ec=BC-EC12116-Cat1680&topnav=
[14:05:30] <SWPadnos> that's a big URL
[14:05:33] <jepler> you are like the devil who sits on my shoulder
[14:05:37] <SWPadnos> heh
[14:05:40] <jepler> "kill them all" he wispers, alternating with "buy more computers"
[14:05:44] <SWPadnos> at least it's a goog geal ;)
[14:05:47] <SWPadnos> good
[14:06:23] <SWPadnos> I don't know the quality, but that's the same size/res as my two Dells
[14:06:46] <SWPadnos> hmmm. I should probably get a couple for my other computers ;)
[14:07:08] <jepler> if I buy something it'll probably be a 1280x1024 and hopefully under $200
[14:07:36] <SWPadnos> icky
[14:07:35] <cradek> can you run that resolution with any old dvi card, or is it in the "special" territory?
[14:07:39] <SWPadnos> err - I mean, that's cost effective
[14:07:47] <SWPadnos> 1920x1200 is pretty normal
[14:07:53] <SWPadnos> 3840x2400 is not
[14:07:58] <jepler> and probably not widescreen
[14:08:37] <SWPadnos> http://www.costco.com/Browse/Product.aspx?Prodid=11227819&whse=BC&Ne=4000000&eCat=BC|84|1680|62022&N=4018492&Mo=7&pos=1&No=7&Nr=P_CatalogName:BC&cat=62022&Ns=P_Price|1||P_SignDesc1&lang=en-US&Sp=C&ec=BC-EC12116-Cat1680&topnav=
[14:08:42] <jepler> newegg has viewsonic 20" 1680x1050 (widescreen) for $190-$20MIR
[14:08:57] <SWPadnos> same thing, $160
[14:09:16] <cradek> I wouldn't want to trade in any of my 1200 lines
[14:09:26] <SWPadnos> indeed
[14:09:37] <cradek> the width means almost nothing to me
[14:09:40] <SWPadnos> and 1920x1200 lets you watch HD movies on it at full res
[14:09:42] <jepler> I wonder if it's worth paying for brand names anymore
[14:09:48] <jepler> SWPadnos: where would I get these HD movies?
[14:09:55] <SWPadnos> err - Best Buy?
[14:10:05] <jepler> bah
[14:10:10] <skunkworks_> * skunkworks_ is running 2 monitors at 1280X1024
[14:10:10] <cradek> I'd trade 1600x1200 for 1920x1200, but I would not want any fewer lines
[14:10:13] <SWPadnos> no, from your new Sony Vaio laptop with Blu-Ray disc player in it
[14:10:24] <jepler> bah
[14:10:27] <SWPadnos> heh
[14:10:35] <SWPadnos> double-bah there
[14:10:45] <cradek> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=130152845385
[14:10:51] <cradek> does anyone know what "style" of collets these are?
[14:11:38] <cradek> they look like useful sizes but ideally I'd like to be able to get more/replacement collets
[14:11:56] <skunkworks_> I like these better..
http://cgi.ebay.com/Erickson-30-Taper-COLLET-CHUCKS-Bridgeport-CNC-Milling_W0QQitemZ130152844959QQihZ003QQcategoryZ104242QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
[14:14:49] <cradek> I guess DA180 are cheaper than ER40 (but not much)
[14:14:57] <skunkworks_> :) I thougth you where on a spending freeze :)
[14:14:58] <skunkworks_> http://cgi.ebay.com/41-Pcs-Close-Tolerance-DA-180-1-8-3-4-x64ths-collet-set_W0QQitemZ160158122423QQihZ006QQcategoryZ25294QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
[14:15:09] <skunkworks_> then that would be a nice set
[14:15:32] <skunkworks_> might keep an eye out for cheaper ones.
[14:15:33] <cradek> yeah no kidding
[14:15:40] <cradek> by 64ths would be great
[14:15:44] <skunkworks_> yes
[14:16:37] <skunkworks_> I think they have a tollerence of 64ths so you could really hold anything. but you would want to check that out.
[14:17:27] <cradek> I could also just buy a cheap ER40 set (I have the chuck)
[14:17:27] <skunkworks_> * adjustment range.
[14:17:40] <cradek> having two chucks would be cool though.
[14:17:52] <skunkworks_> :)
[14:20:35] <cradek> nobody knows what these others are? maybe they're something weird
[14:21:26] <skunkworks_> your first link? I have seen them - acorn style :)
[14:22:31] <skunkworks_> but I don't know the designation
[14:24:24] <skunkworks_> er40 is very nice also
[14:25:33] <skunkworks_> nice long taper - and it has the extractor built in. (pops the collet out when you are loosening it.
[14:25:43] <skunkworks_> )
[14:26:06] <skunkworks_> http://cgi.ebay.com/Precision-ER40-Series-Spring-Collets-1-8-1-0-23PC-SET_W0QQitemZ160158035919QQihZ006QQcategoryZ25262QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
[14:29:26] <cradek> I saw those but I'm worried that the title says ER40 and the text below says ER32
[14:29:47] <cradek> I do like that unscrewing the nut pulls the collet out
[14:32:21] <Guest248> odd
[14:32:40] <Guest248> Guest248 is now known as skunkworks__
[14:33:51] <skunkworks__> I don't think er32 goes to an inch
[14:33:55] <skunkworks__> but I could be wrong
[14:34:23] <cradek> I bet you're right
[14:34:36] <cradek> I emailed him anyway, we'll see if he gets back to me in time
[14:37:01] <fenn> why would you need all those collets for a milling machine anyway?
[14:37:12] <fenn> i can see how they'd be useful on a lathe
[14:37:36] <skunkworks__> that is how you hold the assorted mills and such
[14:37:38] <cradek> well currently I'm missing obvious sizes like 1/2
[14:37:42] <SWPadnos> err - instead of end mill holders?
[14:37:48] <cradek> and 3/8...
[14:38:07] <cradek> so I could buy the ones I need at $30 each or a set that will hold anything
[14:38:15] <fenn> 23 is not excessive, but 41 is a lot of collets
[14:38:20] <cradek> and, I've already wanted odd sizes a few times
[14:38:39] <cradek> http://timeguy.com/cradek-files/01188770083/DSCN6327.JPG
[14:38:42] <cradek> ^ like for this setup
[14:38:53] <SWPadnos> 57 is better, unless you need metric, or you want to go beyond 1"
[14:39:01] <SWPadnos> in which case you need more
[14:39:01] <cradek> I used .005 shim stock to use a collet that was .010 too big to hold it
[14:39:26] <skunkworks__> did it take a few tapes to get it centered?
[14:39:33] <skunkworks__> (with a hammer)
[14:39:40] <fenn> does it even need to be centered?
[14:39:58] <cradek> I got it pretty close (maybe .002 tir)
[14:40:01] <fenn> that job needs a tailstock
[14:40:03] <skunkworks__> * skunkworks__ figures cradek is a perfectionist
[14:40:14] <fenn> well, wants a tailstock
[14:40:27] <cradek> fenn: this quickchange spindle clamps the flange, so it should be pretty well centered
[14:40:53] <cradek> yeah a tailstock would have been nice. but I was gentle and it worked fine
[14:45:47] <cradek> finally got the mill out of the center of the garage and into a corner - it doesn't look so huge now
[14:50:36] <cradek> jepler: have you done anything with the serial number problem?
[14:51:49] <jepler> cradek: no, I haven't.
[14:52:07] <cradek> should I just take out the halui "smarts" and have it increment like the others?
[14:52:19] <cradek> that would make it no worse than anything else
[14:52:57] <cradek> ... and maybe we could start it at 10000 and never see the problem
[14:54:17] <SWPadnos> have it count downward - then it would only be a problem every once in a while
[14:54:27] <fenn> have it count imaginary numbers
[14:54:46] <fenn> every interface could have its own set of basis vectors
[14:56:35] <jepler> cradek: I've been reluctant to do anything because I don't feel I know the proper solution to the problem
[14:57:15] <cradek> we must be different then, that never stops me
[14:58:11] <jepler> I do think things will get better if you remove the "smart" from halui, but I don't know if it will be in some sense "right"
[14:58:13] <cradek> if(a) return b(); else return c(); return d;
[14:58:43] <SWPadnos> that seems a bit wordy
[14:58:56] <fenn> it'll never return d
[14:59:04] <SWPadnos> those are the extra words :)
[14:59:04] <cradek> no really
[14:59:41] <cradek> for extra elegance, "a" is a constant that's never changed
[14:59:49] <fenn> nice
[14:59:56] <SWPadnos> awwwwwwwesssssome
[15:01:53] <SWPadnos> I wonder what would happen f a were a constant that *did* change
[15:01:55] <SWPadnos> s/f/if/
[15:02:16] <fenn> you'd get a compiler error?
[15:22:55] <cradek> oh good, cia isn't working so you guys won't see that change
[15:40:34] <SWPadnos> hey -that was actually if (constant) return a; else if (other constant) return b; return c;
[15:41:02] <SWPadnos> it still did nothing, but the structure was capable of returning c (or d in the original)
[15:46:27] <fenn> well i suppose the constant could change at compile time for different machines/libraries/platforms
[15:47:37] <SWPadnos> it could
[15:47:46] <cradek> huh?
[15:48:02] <cradek> static a = CONST;
[15:48:16] <cradek> if(a == CONST) ... else if(a == OTHERCONST) ...
[15:48:26] <SWPadnos> sure, which can change at compile time
[15:48:40] <SWPadnos> ie, change the source so static a = const OTHERCONST
[15:48:53] <SWPadnos> err -const
[15:49:05] <cradek> uh, so you're saying if someone changes the code, it would do something different?
[15:49:12] <SWPadnos> strange, isn't it? ;)
[15:49:49] <cradek> what does that have to do with machines/libraries/platforms?
[15:50:03] <SWPadnos> that enum was acting like a #define - it was a single place to switch all NML calls between wait_received and wait_done
[15:50:07] <SWPadnos> nothing
[15:50:16] <SWPadnos> I just didn't bother correcting that part
[15:50:20] <cradek> oh ok
[15:50:49] <cradek> oh I see what you mean, someone could have chosen one of three return values by changing this one static
[15:51:17] <SWPadnos> right
[15:58:30] <SWPadnos> uh - wait a second. that was a static definition, not a const definition
[15:58:44] <SWPadnos> so it's "source-file-global", but writable
[15:58:51] <cradek> right
[15:58:59] <cradek> and nothing changed it, I looked through the whole file
[15:59:02] <SWPadnos> ok
[15:59:31] <SWPadnos> I think it's time for me to get some coffee. I should have noticed that earlier
[15:59:46] <cradek> I'm glad those changes distracted you from the 100000
[16:00:03] <SWPadnos> eh - whatever. I don't see an easy and correct solution to that either
[16:00:25] <cradek> yeah, and I have no shame, I just want it to work better
[16:00:35] <SWPadnos> let's hope it does :)
[16:01:43] <SWPadnos> for machines that stay on (think like Stuart's shop), the various UI processes will be running at different loop rates, so eventually they'll sync up for a little while
[16:02:13] <cradek> these only increment when you issue a command
[16:02:18] <SWPadnos> which may be weird if a problem occurs once every 17 days or so
[16:02:20] <SWPadnos> right
[16:02:44] <cradek> you'd have to issue 100000 commands (like jogs) in one gui and none in the other
[16:03:13] <SWPadnos> ah - right, these commands aren't per line of Gcode, they're per "user action"
[16:28:34] <fenn> if a hal pin sends an nml command, does it increment the message number?
[16:30:55] <cradek> you mean halui?
[16:31:05] <cradek> each nml message gets the next number
[16:31:53] <fenn> i had the impression there were other hal pins that send nml commands, like iocontrol for instance
[16:35:51] <fenn> iocontrol only sends 'Done'
[16:42:11] <fenn> actually they lied - it sends some other nml messages too
[16:53:08] <jepler> iocontrol and task communicate using a different nml buffer than task and ui
[16:53:45] <jepler> only ui -> task typically has more than one source of messages
[16:54:30] <jepler> (gui + halui being most common)
[17:46:06] <alex_joni> that's almost true
[17:46:26] <alex_joni> iocontrol also sometimes pushes a message
[17:46:39] <alex_joni> (I did that to send estop events to task)
[17:46:49] <alex_joni> otherwise it would have only signalled on the next stat
[17:52:12] <alex_joni> cradek: the change seems ok to me
[18:09:17] <alex_joni> fenn: usually it's implemented with 2 channels, one for commands, and one for status
[18:09:31] <alex_joni> GUI sends commands to task, and gets status from task
[18:09:41] <alex_joni> task sends commands to iocontrol, and gets status from iocontrol
[18:21:21] <cradek> alex_joni: do you remember that iocontrol problem? I think I never filed a bug report
[18:23:18] <alex_joni> can't say for sure I do..
[18:23:46] <cradek> lube sometimes doesn't turn on or off right, but that's all I remember
[18:23:56] <alex_joni> oh, right.. never saw that
[18:24:17] <alex_joni> might be because of lacking hardware.. watching halmeters is not always as efficient
[18:24:27] <cradek> I looked for a while but decided I was clueless - let me see if I can do it again
[18:24:50] <cradek> I noticed it in sim, I don't have anything on iocontrol.lube on my machines
[18:25:44] <cradek> yeah it's easy to spot
[18:26:00] <cradek> just watch iocontrol.0.lube, it should turn on and off with 'machine'
[18:26:07] <cradek> it always turns on, but only sometimes turns off
[18:28:11] <alex_joni> * alex_joni looks
[18:32:25] <alex_joni> are you sure it's supposed to go off with machine off?
[18:32:33] <alex_joni> it stays on here all the time :D
[18:32:48] <alex_joni> oh, it went off once
[18:32:51] <cradek> yes I'm sure
[18:32:56] <alex_joni> weird stuff
[18:32:59] <cradek> you can even see the message if you turn on the right debug thingy
[18:34:08] <skunkworks__> 'debug thingy' :)
[18:34:18] <skunkworks__> skunkworks__ is now known as skunkworks_
[18:34:27] <alex_joni> cradek: have the name handy?
[18:34:35] <alex_joni> I turned up debug in axis, but can't seem to identify it
[18:35:01] <alex_joni> I only see: set_state, set_teleop_enable ??, set_state and plan_synch
[18:36:29] <alex_joni> guess AXIS needs more verbose debug
[18:40:45] <cradek> I'm trying to figure out how I turned on the messages... maybe it was with a recompile
[18:41:00] <SWPadnos> DEBUG in the run script/ini file?
[18:41:04] <alex_joni> I added some printf's
[18:41:07] <alex_joni> SWPadnos: won't work
[18:41:15] <alex_joni> for some odd reason I used rtapi_print_msg
[18:41:22] <SWPadnos> ok - I figured it was too simple, but thought I'd throw it out there anyway :)
[18:41:26] <alex_joni> but echo 5 > /proc/rtapi/debug doesn't help
[18:41:39] <SWPadnos> ok, that was going to be my next simple suggestion
[18:41:47] <SWPadnos> I'll go back to lurking now :)
[18:41:47] <alex_joni> maybe it gets set differently for userspace rtapi
[18:41:54] <alex_joni> some define somewhere I bet
[18:42:02] <jepler> yeah userspace programs each have their own debug level and there's no real way to set it
[18:42:20] <alex_joni> odd is that I don't see the printf
[18:46:07] <alex_joni> * alex_joni has a hunch
[18:46:23] <cradek> * cradek was hoping he would
[18:46:45] <alex_joni> I bet it's because lube off is beeing sent with sendCommand
[18:46:55] <alex_joni> but toolAbort is beeing sent with forceCommand
[18:47:12] <alex_joni> and the forceCommand might override the sendCommand
[18:48:29] <alex_joni> wonder why lube isn't switched off on tool_abort, together with mist & flood
[18:48:58] <alex_joni> does anyone see a reason to have lube go on, when mist & coolant get switched off?
[18:49:24] <cradek> I think they are unrelated
[18:49:41] <cradek> I think mist/flood can turn off whenever the spindle does
[18:49:42] <alex_joni> well.. tool_abort is supposed to switch off all things in the iocontroller
[18:49:58] <alex_joni> mist/flood and spindle (which is gone now)
[18:50:24] <cradek> I think lube is supposed to be for way/screw lube, not anything for cutting
[18:50:49] <alex_joni> still.. tool_abort gets sent in case of errors
[18:50:56] <alex_joni> not from the GUI or g-code
[18:51:15] <alex_joni> maybe IO_ABORT would be a better name to describe it
[18:51:38] <cradek> ok I guess I didn't understand the question
[18:51:45] <alex_joni> I probably wasn't clear
[18:51:54] <alex_joni> there's a message called tool_abort
[18:52:08] <alex_joni> which gets sent in case of an error (to stop spindle, mist, flood)
[18:52:29] <alex_joni> it also gets sent when switching to estop-reset and estop
[18:52:28] <cradek> ok
[18:52:46] <alex_joni> in the same cases an sepparate message LUBE_OFF is also sent
[18:53:43] <alex_joni> (only the lube_off is of lower priority, and might be lost)
[18:54:16] <alex_joni> the question was, wth isn't there only one message which resets everything in the iocontroller
[18:54:56] <SWPadnos> I suspect it's hard to define what "reset everything" means within the iocontroller
[18:55:10] <SWPadnos> I'd think some of that would cahnge depending on the machine setup
[18:55:10] <alex_joni> same as the init when it starts up?
[18:55:14] <alex_joni> :P
[18:55:17] <SWPadnos> could be
[18:55:32] <alex_joni> but I agree it should be configurable
[18:55:32] <SWPadnos> but outputs are probably not enabled at startup
[18:55:43] <SWPadnos> (physical driver outputs, that is)
[18:55:57] <SWPadnos> you'd have to capture the "initialized state", not the startup state
[18:56:00] <cradek> but that aside, isn't it a problem that messages are sometimes dropped?
[18:56:11] <SWPadnos> heh - that is a problem ;)
[18:56:13] <cradek> seems like changing the messages around will not fix that
[18:56:16] <alex_joni> cradek: I guess it's a safety feature
[18:56:29] <alex_joni> * alex_joni says by only looking at the stuff
[18:56:44] <alex_joni> I think nist came to conclusion that some messages are really important
[18:56:59] <alex_joni> and it wouldn't hurt if others are interrupted
[18:57:04] <alex_joni> "maybe
[18:57:10] <cradek> oh? bizarre
[18:57:17] <jepler> maybe this weekend I'll toss iocontrol and task, write a merged iotask in python, and get rid of nml while I'm at it.
[18:57:21] <alex_joni> "maybe" in the beginning they still delivered the interrupted message somehow
[18:57:29] <jepler> smop to do that
[18:57:38] <alex_joni> jepler: right :)
[18:57:54] <alex_joni> we'll all toss in some bucks for you to take a long weekend off
[19:00:15] <SWPadnos> jepler, just call Paul - I think he has most of that done already
[19:00:23] <alex_joni> ha
[19:01:10] <cradek> oh let's not start
[19:01:24] <alex_joni> cradek: can you look at iotaskintf.cc line 200 ?
[19:01:50] <cradek> strncpy?
[19:02:08] <alex_joni> static int forceCommand()
[19:02:13] <alex_joni> line 196 to be exact
[19:02:30] <cradek> ok
[19:02:34] <cradek> (I was in the wrong file)
[19:02:43] <alex_joni> sounded like it :)
[19:03:58] <cradek> yuck I bet you're right
[19:04:08] <cradek> it's a "feature" that it gets stepped on sometimes
[19:04:18] <alex_joni> yeah, sure sounds like it
[19:04:24] <cradek> that's stupid
[19:04:29] <alex_joni> * alex_joni is a bit too lazy to bring out the RCS book
[19:05:27] <alex_joni> oh great
[19:06:03] <SWPadnos> force is necessary for stop commands and the like, but it's a bug that it causes other commands to be forgotten
[19:06:20] <SWPadnos> they should be stuck at the end of the queue (if there weer a wueue)
[19:06:23] <SWPadnos> were
[19:06:30] <alex_joni> moving things around really helps, now I can't get out of estop at all :D
[19:07:44] <cradek> it's a bug in the design that anything estop-related goes through nonrealtime
[19:08:07] <alex_joni> hmm, initially (in emc1) the tool controller and the lube controller were sepparate
[19:08:09] <skunkworks_> this has been descussed :)
[19:08:12] <skunkworks_> discussed
[19:08:15] <cradek> sure
[19:08:37] <alex_joni> * alex_joni ponders abotu really cleaning things up
[19:08:41] <cradek> in hal we can work around it (motion.enable etc)
[19:08:57] <alex_joni> working around it is a bad thing
[19:09:08] <alex_joni> having to work around it is even worse
[19:09:54] <SWPadnos> cradek, it's not really a bug, since the definition of estop requires that no software be involved in making the machine safe
[19:09:58] <SWPadnos> but it does seem silly
[19:10:10] <cradek> since an estop circuit stops the machine, whether emc knows about it in one or two time periods doesn't matter
[19:10:19] <SWPadnos> right
[19:10:21] <cradek> right I think we're saying the same thing now
[19:10:26] <alex_joni> right
[19:10:33] <cradek> so, back to 'the force is stupid'
[19:10:39] <SWPadnos> ok, I can accept that :)
[19:10:44] <alex_joni> cradek: the force it theoretically sane
[19:10:54] <alex_joni> but the implementation is not nice
[19:11:07] <alex_joni> especially since there's a last_io_command
[19:11:09] <cradek> well there's no queue, I think that's what makes it suck
[19:11:19] <alex_joni> * alex_joni tries some funky stuff
[19:22:37] <alex_joni> wth is task state off?
[19:41:22] <alex_joni> cradek: I might make the assumption I fixed it the right way..
[19:41:41] <cradek> yay
[19:41:53] <cradek> thanks for fixing it
[19:42:11] <cradek> does anything else use force?
[19:42:27] <alex_joni> yes, the sendauxestopthingies
[19:42:52] <alex_joni> and no, nothing besides iotaskintf.cc uses force
[20:58:15] <alex_joni> lets move the ns2tsc talk in here
[20:58:54] <jepler> except that it's really skyfox00's problem since it works just fine on the supported systems..
[20:58:57] <alex_joni> it might be a bit confusing for users in #emc
[20:59:02] <alex_joni> I asked him to join here
[20:59:03] <jepler> I'm really, really inclined to do nothing
[20:59:58] <skyfox00> I have a linux kernel module that just does printk's that I can try math stuff with if anyone would like...
[21:00:44] <alex_joni> skyfox00: I think the easiest solution for now would be to take the __<mumble> function, and place it inside hal_parport
[21:01:46] <skyfox00> oh, you mean copy it form its source (libgcc?) into hal_parport?
[21:01:50] <alex_joni> yeah
[21:02:39] <alex_joni> or if you feel like it, add a rtapi function for 64/64 bit divide (using rtai_ulldiv)
[21:03:59] <skyfox00> would copying the libgcc function in be a perminant emc fix?
[21:04:06] <fenn> are you sure you guys arent chasing the wrong tree?
[21:04:17] <alex_joni> skyfox00: nope, it would be a fix for you
[21:04:19] <skyfox00> what is the right tree?
[21:04:21] <fenn> i see a lot of 'warning: not defined' in that pastebin
[21:04:27] <fenn> mostly rt functions
[21:04:31] <jepler> fenn: yes that's a red herring
[21:04:32] <alex_joni> fenn: that's rtai functions
[21:04:39] <jepler> fenn: the kernel build system is too clever by half
[21:04:50] <alex_joni> because kbuild doesn't know about stuff outside the kernel tree and the emc2 tree
[21:05:30] <skyfox00> move emc+rtai into the kernel tree? (*puts on flame retardent suit*)
[21:07:02] <jepler> "retardant"
[21:07:09] <skyfox00> yeah yeah....
[21:07:24] <jepler> sorry, I always criticise the spelling of people whose nicks start with sk .. just ask skunkworks
[21:08:31] <skyfox00> thats ok...
[21:08:54] <skyfox00> ok, I have a kernel module that I can load and it does prink's....
[21:09:31] <skyfox00> how shall I smoke test gcc?(should I even bother?)
[21:13:43] <SWPadnos> set the computer on fire
[21:14:18] <jepler> if anything's going to be done it's probably best to implement 64/64->64 as a rtapi_XXX function and call it from hal_parport.c. The first implementation should be written in portable C without the use of floating-point even if it's excruciatingly painful.
[21:15:26] <jepler> and also change 1e6 to 1000000 in hal_parport.c
[21:15:46] <alex_joni> one-e-six is nicer :D
[21:16:09] <jepler> you can look in the output of 'nm hal_parport.c' for any undefined __ functions -- __divdi3 is the one you'll probably get if you restore the 64/64 division
[21:16:10] <skyfox00> Am I the only persion that will need this or would emc benifit from such a function?
[21:16:50] <jepler> the code runs just fine on ubuntu 5.10 and 6.06 and apparently is just fine on recent gcc versions which inline what your gcc is trying to do with a call to __fixmumble
[21:17:41] <skyfox00> what versions of gcc does Ubuntu use?
[21:17:43] <jepler> but a patch that will improve portability on the whole is pretty attractive to incorporate
[21:18:18] <jepler> ubnutu 5.10's kernel appears to also use gcc 3.4 but it doesn't exhibit the problem you saw; 6.06 and newer use 4.x versions
[21:21:13] <skyfox00> so if I write a function, would it assume that the input would be 32.32 and return 32.32?
[21:21:19] <jepler> no
[21:21:39] <jepler> the math is with 64 bit integers
[21:21:52] <jepler> it's only the interpretation that says they are 32.32 fixed point numbers
[21:22:08] <SWPadnos> it matters to the function though
[21:22:23] <SWPadnos> for both multiply and divide
[21:22:37] <skyfox00> oh, so all crunching inside this hypothetical function is on 64 bit ints?
[21:22:37] <jepler> long long rtapi_proposed_division_function(long long numerator, long long divisor) { return numerator / divisor; }
[21:23:47] <SWPadnos> ok - for divide it doesn't matter, thuogh it does for multiply
[21:23:49] <SWPadnos> though
[21:24:53] <skyfox00> ok, so we need a devider, do we also want a similar multiplyer?
[21:25:35] <SWPadnos> it seems that might not be needed
[21:25:45] <jepler> that depends what "all the versions of gcc in the world" do
[21:25:49] <SWPadnos> the code snippet jepler posted on #emc had a multiplication in it
[21:25:53] <SWPadnos> that's truwe
[21:25:56] <SWPadnos> -w
[21:25:56] <jepler> or even the subset where people want to run it
[21:27:41] <jepler> from the sample of your system, ubuntu 5.10, and ubuntu 6.06 the multiplication in ns2tsc() is not a problem
[21:28:23] <jepler> only the 64/64 division (ubuntu, which lead to the formulation in terms of double division followed by cast to long long) or double-to-long-long cast (which gives the insmod error on your system but not on ubuntu)
[21:29:11] <skyfox00> is there any sort of flag that can be passed to gcc to make it do math differently?
[21:30:13] <jepler> gcc has hundreds if not thousands of flags
[21:31:48] <alex_joni> you could implement a QQRNND algorithm
[21:31:54] <skyfox00> how can I make a testbench for doing such math in a kernel module?(I have the kernel module, I just dont know how to make try/fail to do large math)
[21:33:44] <jepler> umm .. write the code you want to test, insmod it, and see if you get an insmod error?
[21:34:46] <skyfox00> so I create 2 unsigned long long ints(?) and try to devide one by the other?
[21:35:30] <alex_joni> yup
[21:36:11] <skyfox00> lol, __udivdi3 undefined...
[21:38:17] <SWPadnos> ok, so you've recreated the problem ;)
[21:38:38] <jepler> hmm .. it would also be possible to use 12 fractional bits .. in this formulation, the numerator fits in a 32-bit unsigned long: 1000000 * (1<<12) / cpu_khz
[21:39:16] <jepler> it gives answers close to the ideal answer
[21:40:14] <jepler> e.g., 1 cycle difference for a 2.7GHz CPU and a 5000ns delay compared to the current formulation
[21:40:16] <skyfox00> how do you print a unsigned long long int with printk?
[21:40:19] <jepler> you don't
[21:40:35] <skyfox00> cast it as a %Lf?
[21:41:05] <jepler> at least if %lld doesn't work I don't know what else to try
[21:41:23] <jepler> no, you can't use floating-point in a traditional (as opposed to real-time) kernel module
[21:41:37] <skyfox00> casting as an int works for testing I guess...
[21:43:39] <jepler> ns2tsc_factor = (1000000u * (1<<12u) + cpu_khz - 1u) / cpu_khz
[21:43:39] <jepler> #define ns2tsc(x) (((x) * ns2tsc_factor) >> 12)
[21:44:05] <jepler> I'm leaning towards reformulating things so ns2tsc_factor isn't computed with 64-bit arithmetic
[21:44:28] <skyfox00> just how are these long long's defined?
[21:44:33] <SWPadnos> I'd throw in another set of parens
[21:44:49] <jepler> SWPadnos: is that sarcasm or did I overlook something?
[21:45:05] <jepler> the multiplication x*ns2tsc_factor is still done with 64 bits
[21:45:29] <jepler> but 32*64 -> 64 doesn't seem to be a problem on any systems we know about
[21:45:31] <SWPadnos> oh - right. ns2tscfactor isn't a define - nevermind
[21:48:31] <jepler> the (... + cpu_khz - 1u) part is intended to give "ceil-like" behavior to the ns2tsc calculation
[21:48:51] <jepler> not sure if it actually manages to
[21:50:28] <SWPadnos> it seems that it would round up
[21:50:44] <jepler> http://pastebin.ca/702497
[21:51:32] <jepler> looks good from here
[21:51:46] <jepler> and unless I miss something, it skirts the 64/64 problem
[21:55:35] <skyfox00> is that a good thing?
[21:59:38] <jepler> yeah it means that the need for __divmumble or __fixmumble should go away on your system
[22:00:27] <alex_joni> is that a good thing?
[22:00:40] <skyfox00> cool... I'm a bit slow, though, so what was the trick?
[22:01:37] <alex_joni> reducing the >> 32 calcs to >> 12
[22:01:43] <jepler> the original expression to calculate ns2tsc_factor required values larger than 1<<32 as the numerator in a division
[22:02:14] <skyfox00> so you just reduced the number of bits involved?
[22:02:16] <jepler> on all our systems, this caused an insmod error about the function __divmumble, because gcc implements that division as a call to the function instead of as a series of instructions in-line
[22:02:55] <jepler> (the final result could also be bigger than 1<<32)
[22:03:33] <jepler> (and the next calculation, in the #define ns2tsc(x), also had an intermediate result bigger than 1<<32)
[22:03:58] <jepler> so having encountered the __divmumble problem, I rewrote the expression ns2tsc_factor = ... to be a floating point division with the result cast to unsigned long long
[22:04:06] <jepler> on your system (but not mine) this gave an insmod error about the function __fixmumble
[22:04:53] <skyfox00> so will it work on 'everyones' systems?
[22:05:04] <jepler> so I decided to find a new formulation which did not have either of these features (division of 64-bit integers or cast from double to 64-bit integer)
[22:05:36] <jepler> the formula is a little bit less exact but that's perfectly acceptable in this case
[22:05:47] <jepler> I think it will work on your system and on my system
[22:06:32] <skyfox00> is it just one line that will need modifying or will I need to download the entire file?
[22:08:05] <jepler> "cvs up" will get my changes once I check them in
[22:08:14] <skyfox00> ok
[22:08:25] <jepler> but I'm still testing the change (to the extent I can without a hardware scope to hook up to my parport)
[22:08:29] <alex_joni> unless you changed the file..
[22:08:45] <alex_joni> skyfox00: then you might get problems when updating (merging errors)
[22:08:58] <jepler> and assuming that you originally used cvs to get your source tree
[22:09:09] <skyfox00> I'll just do a whole fresh cvs download
[22:09:31] <skyfox00> yeah, I used cvs to get the emc2-trunk directory...
[22:11:49] <alex_joni> then cvs up -dP is all you need
[22:12:26] <jepler> hm the formula is wrong anyway
[22:12:59] <jepler> the original one, I mean
[22:13:09] <skyfox00> how so?
[22:13:53] <jepler> ns2tsc(x) gets smaller as cpu_khz increases; it should get bigger (because there are more CPU cycles in a given time)
[22:24:58] <skyfox00> totaly unrelated... what mode is the parport in when the pluto_servo frimware is unloaded?
[22:25:14] <skyfox00> or is that a question for #emc
[22:26:08] <jepler> in 2.2 it looks like it's left in EPP mode, though if I hadn't looked at the source code I'd have said it was reset to SPP mode
[22:26:26] <jepler> that is, in cvs trunk...
[22:27:35] <skyfox00> so when the firmware loads corectly, the LED goes out... if when pluto_servo is unloaded the led comes back on, does that mean EPP is working?
[22:28:53] <jepler> static void pluto_cleanup(void) {
[22:28:52] <jepler> if(region1)
[22:28:53] <jepler> outb(0, ioaddr+2); // set nInitialize low and reset the FPGA
[22:29:16] <jepler> when the driver is unloaded, the pin "nInitialize" is driven low which makes the FPGA assert its internal reset signal and unload the firmware
[22:29:33] <skyfox00> ok, got it, that helps greatly...
[22:32:27] <jepler> jmkasunich_: are you really there or is it just your dsl bouncing?
[22:33:50] <jepler> I guess that answers my question
[22:33:59] <alex_joni> yup
[22:34:09] <SWPadnos> heh
[22:34:11] <SWPadnos> so close
[22:35:39] <skyfox00> does the parport(in EPP mode) ever tell you if an EPP read/write times out?
[22:35:52] <jepler> skyfox00: yes, that's what communication-error is supposed to indicate
[22:36:42] <skyfox00> does the pluto_servo test_encoder parameter work?
[22:37:18] <jepler> yes but you need other stuff in the .hal file to generate a quadrature signal on certain of the digital outputs
[22:37:43] <skyfox00> does using setp on the output pins do it?
[22:37:57] <skyfox00> (in halrun -I)
[22:38:30] <jepler> yes it should
[22:39:03] <skyfox00> ok... what does it mean when debug_0 (and I think debug_1) = 16?
[22:41:17] <jepler> I don't think those have any meaning at the moment
[22:41:27] <jepler> the only assignment to them I see is in an if(0) block...
[22:42:38] <skyfox00> line 282 of pluto_servo.comp: if(i==0).... that one?
[22:43:42] <jepler> yeah
[22:44:54] <skyfox00> so if I'm not getting any communication errors, does that mean that EPP is working and that its talking to the pluto like its saposed to? or does that just mean there are no EPP errors.(EPP not working at all)
[22:46:19] <jepler> OK, so debug_0 will be the first 32 bits read from the pluto
[22:46:53] <jepler> this is information about the state of encoder.0.
[22:47:11] <skyfox00> right...
[22:47:39] <jepler> debug_1 should be the same as encoder.0.counts except without taking into account any causes of counter reset (such as index pulse or assertion of the hal encoder.0.reset pin)
[22:48:34] <skyfox00> when pluto_servo loads, should all the counters be 0?(with nothing connected to the board)
[22:49:42] <jepler> the pins do not have pull-ups or pull-downs so they could register spurious signals .. I think they generally register as FALSE when unconnected though.
[22:50:00] <jepler> and the counters would not count
[22:50:38] <jepler> unless as I said there are suprious signals because the inputs are not being driven
[22:50:43] <skyfox00> so counter.0.value always being 16 on startup is just random?
[22:51:03] <jepler> it seems a bit odd to me
[22:51:19] <alex_joni> good night guys
[22:51:22] <SWPadnos> what EPP status bit is 0x10?
[22:51:25] <SWPadnos> see you Alex
[22:51:26] <fenn> i was reading about using startup values in computer ram for getting random numbers
[22:51:27] <jepler> I recall distinctly that when I ran your .hal file last night all the .encoder halmeters said "0"
[22:51:49] <SWPadnos> yep - I think I linked that article for jymmm
[22:51:55] <fenn> it appears that each individual chip has its own 'fingerprint' of cells that tend to be on
[22:52:07] <skyfox00> oh, yeah, the hal file is good, just dont know about the hardware...
[22:52:27] <SWPadnos> skyfox00, how long is your printer cable, and have you tried a different one (or directly plugging the pluto into the port)?
[22:52:48] <skyfox00> its plugged directly into the back of the onboard parport...
[22:52:54] <SWPadnos> ok
[22:54:10] <skyfox00> I can send quadrature(by hand) signals into the dout0-1 pins with the module loaded with test_encoder=1 and the counter does change...
[22:54:24] <skyfox00> does not change.
[22:54:40] <fenn> is that because they're dout pins?
[22:54:52] <jepler> are all the encoders stick at 16, or is only the first one 16?
[22:55:30] <skyfox00> just the first one is at 16 at startup, but raising the reset pin(from halrun) then lowering it sets it to 0
[22:55:30] <jepler> fenn: when test_encoder=1, the dout 0, 1, and 2 pins are internally looped to the encoder.0 inputs (at least that's what the manpage says :-P)
[22:56:02] <jepler> skyfox00: the encoder.0.reset pin is internal to the PC, it doesn't get "transmitted" to the pluto device
[22:56:18] <skyfox00> thats kinda what I thought.
[22:56:23] <jepler> skyfox00: does your .hal file add both the read and write functions to the thread?
[22:56:57] <skyfox00> yeah, it does
[22:57:19] <jepler> if you unplug the pluto from the parport while the driver is loaded, does communication-error start incrementing?
[22:57:48] <skyfox00> I dont remember doing that specificly...
[22:57:54] <skyfox00> shall I go try it?
[22:58:33] <jepler> if it doesn't start incrementing, that means the communication error detection (or maybe all of epp) isn't working on your hardware
[22:58:37] <jepler> I think it would be a useful test
[22:58:45] <skyfox00> brb, will try it...
[22:59:40] <jepler> another thing to do is test with a logic probe or oscope whether there is active pulsing on these pins: 1, 2, 11
[22:59:49] <jepler> in a functioning system, the PC will be causing pulses on 1, the pluto will be causing them on 11, and both will be causing them on 2 (though not so much the pluto if all its inputs are FALSE)
[23:02:15] <skyfox00> ok, unplugging causes errors...
[23:03:16] <skyfox00> and touching the Q[ABZ]* pinheaders causes the counters to jump around then return to zero...
[23:03:52] <skyfox00> and it wasy 13 that counter.0.value starts up as, but is sometimes 5, etc...
[23:04:04] <skyfox00> so reading seems to work fine...
[23:06:15] <jepler> huh
[23:07:17] <jepler> can you easily measure voltage or check for pulsing on the UP0/DOWN0 pins? set a dout-NN pin to 1 and measure it?
[23:07:32] <jepler> have you tried loading with watchdog=0 ?
[23:08:05] <jepler> physically loop dout-NN to din-NN ?
[23:09:01] <skyfox00> I think I tried watchdog=0; I have only used the onboard led for measureing voltage; have yet to loop dout->din...
[23:11:41] <jepler> if the watchdog timer goes off the LED will too
[23:11:55] <jepler> have you run the rtai latency test on this machine?
[23:12:04] <skyfox00> in the pluto_servo documentaion: LED=UP0 xor DOWN0. is there a mode (pwm+dir?) that could cause the led to not lite when pwm.0.value set to 1?
[23:12:12] <skyfox00> no rtai testing of any sort...
[23:13:27] <jepler> if you're using the same .hal file you put on pastebin last night, it ramps the LED on and off
[23:14:02] <skyfox00> yeah, its the same one...
[23:14:53] <jepler> you're sure? after all, I know you didn't pastebin it from the machine you're testing on..
[23:14:47] <skyfox00> I use my thumb drive like a network ;)
[23:16:17] <skyfox00> It could be some other gcc 3.4 induced bug that compiles fine but doesnt run quite right...
[23:19:52] <jepler> I'd love to know whether the output pins show as high, low, or Z -- if they show as Z it would implicate the watchdog timer
[23:20:18] <jepler> with a logic tester I mean
[23:20:36] <skyfox00> would a digital volt meter work?
[23:21:47] <jepler> you can tell if you're getting a HIGH with a volt meter, but low and Z will probably both show up as 0V
[23:23:01] <skyfox00> if measuring from +3.3 to dout and gnd to dout both are 0V, would that mean Z?
[23:23:22] <SWPadnos> probably
[23:23:23] <jepler> I dunno; is that what you measure?
[23:23:36] <SWPadnos> though it could also mean you have a problem with your meter or measurement method
[23:24:56] <skyfox00> ok, what all pins should I test, and how?
[23:25:30] <jepler> setp pluto-servo.dout-00 1
[23:25:46] <jepler> then measure the voltage at dout-00 and dout-01
[23:25:57] <jepler> if it was working you'd measure over 2V at dout-00 and under .1V at dout-01
[23:25:56] <skyfox00> got it...
[23:26:49] <jepler> you're on DC and set to 2V or 20V scale right?
[23:27:01] <skyfox00> yeah...
[23:27:02] <jepler> measure GND - VCC just for the sake of completeness
[23:27:09] <skyfox00> right
[23:28:31] <skyfox00> dout-00 and dout-01 corispond to out0 and out1 on the 'about pluto_servo' page, right?
[23:28:35] <jepler> right
[23:29:53] <skyfox00> ok will go test... brb
[23:31:21] <jepler> I'll take this opportunity to finally drive home from the office
[23:31:23] <jepler> be back later
[23:31:37] <SWPadnos> heh -see you
[23:42:33] <skyfox00> ok, dout-00 has a LOW and dout-01 has a HIGH regardless of setp pluto-servo.dout-0[1/2] true/false
[23:43:17] <skyfox00> they do not seem to be Z though..
[23:55:56] <skyfox00> * skyfox00 is slightly absent....
