Back
[00:15:10] <jmkasunich> ooohh - the .obj model has holes in it!
[00:15:19] <jmkasunich> (ones that look like they are on purpose)
[00:15:46] <jmkasunich> "normal" vismach doesn't do holes well
[00:30:56] <jepler> Lerman: off and on
[00:31:33] <jepler> Lerman: (I see your e-mail)
[01:09:30] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/beeps.py
[01:54:40] <jmkasunich> 3.903+.125+.1875
[01:54:44] <jmkasunich> oops
[01:56:36] <mozroute> calculator didn't have the focus?
[01:57:38] <mozroute> I wrote a .comp file and am getting errors relating to variables in it.
[01:58:50] <mozroute> I have three variables and when I try to compile it gives the following type of error for each time I reference one of the variables in my function:
[01:58:51] <mozroute> ubob-outputs.comp:26: error: ‘struct state’ has no member named ‘shift_count’
[01:59:25] <jmkasunich> if you want somebody to be able to help you they have to see your file - use pastebin.ca
[01:59:55] <mozroute> ok, just a second...
[02:03:14] <mozroute> pastebin won't let me paste to it.. let me find another site
[02:04:08] <jmkasunich> odd, works for me
[02:04:09] <jmkasunich> http://pastebin.ca/1178281
[02:04:31] <jmkasunich> as far as I know, it makes no distinction who or where you are
[02:05:45] <mozroute> it said it thought I was spamming or something
[02:06:01] <mozroute> I tried pastebin.com and it worked:
http://pastebin.com/d2ab0750a
[02:06:54] <jmkasunich> I don't see anything called "state" in there
[02:07:09] <SWPadnos> I think state is created by comp
[02:07:27] <jmkasunich> oh, ok
[02:07:33] <SWPadnos> try using [] instead of ()
[02:07:37] <SWPadnos> (maybe)
[02:08:44] <jmkasunich> what is with that "output-#[8]" syntax in line 9? is that another comp special?
[02:09:02] <SWPadnos> looking that up right now :)
[02:09:05] <mozroute> [] didn't help
[02:09:29] <mozroute> it gives an error for shift_count and shift_next as well.
[02:09:41] <mozroute> ? y'all are the experts :-) I'm a newbie!
[02:09:44] <jmkasunich> just for grins, move line 12 after line 14
[02:10:02] <mozroute> I copied some stuff from a comp jepler did
[02:10:13] <jmkasunich> us'all are not .comp experts - comp takes what you right and massages it a bit to make C code
[02:10:34] <jmkasunich> I can spot problems in C, but I don't have the .comp transformations memorized
[02:10:36] <SWPadnos> which one?
[02:10:54] <SWPadnos> (which jepler comp did you base this one on? :) )
[02:11:39] <mozroute> idoubler for the input doubling stuff I mentioned from CandCNC a couple weeks ago
[02:11:46] <mozroute> I got that working btw
[02:12:21] <mozroute> moving line 12 after 14 made most of the errors go away, but I have this one
[02:12:35] <mozroute> ubob-outputs.comp: In function ‘_’:
[02:12:36] <mozroute> ubob-outputs.comp:48: error: expected expression before ‘else’
[02:13:01] <SWPadnos> yep
[02:13:04] <jepler> at first glance you may have hit a bug in comp
[02:13:16] <jmkasunich> you got some a misplaced { in there
[02:13:17] <SWPadnos> you have an if with a curly brace statement, then another statement, then the else
[02:13:18] <jepler> /tmp/tmpUY5Jmu/ubob_outputs.c:31: warning: no semicolon at end of struct or union
[02:13:23] <jepler> this ^^ is a comp bug
[02:13:40] <jmkasunich> line 47, shouldn't "shift_next = 0" be inside the } ?
[02:14:07] <mozroute> no.
[02:14:17] <SWPadnos> it should probably be shift_next++
[02:14:31] <SWPadnos> oh, maybe not. nevermind
[02:14:47] <mozroute> the logic is a little funky
[02:14:58] <jmkasunich> if (foo) { bar; } blat; else seems weird
[02:15:20] <jmkasunich> is blat supposed to execute when foo is true, or false?
[02:15:22] <mozroute> is it legal to put a line between the if{} and else{}?
[02:15:28] <SWPadnos> yes - you may have a bug because you have two if statements instead of an if/else (lines 25 and 40)
[02:15:30] <SWPadnos> no
[02:15:50] <SWPadnos> if will run one statement only, which can be a compound statement if you use curly braces
[02:16:11] <SWPadnos> if { ... } else { ... }
[02:16:14] <jmkasunich> your braces are somewhat hard to read because you aren't consistent
[02:16:18] <mozroute> that's probably my problem then. I'll have to change my logic.
[02:16:27] <jmkasunich> line 40 has its { on the next line, but line 42 has it on the same line
[02:16:32] <jmkasunich> makes it hard to match them up
[02:16:52] <jmkasunich> we don't get religious about style, but you should be consistent in the same file, for your own sanity if nothing else
[02:16:52] <mozroute> yeah :-) I copied jepler but I normally do the other style with a brace on it's own line
[02:16:58] <SWPadnos> the block between lines 29 and 35 could set shift_count to 1, in which case both that block and the later one (if 0 != shift_count) will also execute
[02:17:32] <SWPadnos> dunno if that's intentional
[02:17:49] <mozroute> ok. the main thing with the way I did it is I need a final run to turn off the latch pin
[02:17:51] <SWPadnos> woohoo! low airfare to Loncoln, NE
[02:18:04] <SWPadnos> only $1873 (down $432)
[02:18:07] <jmkasunich> heh
[02:18:15] <SWPadnos> first calss of course ;)
[02:18:17] <SWPadnos> class
[02:18:25] <jmkasunich> what is the cattle car rate?
[02:18:33] <SWPadnos> probably < $432 ;)
[02:18:36] <jmkasunich> (probably still high - there is no good way to get to lincoln)
[02:18:41] <SWPadnos> heh
[02:19:23] <jepler> here's a version of comp with the bug due to 'variable double output[8];' corrected:
http://emergent.unpy.net/index.cgi-files/sandbox/comp -- the fix will also go in the next bugfix release of emc2.
[02:19:40] <SWPadnos> see - he's the expert ;)
[02:20:04] <CIA-43> EMC: 03jepler 07v2_2_branch * 10emc2/src/hal/utils/comp.g: fix bug with 'variable double output[8];' generating bad C code
[02:20:04] <mozroute> that was fast!
[02:20:12] <SWPadnos> oh, $437.50 :)
[02:20:30] <CIA-43> EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/comp.g: from branch: fix bug with 'variable double output[8];' generating bad C code
[02:21:29] <jepler> the other confusing thing is whether to use () or [] for arrays. Here's the rule: If it's a pin, use (). If it's a variable, use []. Here's why: C normally uses [] for arrays, but access to pins also needs an implicit pointer dereference (like *x=3 vs x=3), and that takes a macro, and that uses () instead of [].
[02:22:05] <jepler> for parameters I guess you also use ()
[02:22:10] <mozroute> thanks. is that in the documentation?
[02:22:17] <jepler> mmmmmmm I dunno
[02:22:32] <mozroute> I didn't see it so I did it the way I did.
[02:22:41] <jepler> obviously nobody has been able to use variable arrays before
[02:22:58] <jepler> because you hit that 'missing semicolon' bug with any declraation of a variable array
[02:24:04] <SWPadnos> the [] vs. () is pretty much explained in the docs
[02:24:12] <jmkasunich> jepler: what is the syntax on lines 9 and 10 of his file?
[02:24:19] <mozroute> what I'm doing might be better done as a parport driver like I think jmkasunich mentioned the other day
[02:24:35] <mozroute> but I figured I'd see if I could get it to work this way first
[02:25:00] <jepler> jmkasunich: that declares an array of parameters numbered 0 through 7 (a total of 8)
[02:25:24] <mozroute> where do I put the "comp" file you uploaded?
[02:25:26] <jmkasunich> on line 10 he put the # right in the middle of the name
[02:25:31] <SWPadnos> there is a typo though - in the table that describes how names are changed between comp, C, and HAL, the trailing _ are left out of the table, even though they're explicitly mentioned in the accompanying text
[02:25:54] <jepler> jmkasunich: yes that is acceptable -- the number is put where the # sign(s) is(are)
[02:26:20] <jmkasunich> ah, ok
[02:27:01] <jepler> mozroute: in a terminal in the directory where you downloaded the file 'comp', run this: 'chmod +x comp; sudo mv comp /usr/bin'. Enter your password when prompted, that command modifies the comp executable program installed by the emc2-dev package.
[02:27:22] <jepler> mozroute: after that when you run comp you should get the bugfixed version
[02:27:31] <jepler> SWPadnos: I'm not sure I understand what you're saying about the table
[02:27:59] <SWPadnos> in section 1.4 "Syntax", the third line of the table should have "x_y_z_" as the C identifier, I think
[02:28:15] <jepler> SWPadnos: oh -- yes, I think you're right
[02:28:17] <SWPadnos> since it says above that "a trailing '_' is retained"
[02:28:47] <SWPadnos> is HALNAME in that table the "comp name"?
[02:29:02] <SWPadnos> ah yes - nevermind
[02:29:31] <CIA-43> EMC: 03jepler 07v2_2_branch * 10emc2/docs/src/hal/comp.lyx: some doc improvements prompted by irc discussion
[02:29:52] <CIA-43> EMC: 03jepler 07TRUNK * 10emc2/docs/src/hal/comp.lyx: from branch: doc improvements
[02:30:04] <SWPadnos> cool, thanks
[02:30:37] <CIA-43> EMC: 03jepler 07v2_2_branch * 10emc2/debian/changelog: note items fixed
[02:31:30] <jepler> any other unanswered questions I can tackle before I wander off?
[02:31:43] <SWPadnos> hmmm
[02:32:00] <mozroute> the file compiles fine now
[02:32:27] <SWPadnos> if a train leaves Chicago traveling westbound at 125 MPH, and another train leaves New York, when does the train catch up with the other train?
[02:32:44] <SWPadnos> or something like that
[02:32:49] <mozroute> I moved the shift_next = 0 line up above the if statement and that fixed the last errors
[02:33:36] <jepler> SWPadnos: why are you talking about coming to lincoln?
[02:33:55] <SWPadnos> because I just got an email with the amazingly low first class airfare :)
[02:34:11] <jmkasunich> there is no such thing
[02:34:26] <SWPadnos> only $1873!
[02:34:27] <cradek> hi folks
[02:34:32] <jmkasunich> hi
[02:34:34] <jepler> heh ok
[02:34:36] <SWPadnos> hi
[02:34:42] <cradek> jepler: I got it to fit
[02:34:50] <jepler> cradek: woo
[02:34:51] <SWPadnos> no need to hide the kids :)
[02:35:10] <jepler> 'night guys
[02:35:15] <SWPadnos> see you
[02:35:24] <cradek> I know you all know this, but whatever box you pick will be too small
[02:35:30] <cradek> goodnight jepler
[02:35:37] <jepler> heh that's true for me and the box is about as big as the mill
[02:35:53] <jmkasunich> what did you fit? the vfd?
[02:36:07] <cradek> servo amp power supply (another pc supply)
[02:36:16] <jmkasunich> how big of a hammer did it take?
[02:36:24] <cradek> tin snips
[02:36:32] <jmkasunich> wait - another PC supply? for the amps?
[02:36:43] <cradek> yes they need +-12
[02:36:45] <SWPadnos> heh. I bought a 30x24x12" box, and as soon as I mounted it on the mill (before, actually), I knew it was too small
[02:36:49] <jmkasunich> oh, control power
[02:37:05] <SWPadnos> didn't even bother putting anything in it, now I have a 42x30x12 to replace it ;)
[02:37:11] <SWPadnos> or similar
[02:37:17] <jepler> SWPadnos: and now the mill is nearly finished?
[02:37:33] <SWPadnos> well, it has an empty control box attached now, yes ;)
[02:37:47] <cradek> shame on you if I have the lathe done first
[02:38:04] <SWPadnos> weeeeelll - err, you have a working mill to help you though
[02:38:15] <cradek> haven't needed it
[02:38:19] <SWPadnos> shhhh
[02:38:23] <cradek> ha
[02:40:13] <SWPadnos> I think I may actually have most of the parts I need - I even have analog servo amps now
[02:40:40] <cradek> cool
[02:40:49] <SWPadnos> oh, and I just nabbed this (not really for the mill):
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=290252685062
[02:42:16] <cradek> neat but I don't see how you can stick it in a 0.87" diameter holder (?) with the air hookups on the top
[02:42:23] <SWPadnos> heh
[02:42:37] <SWPadnos> I'd probably make a quill clamp and use offsets ;)
[02:43:04] <cradek> yeah you'd have to
[02:43:09] <jmkasunich> do you have a suitable compressor?
[02:43:14] <SWPadnos> I think so
[02:43:16] <cradek> 4.5 cfm is easy
[02:43:22] <jmkasunich> continuously?
[02:43:33] <SWPadnos> a good shop compressor is on my list anyway, if the cheeso one I forgot to return sucks too badly
[02:43:42] <SWPadnos> err - blows poorly
[02:44:24] <cradek> yeah I want a nice 60gal dual stage compressor too. too bad about the $800-1000 price tag though
[02:44:39] <SWPadnos> I have a friend making a router-type machine, so this could be a good addition to it
[02:44:49] <cradek> it would be nice to pipe air to everywhere and never worry about it
[02:44:56] <SWPadnos> yeah, the <$100 for the one I got is reasonable though
[02:45:12] <cradek> you won't get 4.5cfm for $100...
[02:45:17] <SWPadnos> it was on sale
[02:45:31] <cradek> oilless vibro-box?
[02:46:00] <cradek> I have one of those pieces of crap on my mill - it is barely adequate to run the brake and change speeds once in a while
[02:46:05] <SWPadnos> it says 5.2@40PSI and 4.2@90PSI
[02:46:16] <SWPadnos> one from an auto parts store
[02:46:20] <SWPadnos> so it's pretty close
[02:46:21] <cradek> huh, I'm surprised
[02:46:31] <jmkasunich> it can say whatever it wants - they lie
[02:46:33] <SWPadnos> it was about $50 or $60 off
[02:46:54] <SWPadnos> yeah - the 3.5HP rating is an obvious lie for a standard plug
[02:47:04] <SWPadnos> though it is just barely possible with a 20A circuit
[02:47:10] <jmkasunich> http://www.truetex.com/aircompressors.htm
[02:48:00] <SWPadnos> it was sufficient for inflating beanstalks for an effect in a play though ;)
[02:48:08] <SWPadnos> then I forgot to return it
[03:07:25] <mozroute> insmod: error inserting '/usr/realtime-2.6.24-16-rtai/modules/rtai_hal.ko': -1 File exists
[03:07:44] <mozroute> I get this when I try to run after loading my comp
[03:07:54] <jmkasunich> trying to start RTAI after its already running?
[03:08:22] <mozroute> /usr/bin/emc_module_helper: Invalid usage with args: remove ubob_outputs
[03:08:39] <mozroute> how do I find that out?
[03:09:20] <SWPadnos> you may get a better error message in dmesg
[03:09:29] <cradek> what is ubob_outputs?
[03:09:40] <mozroute> a comp I just wrote
[03:09:44] <SWPadnos> you can make sure that EMC/RTAI aren't running by doing `halrun -U`
[03:10:35] <mozroute> hmmm, halrun gives me the same kind of error
[03:10:47] <mozroute> looks like emc doesn't like my comp
[03:10:52] <SWPadnos> -U? I think that's supposed to unload RTAI
[03:11:38] <mozroute> /usr/bin/emc_module_helper: Invalid usage with args: remove ubob_outputs
[03:11:39] <SWPadnos> did you check dmesg?
[03:12:39] <SWPadnos> did you install ubob_outputs using `comp --install ubob_outputs.comp` ?
[03:12:51] <mozroute> [12390.663431] I-pipe: Domain RTAI registered.
[03:12:51] <mozroute> [12390.663448] RTAI[hal]: <3.6.1> mounted over IPIPE-NOTHREADS 2.0-04.
[03:12:51] <mozroute> [12390.663451] RTAI[hal]: compiled with gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7).
[03:12:51] <mozroute> [12390.663458] RTAI[hal]: mounted (IPIPE-NOTHREADS, IMMEDIATE (INTERNAL IRQs DISPATCHED), ISOL_CPUS_MASK: 0).
[03:12:51] <mozroute> [12390.663461] PIPELINE layers:
[03:12:52] <mozroute> [12390.663464] e0a17000 9ac15d93 RTAI 200
[03:12:55] <mozroute> [12390.663467] c0383180 0 Linux 100
[03:12:57] <mozroute> [12390.698505] RTAI[malloc]: global heap size = 2097152 bytes, <BSD>.
[03:12:59] <mozroute> [12390.699034] RTAI[sched]: loaded (IMMEDIATE, UP, USER/KERNEL SPACE: <with RTAI OWN KTASKs>, kstacks pool size = 524288 bytes.
[03:13:01] <mozroute> [12390.699044] RTAI[sched]: hard timer type/freq = 8254-PIT/1193180(Hz); default timing: periodic; linear timed lists.
[03:13:04] <mozroute> [12390.699048] RTAI[sched]: Linux timer freq = 250 (Hz), CPU freq = 1792939000 hz.
[03:13:06] <mozroute> [12390.699052] RTAI[sched]: timer setup = 2010 ns, resched latency = 2688 ns.
[03:13:08] <mozroute> [12390.818238] RTAI[math]: loaded.
[03:13:11] <mozroute> [12390.853220] rtapi: no version for "nano2count" found: kernel tainted.
[03:13:13] <mozroute> [12391.058302] config string '0x378'
[03:13:15] <mozroute> [12391.525823] RTAI[math]: unloaded.
[03:13:16] <mozroute> yes, that's how i installed it...
[03:13:28] <cradek> sudo comp ...
[03:13:48] <mozroute> yes, had to do sudo.
[03:14:09] <SWPadnos> ok
[03:14:40] <SWPadnos> can you run an emc config that doesn't use ubob_outputs?
[03:15:06] <mozroute> I wonder if it doesn't like that my component name is ubob_outputs but the file is ubob-outputs?
[03:15:19] <mozroute> no, i tried that too.
[03:15:26] <SWPadnos> bummer
[03:15:43] <SWPadnos> can you use halcmd interactively? (halrun -kf)
[03:15:46] <mozroute> is there a way to kill rtai?
[03:15:55] <SWPadnos> err - halcmd -kf, not halrun
[03:16:13] <SWPadnos> sudo /etc/init.d/realtime stop may work
[03:16:35] <mozroute> halcmd -kf runs. now what do I do?
[03:16:44] <SWPadnos> show all
[03:17:02] <SWPadnos> or show comp
[03:17:41] <SWPadnos> if there are any comps loaded, unload them (unload ubob-outputs or ubob_outputs, whichever is listed)
[03:18:07] <mozroute> http://pastebin.com/d40bc0397
[03:18:31] <SWPadnos> ok, so `unload ubob_outputs` should remove it
[03:18:57] <mozroute> no... it gives the same error. let me paste it...
[03:19:46] <mozroute> http://pastebin.com/d522877df
[03:20:23] <mozroute> could it be a problem in my .hal file?
[03:20:43] <SWPadnos> I'm not sure
[03:21:03] <SWPadnos> cradek - to run module_helper from the command line, do you need sudo?
[03:21:04] <cradek> that error tells you exactly what's wrong...
[03:21:09] <cradek> SWPadnos: no
[03:21:31] <SWPadnos> yes - module_helper doesn't know about ubob_outputs
[03:21:44] <SWPadnos> do you have an installed EMC and a development run-in-place version?
[03:22:18] <cradek> if it doesn't know about it, it must be in one of those whitelist directories
[03:22:26] <cradek> comp --install will put it there
[03:22:34] <mozroute> I installed emc2 with the install.sh script, and installed emc2-dev and build-essential.
[03:22:39] <cradek> I bet you have a version mismatch somewhere
[03:22:56] <mozroute> I installed with sudo comp --install
[03:23:16] <SWPadnos> take a look in /usr/realtime-2.6.24-16-rtai/modules/emc2 and see if ubob_outputs.ko is in there
[03:23:19] <mozroute> ah. jepler just updated comp because of a bug in it. could that be the problem?
[03:23:41] <SWPadnos> also, make sure you're running the 2.6.24-16-rtai kernel
[03:25:01] <mozroute> ubob-outputs.ko is there. does the dash instead of underscore matter?
[03:25:20] <cradek> definitely
[03:25:43] <SWPadnos> yepper
[03:26:05] <SWPadnos> maybe comp shouldn't change the name of the component itself
[03:26:11] <mozroute> hmmm. so I guess the name of the .comp file needs to be exactly the same as the component name inside the file?
[03:26:31] <mozroute> how do I unload it? reboot?
[03:26:34] <SWPadnos> apparently so, but the expert has gone to sleep ;)
[03:26:48] <SWPadnos> no - sudo rmmod ubob-outputs
[03:27:02] <SWPadnos> do an lsmod first, to make sure of the name
[03:27:28] <mozroute> ubob_outputs
[03:31:48] <SWPadnos> sudo rmmod ubob_outputs
[03:31:56] <mozroute> aha! I renamed the file to ubob_outputs.comp and re-installed
[03:32:09] <SWPadnos> heh
[03:32:15] <SWPadnos> now make sure to delete the other one ;)
[03:32:16] <mozroute> had to change the hal file to loadrt ubob_outputs
[03:32:28] <mozroute> emc runs now.
[03:32:34] <SWPadnos> cool
[03:33:30] <mozroute> one output works! I need to double check some stuff
[03:35:42] <SWPadnos> excellent
[04:00:29] <mozroute> question: when I change a pin in a component, when does the output to the parallel port actually get changed?
[04:01:18] <mozroute> at the next tick of the thread it's attached to?
[04:01:33] <SWPadnos> when your driver outputs the new value :)
[04:01:51] <SWPadnos> you need to add the driver output function to a thread for it to run at all
[04:02:11] <mozroute> I did that in my hal file.
[04:02:16] <SWPadnos> ok
[04:02:30] <mozroute> but it is not quite working quite right.
[04:03:19] <mozroute> I think what is happening is that I change the clock signal the next line after I change the data pin
[04:03:46] <SWPadnos> is this an SPI I/O device?
[04:03:51] <mozroute> I'm not sure that the data pin is getting changed before the clock signal tells the chip to read it.
[04:03:55] <mozroute> :-)
[04:04:05] <SWPadnos> it is, about a microsecond ahead of time
[04:04:07] <mozroute> it's a shift register and latch
[04:04:24] <SWPadnos> back-to-back OUT instructions take roughly a microsecond each to execute
[04:04:48] <mozroute> I shift out the 8 bits and then latch it. that way we can control 8 outputs with 3 parport pins
[04:05:07] <SWPadnos> and all that outputting is done each run of the output function?
[04:05:15] <mozroute> I think that's plenty of time.
[04:05:46] <mozroute> no, I change the data and clock lines every other call of the function
[04:05:54] <SWPadnos> ok
[04:06:15] <mozroute> one time I set the data line and put the clock high, the next time I turn the clock off
[04:06:38] <SWPadnos> ok, is clocking done on the falling edge?
[04:06:43] <SWPadnos> (in the chip)
[04:07:07] <mozroute> hmmm, I'm pretty sure it's the rising edge. I'll have to look again
[04:07:50] <SWPadnos> I'd set the clock to the non-active edge in the same iteration that you change the data value, and use the other "phase" to output the active clock edge
[04:08:12] <SWPadnos> I'm assuming that the shift register is a lot faster than the BASE_THREAD ;)
[04:08:55] <mozroute> good idea. yes, I'm sure the register is *way* faster :)
[04:09:30] <mozroute> I may actually write a parport driver, but if this works well enough I might not.
[04:09:59] <mozroute> it's for stuff like spindle, coolant, and other relays
[04:10:10] <SWPadnos> keeping it separate would allow you to stick a shift register on anything with generic I/O (mesa, motenc, ppmc, ...)
[04:10:23] <mozroute> so it doesn't have to be real fast
[04:10:29] <SWPadnos> maybe not ppmc, since it optos for the outputs
[04:10:34] <SWPadnos> ^uses
[04:10:41] <mozroute> maybe so...
[06:38:26] <CIA-43> EMC: 03seb 07TRUNK * 10emc2/docs/man/man9/hostmot2.9: This adds an "enable" pin to the hm2 stepgen.
[06:38:36] <CIA-43> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (TODO hostmot2.h stepgen.c): This adds an "enable" pin to the hm2 stepgen.
[06:43:29] <CIA-43> EMC: 03seb 07TRUNK * 10emc2/configs/hostmot2/ (hm2-2-boards.hal hm2.hal):
[06:43:29] <CIA-43> EMC: This changes stepgen timing parameters from "float seconds" to "u32 nanoseconds".
[06:43:29] <CIA-43> EMC: NOTE: This will break existing configs that change the stepgen timing registers!
[06:43:30] <CIA-43> EMC: 03seb 07TRUNK * 10emc2/docs/man/man9/hostmot2.9:
[06:43:30] <CIA-43> EMC: This changes stepgen timing parameters from "float seconds" to "u32 nanoseconds".
[06:43:32] <CIA-43> EMC: NOTE: This will break existing configs that change the stepgen timing registers!
[06:43:34] <CIA-43> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (hostmot2.h stepgen.c):
[06:43:36] <CIA-43> EMC: This changes stepgen timing parameters from "float seconds" to "u32 nanoseconds".
[06:43:38] <CIA-43> EMC: NOTE: This will break existing configs that change the stepgen timing registers!
[06:47:02] <CIA-43> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (ChangeLog hostmot2.h): Release 0.8.
[15:14:59] <jepler> * jepler kicks CIA-43
[15:15:08] <jepler> cradek: anyway, I checked in that pid stuff to 2.3
[15:15:23] <jepler> that is, TRUNK
[15:15:27] <cradek> yay, thanks
[15:16:00] <cradek> darnit, I don't want to be the one who pushes for new features to be put into the stable branch.
[15:16:09] <jepler> hah
[15:16:17] <cradek> maybe I will end up using a custom build.
[15:16:38] <cradek> I'm resisting because I know how I am - it's so easy to let it get stale
[15:17:24] <cradek> but cvs with local changes on top of the release branch's head helps with that.
[15:17:52] <cradek> I do want this runaway detection though, since I'm jon E's beta tester :-)
[15:44:17] <cradek> I didn't know he made a velocity mode servo amp:
http://jelinux.pico-systems.com/servo.htm
[15:55:30] <skunkworks_> I think that is what stuart used on atleast one of his machines
[16:06:20] <cradek> I know he used elson's amps on the dah-lih but I figured it was the simpler torque mode ones
[16:07:54] <jepler> the lack of silkscreen and the thru-hole ICs makes me think that must be a pretty old product
[16:08:27] <cradek> it says in the text that the picture is of a prototype
[16:08:41] <jepler> hah, "Numerous adjustment pots are on the board"
[16:10:37] <cradek> huh, wonder how I did that, I meant
http://jelinux.pico-systems.com/servo.html
[16:14:28] <skunkworks_> I could be wrong. I think jon figured out 1 loop works just fine ;)
[16:17:08] <cradek> I think I will end up with 102400 counts per inch - I hope that doesn't break anything
[16:17:22] <jepler> what do you think it might "break"?
[16:17:39] <cradek> oh, I was thinking counts per index
[16:17:55] <cradek> but that's lower (I was worried it would break the mesa)
[16:18:04] <jepler> I don't think mesa has any limits on that -- they have nice wide registers for everything.
[16:18:15] <cradek> oh, that's nice.
[16:18:23] <jepler> 32 bits everywhere, I think
[16:18:32] <cradek> I wonder about count rate - looking
[16:19:25] <jepler> in TTL mode .. 1MHz
[16:19:36] <cradek> it will be differential
[16:19:44] <jepler> In RS-422 mode .. 10MHz
[16:20:40] <cradek> looks like it'll be fine
[16:20:41] <jepler> I think that's 586.9in/min and 5969in/min respectively
[16:21:09] <cradek> +- a factor of 4?
[16:21:31] <jepler> if channel A has a frequency of 1MHz I think the quadrature edge rate is 2MHz so it might be *2
[16:22:01] <cradek> I only want to go 200-250 ipm (~ 4ips)
[16:22:36] <jepler> I think that'll be fine
[16:24:03] <cradek> but I couldn't use the same scheme on the spindle (3krpm)
[16:25:15] <jepler> that's about 5MHz edge rate? That should be OK in the RS-422 mode
[16:25:43] <jepler> 3000*102400/minute = 5.12MHz
[16:26:13] <cradek> oh, hmm
[16:26:21] <cradek> thanks for doing math for me
[16:26:22] <jepler> that's only a 2.56MHz signal on channels A and B
[16:31:59] <jepler> there's also the digital filter in the fpga. It looks like it can be set to either require 3 or 15 samples to debounce, and I can't tell which is the default. I'm also not sure whether that's sampled on the 33MHz PCI clock or some other clock.
[16:32:21] <jepler> 33MHz / 3 samples would be OK, 33MHz/15 wouldn't.
[16:32:39] <SWPadnos> hostmot2?
[16:32:43] <jepler> SWPadnos: no, the old one
[16:33:05] <SWPadnos> ok, that's on the PCI clock, unless you use the version that PeteW made for Anders (?) that uses a 100MHz base clock
[16:33:06] <jepler> the hostmot2 driver doesn't have index yet, among other things that chris needs
[16:34:32] <SWPadnos> one minor correction: if the phase A and B rates are 1 MHz, the edge rate is 4 MHz
[16:34:46] <SWPadnos> you get 2 edges per cycle, and two phases with edges
[16:34:49] <jepler> er yes
[16:34:50] <jepler> #define M5I20_ENC_CTL_QUAD_FILTER_4MHZ 0x0200
[16:34:50] <jepler> #define M5I20_ENC_CTL_QUAD_FILTER_11MHZ 0x0000
[16:35:01] <jepler> pCard16->encoderControl[i] = M5I20_ENC_CTL_COUNT_QUADRATURE
[16:35:01] <jepler> | M5I20_ENC_CTL_INDEX_ACTIVE_HI | M5I20_ENC_CTL_QUAD_FILTER_4MHZ
[16:35:01] <jepler> | M5I20_ENC_CTL_LATCH_ON_READ | M5I20_ENC_CTL_LOCAL_CLEAR;
[16:36:14] <jepler> cradek: so you'll also need a parameter for quadrature filter, because I suspect you'll want QUAD_FILTER_11MHz
[16:37:38] <cradek> well heck
[16:37:40] <jepler> (hm I think it's actually 11MHz or 2MHz, not 4MHz since the 'limit' value can be 1111 binary or 0011 binary)
[16:37:57] <cradek> is this machine really strange?
[16:38:35] <SWPadnos> what is saturation supposed to tell you again?
[16:38:56] <cradek> servo runaway
[16:39:11] <SWPadnos> I don't think it's comprehensive enough
[16:39:29] <cradek> is there a counterexample?
[16:39:34] <SWPadnos> it will tell you if an amp dies and is stuck on, but it won't tell you if you lose feedback
[16:40:00] <cradek> I think you are not thinking about it right
[16:40:09] <SWPadnos> sure, motor at rest, within deadband. PID outputs nothing, and the servo amp does a little dance to keep things steady
[16:40:12] <cradek> if an amp dies and is stuck on, you will get unexpected motion (following error)
[16:40:27] <SWPadnos> encoder/tach falls off, and the motor starts moving (slowly maybe), but it's not detected
[16:40:33] <SWPadnos> PID continues to output zero
[16:40:53] <cradek> if feedback goes away, pid I builds up and position is not corrected, pid output quickly saturates with the amp fully on
[16:40:55] <SWPadnos> more of a "walk aweay" in that case :)
[16:41:11] <SWPadnos> PID I doesn't go anywhere when the position is within DEADBAND
[16:41:27] <cradek> then you won't get a runaway (yet) but as soon as you try to move the machine, you will
[16:41:30] <SWPadnos> yet the motor can be creeping off into the woods
[16:42:07] <SWPadnos> there's also a problem with fine-tuning the threshold of what is considered runaway
[16:42:08] <cradek> what do you propose? I don't think you can detect a creep at zero pid output without feedback
[16:42:13] <SWPadnos> no, I agree
[16:42:41] <SWPadnos> a friend and I discussed this at length, and I think we realized that using PID output as an indicator works most of the time, but isn't foolproof
[16:42:51] <cradek> are you proposing an improvement, or just pointing out that it's not possible to perfectly detect every problem (I agree)?
[16:43:32] <SWPadnos> I'll have to have more coffee, and maybe a conversion with that frined, before I can answer your question :)
[16:43:45] <SWPadnos> I think we had a solution, but I don't remember it
[16:43:46] <jepler> "saturated" and "following error" are at least somewhat independent, so overall it improves detection of problems.
[16:44:01] <SWPadnos> I think saturation without motion is the key there
[16:44:12] <SWPadnos> saturation is fine, for seconds at a time
[16:44:19] <SWPadnos> saturation without motion is not fine
[16:44:34] <SWPadnos> at least not for very long, like > 10ms or so
[16:44:37] <cradek> saturation for seconds means you're building up FE
[16:44:48] <cradek> it means something is wrong
[16:44:50] <SWPadnos> or you're asking for something close to the limit of the machine
[16:44:53] <jepler> cradek: or that you're exactly at the limit of the system
[16:44:59] <cradek> yes
[16:45:15] <SWPadnos> G0 should cause saturation for the entire accel/decel phase
[16:45:26] <cradek> it's true you might want to detect saturation + little motion
[16:45:27] <SWPadnos> or be near to it anyway
[16:45:49] <cradek> SWPadnos: I don't agree with "should". it could be near, yes
[16:46:06] <SWPadnos> especially for a servo system, where you design for the continuous case, but use the peak as reserve power
[16:46:12] <jepler> well -- you now get various saturation-related outputs from pid. hook them up however you want, mr integrator man
[16:46:18] <SWPadnos> heh
[16:46:25] <cradek> do I have a theme song?
[16:46:35] <SWPadnos> "that's my theme music"
[16:47:08] <SWPadnos> hey mr integrator man, make a machine for me
[16:47:19] <jepler> I think Mr. Radek the integrator is planning to have his system set up so that acceleration phase and G0 is a good 5% or more below saturation
[16:47:31] <SWPadnos> wuss
[16:47:33] <cradek> definitely
[16:48:28] <SWPadnos> I'm kinda bummed. there was a controller of some sort on eBay that had a Yaskawa servo drive which is matched to a 200W motor I have
[16:48:45] <cradek> actually with velocity mode amps I don't think you will see anything special in the pid output during accel
[16:48:46] <SWPadnos> but the item is no longer for sale (it didn't sell), and the seller has nothing listed at the moment
[16:49:34] <SWPadnos> with V mode, I think FE will trip before saturation detection
[16:50:09] <cradek> in what kind of failure?
[16:50:09] <SWPadnos> for torque mode, you can use a saturation output (or percent of full scale) for a lot of things, like adaptive feed override
[16:50:29] <SWPadnos> if there's no feedback to EMC, FE will trip after a few servo cycles
[16:51:00] <cradek> only if emc commands a move longer than the FE limit
[16:51:10] <SWPadnos> if the amp is stuck on, then the PID output may be irrelevant
[16:51:39] <SWPadnos> if the amp is stuck on and there's no feedback to EMC (which can happen if the amp loses feedback also)
[16:52:02] <SWPadnos> then you could be outputting zero, and the amp will be screwed up and doing something other than what you asked for
[16:52:58] <cradek> yes, then you get FE
[16:53:10] <cradek> assuming you have position feedback
[16:53:24] <SWPadnos> ... and there's no feedback to EMC ...
[16:54:10] <cradek> you mean if the amp shorts out and the encoder falls off at the same time it's bad?
[16:54:33] <SWPadnos> no, cutting the encoder cable will remove feedback to the amp as well, which is the cause of runaway
[16:54:41] <cradek> I'm still muddy about what you're arguing/proposing
[16:55:12] <SWPadnos> I'm thinking about the sources of error: 1) no feedback to EMC, amp still works as commanded
[16:55:16] <cradek> you mean losing the tach and encoder at the same time?
[16:55:27] <SWPadnos> same cable?
[16:56:21] <cradek> it's true that you cannot detect a runaway caused by losing both tach and encoder
[16:57:01] <alex_joni> sure you can
[16:57:05] <SWPadnos> I didn't realize that you had separate feedback sources. I thought the resolver->quadrature board was so you could use the resolver for feedback to EMC (and direct to the amp)
[16:57:10] <alex_joni> you just need to watch the hardware limit switches :)
[16:57:15] <SWPadnos> heh
[16:57:28] <alex_joni> it'll get there fast
[16:57:43] <cradek> tach goes to amp, resolver goes to emc
[16:57:45] <jepler> yes but what if they vanish in the same puff of logic as tach and resolver/encoder?
[16:57:55] <cradek> hahaha
[16:58:03] <alex_joni> jepler: then it falls of
[16:58:07] <alex_joni> off
[16:58:27] <alex_joni> http://www.vibramfivefingers.com/ <- most stupid thing I saw today
[16:58:32] <SWPadnos> well, with dual feedback devices, it's a different story. I'll go make coffee now :)
[16:58:34] <jepler> what if a local fluctuation in the quantum waveform of logic itself changes the truth tables inside the PC to equate true, false, and the floating-point value closest to 1/e?
[16:59:15] <cradek> it's unlikely, but what if the lathe tunnels in the quantum sense out of the shop?
[17:00:02] <SWPadnos> WHAT IF I HAVE NO COFFEE?
[17:00:11] <jepler> OK, SWPadnos wins
[17:00:13] <SWPadnos> heh
[17:00:22] <SWPadnos> it's the capital letters - gets them every time
[17:04:02] <alex_joni> SWPadnos:
http://en.wikipedia.org/wiki/Kopi_Luwak
[17:04:16] <SWPadnos> heh - I've seen "The Bucket List" ;)
[17:05:30] <alex_joni> (=US$48.00) per cup
[17:06:12] <alex_joni> so.. IT'S OK IF YOU HAVE NO COFFEE TODAY
[17:14:37] <SWPadnos> it may be simpler to have the PID output an absolute percentage of full scale - the integrator can then set absolute thresholds as a percentage of FS, and can do timing elsewhere in HAL
[18:00:41] <fenn> WEASEL COFFEE!
[18:52:22] <skunkworks_> jeeze..
http://gmy.news.yahoo.com/v/9344805
[18:54:03] <jepler> * jepler closed the window when it started to blare an avertisement at him
[18:55:39] <alex_joni> lol
[18:55:46] <alex_joni> jepler: didn't miss anything
[18:56:10] <skunkworks_> pretty much saying that with his hydrogen generator he made and put in his suv - he is getting 40mpg
[18:56:15] <skunkworks_> highway
[18:57:47] <cradek> I keep hearing about that scheme.
[18:58:39] <jepler> 40 miles per gallon of .. what?
[18:58:46] <jepler> of gasoline?
[18:59:12] <jepler> what's hydrogen got to do with it?
[18:59:35] <SWPadnos> it makes those cool bubbling effects
[19:00:03] <cradek> I think the theory is you use the electricity generated with your alternator to split some water, and then use the hydrogen along with the usual gasoline to ... do something
[19:00:40] <jepler> oh, so to go 40 miles it takes a gallon of gasoline plus an unknown amount of energy used to split the hydrogen from water?
[19:00:48] <skunkworks_> exactly - you make the hydrogen thru the electrolosis of water and that gets sucked into the intake also
[19:01:20] <alex_joni> bbl
[19:01:21] <jepler> I wonder what happens if you hold an open flame near water that is saturated with hydrogen gas
[19:01:47] <jepler> probably no chance that it just calmly burns on the surface of the water as the H2 comes out of solution
[19:02:21] <skunkworks_> SWPadnos: you should ask your mom. ;)
[19:02:29] <SWPadnos> or my dad ;)
[19:02:57] <cradek> huh, nothing on snopes
[19:03:04] <SWPadnos> jepler, that is what happens (for the most part) when you have lots of methane in the water
[19:08:14] <jepler> cradek: argh I misplaced that hal_m5i20 with index-mask and polarities added
[19:08:41] <jepler> oh wait, I checked one more machine and found it
[19:09:09] <cradek> thanks for doing all this stuff for my machine
[19:09:10] <BigJohnT> passing DC current through water with something to make it more conductive and O2 comes off one side and hydrogen comes off the other electrode.
[19:09:35] <BigJohnT> the problem is it takes more energy to convert than is given off in hydrogen
[19:09:47] <SWPadnos> thus yielding fuel which, when burned, provides slightly less energy than the electricity used for the electrolysis in the first place
[19:10:03] <BigJohnT> actually a lot less
[19:10:26] <skunkworks_> but somehow magicly in a gas engine - it makes it a ton more efficent.
[19:10:28] <skunkworks_> ;)
[19:10:46] <cradek> well the right amount of air mixed with the fuel makes the engine work most efficiently...
[19:10:51] <BigJohnT> yep the magic is getting the money from your pocket to his
[19:10:55] <SWPadnos> something of that sort could be possible, but I'm very skeptical that it's true
[19:11:11] <cradek> that's just how I feel about it
[19:11:59] <BigJohnT> it does produce hydrogen and O2 but the energy to do that is way more than the energy from the hydrogen
[19:12:22] <cradek> sure, there's no doubt you can produce hydrogen with water and electricity
[19:12:26] <BigJohnT> if you made the conversion with solar cells it would be cost effective
[19:13:01] <SWPadnos> it is possible that adding hydrogen to the combustion chamber might allow more fuel to be burned, rather than expelled as some form of waste gas
[19:13:08] <cradek> the real question is how much more efficiently (if any) a gas engine can run with the use of gas + hydrogen
[19:13:13] <SWPadnos> but I don't know the reactions that might do that
[19:13:57] <SWPadnos> it's also possible that it slows the burn or something, allowing more of the enerrgy from the explosion to be transferred to the piston
[19:13:58] <cradek> if (say) it is 10x as efficient if you add .1% hydrogen, you might be very smart to use the car's electricity to make hydrogen
[19:14:19] <SWPadnos> yes
[19:15:20] <jepler> that seems unlikely
[19:15:52] <cradek> of course
[19:16:20] <cradek> but that is the open question, and I don't have an informed answer
[19:16:30] <BigJohnT> it takes about 30 gallons of liquid hydrogen to equal the energy in 10 gallons of gas...
[19:17:02] <BigJohnT> there is not much there that is why the Hindenburg could fly...
[19:20:50] <jepler> cradek: I added the digital filter (4MHz vs 11MHz) as a parameter to this modified version of the mesa driver. if we can verify that each of these works, I'll put it in a 2.2.x release.
[19:21:33] <cradek> did you also add the index mask?
[19:21:35] <jepler> (this makes 4 additions: filter, index mask, and inverts for index and index mask)
[19:21:45] <cradek> slick
[19:21:56] <cradek> that will make my life easier
[19:22:05] <jepler> each one is just a matter of setting a bit in a register, assuming the underlying implementation is good (and I have little doubt it is)
[19:23:29] <BigJohnT> 3,145 MPG car
http://www.fueleconomy.gov/feg/mostEfficient.shtml
[20:06:36] <SWPadnos> hey jepler, remember when we were discussing "when dual-core CPUs get below $150" or something like that?
[20:06:41] <SWPadnos> http://www.newegg.com/Product/Product.aspx?Item=N82E16819103211
[20:07:07] <SWPadnos> it's been what, a year since that discussion?
[20:16:31] <jepler> SWPadnos: oh, I don't remember
[20:16:42] <jepler> what was I going to do when that happened?
[20:16:43] <SWPadnos> maybe it was 2 years ago ;)
[20:16:47] <SWPadnos> buy one, I think
[20:17:46] <jepler> oh
[20:18:25] <jepler> I bought one in January 2007: Athlon 64 X2 3800+ 2.0GHz $139. This spring I got a dual-core laptop.
[20:18:54] <jepler> but maybe when those quad cores get below $150 ...
[20:19:03] <SWPadnos> heh
[20:19:40] <SWPadnos> http://www.newegg.com/Product/Product.aspx?Item=N82E16819103244
[20:19:55] <jepler> ah crap
[20:20:13] <jepler> I've got to take a break from buying stuff, though -- I just bought a new LCD to get rid of my last computer CRT
[20:20:13] <SWPadnos> wait a few days and it won't be on sale any more
[20:20:19] <SWPadnos> cool
[20:20:46] <SWPadnos> I have one CRT remaining, though it looks funny between the LCDs on either side
[20:20:55] <SWPadnos> it still works, so I use it
[20:21:01] <jepler> (I still have a CRT TV for video games)
[20:21:24] <SWPadnos> oh - we tried a friend's wii on my big screen TV - it's pretty nice
[20:21:35] <SWPadnos> 480p, wide mode
[20:28:29] <jepler> this monitor has component inputs and I'm going to try that .. but I think a great deal depends on the LCD's internal scaling. Once place I've seen a wii on an LCD monitor it managed to look simultaneously blocky *and* blurry, which I thought was a real feat..
[20:28:57] <jepler> on the other hand I've also seen a wii on a lcd projector and that looked pretty good
[20:31:29] <SWPadnos> that's closer to what I have: a 1080i 3-CRT rear projection screen (55")
[20:48:43] <jepler> cradek:
http://emergent.unpy.net/index.cgi-files/sandbox/m5i20-polarity-mask-filter.patch
[20:49:10] <jepler> (not that I know whether you need the polarity, but it was an obvious thing to add while I was wallowing around in that code)
[20:52:50] <SWPadnos> typo alert: the _4MHZ is missing in the clear branch of the pEncoder->filter if statement
[20:53:21] <SWPadnos> or it's extra above :)
[20:53:46] <SWPadnos> damn. I could have said "the else clause" and it would have been clearer
[20:54:12] <jepler> #define M5I20_ENC_CTL_QUAD_FILTER 0x0200
[20:54:12] <jepler> #define M5I20_ENC_CTL_QUAD_FILTER_4MHZ 0x0200
[20:54:12] <jepler> #define M5I20_ENC_CTL_QUAD_FILTER_11MHZ 0x0000
[20:54:29] <SWPadnos> oh, that looks like it should be good for some confusion later
[20:54:31] <jepler> clearly I got confused when reading this
[20:54:40] <SWPadnos> or now
[20:54:50] <cradek> neat, thanks. I will try that stuff soon! I can't wait to see it home; the mask should make it work perfectly.
[20:55:27] <SWPadnos> does your encoder have a random positioning of the index pulse? (isn't that what the index mask helps with?)
[21:20:24] <jepler> SWPadnos: on cradek's lathe there's a substantial gearing between the axis and the resolver, so apparently just hitting the coarse home switch + index isn't enough. there's some other thing that is active for less than one resolver revolution that is intended to mask the index in homing.
[21:20:29] <jepler> (at least I think that's the story)
[21:20:39] <SWPadnos> ah, ok
[21:34:46] <alex_joni> good night all
[21:41:56] <rayh> The resolvers didn't have index. I believe that there is a hall switch activated by a magnet embedded in one of the belt pulleys.
[22:12:10] <jepler> rayh: jon elson's resolver to encoder board has an index output.
[22:18:35] <jepler> (aren't resolvers absolute within one revolution? I assume the generation of an index pulse would have something to do with this fact)
[23:49:25] <rayh> jepler, that sounds about right. I did read about the index pulse on Jon's board.