Back
[00:21:21] <jmkasunich2_> seb_kuzminsky: around?
[00:21:49] <jmkasunich2_> I just noticed that the hostmot2 man page says it is a "RTAI driver for the Mesa......"
[00:22:15] <jmkasunich2_> it isn't really RTAI specific is it? shouldn't that say "EMC2" or "HAL" instead of "RTAI"?
[01:00:22] <jmkasunich2_> seb_kuzminsky: is there a magic decoder ring that tells me that "SVST2_8.BIT" contains 2 encoders, 2 pwmgens, and 8 stepgens?
[01:02:24] <jmkasunich2_> looks like SV = servo (1 encoder + 1 pwm) and ST = stepper (1 stepgen), and the numbers are the number of each
[01:02:29] <SWPadnos> isn't that "servos, steppers, 2 connectors, 8 (encoders?)" (I'm not sure what the 8 is for)
[01:02:55] <jmkasunich2_> servos, steppers, 2 of the former, 8 of the latter
[01:03:13] <SWPadnos> no, I think there's some code (for some files anyway) that tells which chip it's for
[01:03:18] <jmkasunich2_> that naming convention assumes that num_pwmgen = num_encoder
[01:03:30] <SWPadnos> since he 5i22 and 7i43 have different gate count options
[01:03:50] <jmkasunich2_> the files are in directories for each board
[01:04:01] <jmkasunich2_> 5i20/SVST2_8.BIT, for example
[01:04:17] <SWPadnos> ok, is there an extra number in the files in the 5i22 and 7i43 dirs?
[01:04:38] <jmkasunich2_> some of them have trailing "B" or "S"
[01:04:55] <SWPadnos> ok, big and small chips
[01:05:32] <jmkasunich2_> actually, _all_ the bitfiles have B or S, it's the pin files that don't have either
[01:05:43] <SWPadnos> hmmm
[01:05:56] <jmkasunich2_> the pinout is probably the same for both cases
[01:05:57] <SWPadnos> I guess the pin names are the same for agiven package
[01:06:00] <SWPadnos> yep
[01:06:27] <SWPadnos> hmmm. brb
[01:06:45] <jmkasunich2_> the 5i20 dir has one bitfile that doesn't fit the SVST(numbers) pattern
[01:06:54] <jmkasunich2_> SVST8_4IM2.BIT
[01:07:01] <jmkasunich2_> I wonder what the IM2 is?
[01:13:01] <jmkasunich2_> hmm, dump_state doesn't seem to be working as advertised
[01:19:37] <SWPadnos> index mask (for the encoders)
[01:19:43] <jmkasunich2_> ah
[01:23:38] <SWPadnos> I wonder if the 2_8 pattern means 2 connectors, 8-bit PWM?
[01:23:50] <jmkasunich2_> no, it means 2 servos 8 steppers
[01:24:00] <SWPadnos> that seems like a strange configuration
[01:24:10] <jmkasunich2_> there is also an 8_4 pattern, and it gives 8 servos and 4 steppers
[01:24:16] <SWPadnos> spindle and ? + steppers for axis motors maybe
[01:24:24] <SWPadnos> hmm, ok. just sounds weird :)
[01:24:31] <jmkasunich2_> spindle and jogwheel maybe
[01:24:37] <SWPadnos> oh, for encoders
[01:25:05] <jmkasunich2_> remember, you can select any number <= the max, so if you only have a spindle, you'd just tell it not to export the 2nd servo
[01:25:17] <SWPadnos> yep
[01:25:23] <jmkasunich2_> so 2_8 can become 1_3 at load time, everything else is IO
[01:25:32] <SWPadnos> are the encoders separate?
[01:25:46] <SWPadnos> or separately enabled anyway
[01:26:18] <jmkasunich2_> I think sp
[01:26:20] <jmkasunich2_> so
[01:26:26] <jmkasunich2_> all I know is what I've been reading in man pages
[01:26:35] <jmkasunich2_> I decided it's time for me to come up to speed
[01:26:45] <SWPadnos> heh
[01:26:47] <jmkasunich2_> so I fired up the box with the 5i20 in it and am playing
[01:26:51] <SWPadnos> cool
[01:27:04] <SWPadnos> I can see the box with the 5i20 in it, so that's a start
[01:27:10] <jmkasunich2_> I thought somebody said that the driver would emit the pinout to dmesg - that isn't happening
[01:27:34] <SWPadnos> I think there's a debug insmod parameter, in addition to needing to strobe the dump pin
[01:27:38] <SWPadnos> or something like that
[01:27:54] <jmkasunich2_> raw_dump is something else (which also isn't working)
[01:27:58] <SWPadnos> ah, ok
[01:28:03] <jmkasunich2_> I suspect MSG_LEVEL, trying that not
[01:28:03] <SWPadnos> debug level?
[01:28:04] <jmkasunich2_> now
[01:28:08] <SWPadnos> heh
[01:29:13] <jmkasunich2_> that's not it - I have all messages on, no output
[01:29:22] <jmkasunich2_> and the pin isn't resetting itself like it should
[01:29:36] <SWPadnos> addf something?
[01:29:41] <SWPadnos> start?
[01:29:48] <jmkasunich2_> already have read, write, and pet_watchdog
[01:29:51] <SWPadnos> (silly stuff I know, but still :) )
[01:30:03] <SWPadnos> heh, pet_watchdog :)
[01:30:08] <jmkasunich2_> threads are running, time params show non-zero and changing numbers
[01:33:24] <SWPadnos> so you're using the debug_modules=1 insmod parameter?
[01:33:35] <jmkasunich2_> I turned on all the debugs
[01:33:56] <jmkasunich2_> I didn't have msg_level set to 4 when I first loaded the driver - that may have prevented the pin list and some other info
[01:34:12] <jmkasunich2_> * jmkasunich2_ tries unload/reload
[01:34:17] <SWPadnos> ok, it uses the MSG_DBG level
[01:36:05] <jmkasunich2_> ok, it printed a book this time
[01:36:09] <SWPadnos> heh
[01:36:32] <SWPadnos> you probably don't need debug_idrom
[01:36:46] <jmkasunich2_> probably don
[01:36:58] <jmkasunich2_> don't "need" any of the debug, I'm exploring right now
[01:39:52] <jmkasunich2_> hm2/hm2_5i20.0: Module Descriptor 5 at 0x047C:
[01:39:52] <jmkasunich2_> hm2/hm2_5i20.0: General Function Tag: 128 ((unknown-gtag-128))
[01:40:00] <jmkasunich2_> that's kind of odd
[01:40:15] <SWPadnos> huh
[01:40:19] <jmkasunich2_> it's the last one, maybe a sentinal value?
[01:40:28] <SWPadnos> shouldn't be unknown then
[01:42:18] <jmkasunich2_> later: hm2/hm2_5i20.0: MD 5: 1x (unknown-gtag-128) v0: ignored
[01:43:06] <SWPadnos> and the others say something like hm2/hm2_5i20.0: General Function Tag: 2(Watchdog)
[01:43:20] <SWPadnos> (or whatever they are)
[01:43:33] <jmkasunich2_> right
[01:45:02] <SWPadnos> it's the LEDs actually
[01:45:18] <SWPadnos> should be supported, but a lot of the tags aren't in the driver it seems
[01:46:18] <SWPadnos> funny - there is no "end of list" tag
[01:47:02] <jmkasunich2_> raw_dump_state is working now too
[01:47:35] <SWPadnos> cool. seems odd that it wouldn't at all if the debug level isn't right at load time (if that was the problem)
[01:49:39] <jmkasunich2_> yeah, something else was broked
[01:49:49] <jmkasunich2_> if (*hm2->raw->hal.pin.dump_state != 0) {
[01:49:49] <jmkasunich2_> hm2_print_modules(RTAPI_MSG_DBG, hm2);
[01:49:49] <jmkasunich2_> *hm2->raw->hal.pin.dump_state = 0;
[01:50:01] <jmkasunich2_> that code would reset the pin regardless of the message level
[01:50:06] <jmkasunich2_> and the pin wasn't resetting
[01:50:17] <SWPadnos> that is odd
[01:51:20] <jmkasunich2_> I wish seb was here
[01:51:25] <jmkasunich2_> I see something else I don't like
[01:51:35] <SWPadnos> whazzat?
[01:51:50] <jmkasunich2_> in the main read function. if the watchdog is tripped, it returns without doing anything
[01:52:08] <jmkasunich2_> the man page says that it continues to count encoder pulses
[01:52:21] <SWPadnos> oh. it should still read but not write. though that depends on whether the hardware actually does anything in the WD tripped state
[01:52:46] <jmkasunich2_> well, I sure hope the encoders keep counting while the WD is tripped
[01:52:58] <SWPadnos> they should, but I haven't checked
[01:53:12] <jmkasunich2_> I assume the hardware does, but if the software isn't reading them, there is a risk of missing a hw overflow
[01:53:18] <jmkasunich2_> don't know how wide the hw register is
[01:53:46] <jmkasunich2_> at one point peter and I talked about splitting a 32 bit register into N bits of count and 32-N bits of timestamp, to provide high-res velocity
[01:54:22] <jmkasunich2_> for moderate N (16-20), there is a non-trivial risk of missing a rollover if the software goes to sleep
[01:54:56] <SWPadnos> I'm looking now. I'll let you know if it's there :)
[01:55:50] <jmkasunich2_> oh, I think I figured out the raw_dump issue - the same "return if watchdog is tripped" issue
[01:56:09] <SWPadnos> oh, ok
[01:56:23] <jmkasunich2_> IMO, watchdog shouldn't affect inputs, only outptus
[01:56:29] <jmkasunich2_> ouputs
[01:56:39] <jmkasunich2_> outputs even
[01:56:53] <SWPadnos> heh, I was just about to type that :)
[01:58:07] <jmkasunich2_> the watchdog is a bit limited - it really only verifies the thread that pet_watchdog is in
[01:58:22] <jmkasunich2_> EMC's userspace part could be long gone and it would have no effect
[01:58:27] <SWPadnos> that's pretty standard.
[01:58:47] <SWPadnos> I don't think I've seen a watchdog that required periodic strobes at different rates
[01:58:58] <SWPadnos> (to different ports obviously)
[01:59:58] <jmkasunich2_> if I didn't have a cat on my lap, I'd go digging for my LED board
[02:00:03] <jmkasunich2_> 7i31 or something like that
[02:01:28] <SWPadnos> I think that LED ID tag was for the onboard 8 LEDs
[02:03:05] <jmkasunich2_> probably
[02:08:08] <SWPadnos> is there a watchdog tripped HAL output pin?
[02:08:13] <jmkasunich2_> yes
[02:08:40] <jmkasunich2_> it's an I/O
[02:08:43] <SWPadnos> ok, and that gets set correctly before the main read function decides it shouldn't do anything?
[02:08:50] <jmkasunich2_> once tripped, you can pet the dog all day and nothing happens
[02:09:00] <jmkasunich2_> you need to write a zero to the pin to re-activiate things
[02:09:08] <SWPadnos> ok, so it's the reset line too
[02:09:53] <SWPadnos> ah, my turn in the shower. bbiab :)
[02:49:16] <seb_kuzminsky> hey yo
[02:49:20] <seb_kuzminsky> jmkasunich: i'm here now
[02:49:36] <SWPadnos> oh hey, me too (and clean - woohoo!)
[02:49:49] <seb_kuzminsky> hi SWPadnos
[02:49:52] <SWPadnos> hi seb
[02:50:03] <seb_kuzminsky> ok you and john were playing with hm2
[02:50:06] <seb_kuzminsky> i read back
[02:50:15] <seb_kuzminsky> any feedback? open questions?
[02:50:15] <jmkasunich2_> hi
[02:50:19] <SWPadnos> he was playing, I was kibitzing
[02:50:19] <jmkasunich2_> yes
[02:50:22] <seb_kuzminsky> hi jmkasunich2_
[02:50:46] <jmkasunich2_> the first on was just a man-page thing
[02:50:47] <jmkasunich2_> RTAI?
[02:51:09] <seb_kuzminsky> oh yeah... i wasnt totally sure about the architecture when i first wrote that, i guess "rtapi" would be more accurate
[02:51:14] <jmkasunich2_> dunno if you read back that far
[02:51:19] <seb_kuzminsky> or "hal" or something
[02:51:26] <jmkasunich2_> HAL really - since it exports pins, etc
[02:51:27] <seb_kuzminsky> what do you think it's a driver for? ;-)
[02:51:54] <jmkasunich2_> anyway, thats just a nitpick
[02:52:04] <seb_kuzminsky> i welcome nitpicks :-)
[02:52:08] <seb_kuzminsky> anything to make it better
[02:52:23] <jmkasunich2_> ok, next nitpick
[02:52:32] <seb_kuzminsky> i'm updating my tree so i can fix this as we talk
[02:52:40] <jmkasunich2_> it would be nice if there was an index or something, to tell you what SVST8_2 means
[02:52:48] <seb_kuzminsky> good idea!
[02:52:54] <jmkasunich2_> maybe a readme in the firmware directory
[02:53:08] <seb_kuzminsky> i think you figured it out: "Servos & Steppers; 8 and 2"
[02:53:17] <SWPadnos> manpage is a good place - that's where people might look when making a HAL file
[02:53:42] <SWPadnos> or at least a pointer to look in the firmware directory
[02:53:45] <seb_kuzminsky> hostmot2.9, in a new "Available Firmware" section maybe
[02:54:05] <seb_kuzminsky> really gotta fix that ^W thing
[02:54:10] <jmkasunich2_> heh
[02:54:13] <SWPadnos> heh
[02:54:33] <jmkasunich2_> I figured it out by loading various firmware and looking at pin lists
[02:54:47] <seb_kuzminsky> i saw you had some trouble seeing the pin lists
[02:54:47] <jmkasunich2_> SWP figured out the IM part (index mask)
[02:54:53] <seb_kuzminsky> right
[02:54:55] <jmkasunich2_> yeah, msg level
[02:55:09] <seb_kuzminsky> it's annoying to me that the default msg level is Err & Warn only
[02:55:14] <seb_kuzminsky> i'd like Info to be on
[02:55:25] <seb_kuzminsky> pin lists are not errors and not warnings
[02:55:53] <SWPadnos> since they're only available when the user explicitly enables them, they may as well be errors
[02:56:04] <SWPadnos> they should be visible
[02:56:08] <jmkasunich2_> right
[02:56:20] <seb_kuzminsky> the pinout is printed even if users dont turn on any of the debug_foo options
[02:56:34] <jmkasunich2_> oh, hmm
[02:56:39] <seb_kuzminsky> the debug_foo stuff is low-level debugging info in addition to the pinouts
[02:56:44] <SWPadnos> well, you could make the message level an insmod parameter
[02:57:02] <jmkasunich2_> anyway, if the user specifically requests something, then it should be printed using MSG_ERR so it will be visible
[02:57:17] <jmkasunich2_> that goes for raw_dump_state too, IMO
[02:57:27] <seb_kuzminsky> why is MSG_INFO off by default?
[02:57:35] <jmkasunich2_> because of log bloat
[02:57:46] <jmkasunich2_> every single pin exported by every HAL module would show up
[02:57:51] <SWPadnos> every run
[02:57:56] <seb_kuzminsky> bah, clean up log printing if there's info stuff that's not informative each time
[02:58:03] <seb_kuzminsky> make the hal stuff DBG?
[02:58:05] <SWPadnos> like pin lists?
[02:58:05] <jmkasunich2_> when we have people pasting dmesg dumps into list emails......
[02:58:08] <LawrenceG> 39
[02:58:15] <seb_kuzminsky> LawrenceG: 42
[02:58:54] <jmkasunich2_> it is ERR, WARN, INFO, DBG, right?
[02:59:01] <seb_kuzminsky> i think so yeah
[02:59:17] <jmkasunich2_> then you are probably right, calls to hal_pin_new_foo should be dbg
[02:59:21] <SWPadnos> huh, DBG is "lower" than info?
[02:59:29] <seb_kuzminsky> SWPadnos: yes
[02:59:35] <seb_kuzminsky> makes sense to me
[02:59:42] <SWPadnos> ah, ok. you don't want to see debug messages unless you're debugging :)
[02:59:51] <jmkasunich2_> info is stuff normal people want, dbg is the nitty-gritty
[02:59:52] <SWPadnos> err, or something like that :)
[03:00:01] <jmkasunich2_> I'm going to make that change to hal_lib.c
[03:00:04] <seb_kuzminsky> i agree
[03:00:06] <seb_kuzminsky> thanks jmkasunich
[03:00:06] <SWPadnos> nevermind me - I was reading it backwards
[03:00:14] <jmkasunich2_> then we'll see how bad the bloat is at info, and probably make that the default
[03:00:26] <seb_kuzminsky> yay ^_^
[03:03:29] <seb_kuzminsky> * seb_kuzminsky kicks CIA-38 preemptively
[03:03:40] <seb_kuzminsky> how do you do that again?
[03:03:48] <SWPadnos> * SWPadnos kicks CIA-38
[03:03:48] <CIA-38> ow
[03:03:58] <seb_kuzminsky> * seb_kuzminsky kicks CIA-38
[03:03:58] <CIA-38> ow
[03:04:00] <seb_kuzminsky> heh
[03:04:06] <jmkasunich2_> * jmkasunich2_ kicks CIA-38
[03:04:06] <CIA-38> ow
[03:04:09] <SWPadnos> * SWPadnos pets CIA-38
[03:04:15] <seb_kuzminsky> altogether now!
[03:04:16] <SWPadnos> * SWPadnos strokes CIA-38
[03:04:20] <jmkasunich2_> jmkasunich hugs CIA-38
[03:04:23] <seb_kuzminsky> * seb_kuzminsky slaps CIA-38
[03:04:25] <SWPadnos> ah
[03:04:29] <SWPadnos> * SWPadnos hugs CIA-38
[03:04:29] <CIA-38> * CIA-38 hugs SWPadnos
[03:04:33] <seb_kuzminsky> lol
[03:04:39] <seb_kuzminsky> ok enough robot love
[03:04:43] <SWPadnos> there was one that makes it purr too :)
[03:04:51] <SWPadnos> or maybe that's the logger
[03:05:07] <jmkasunich2_> well, there are 192 instances of RTAPI_MSG_INFO and 104 of RTAPI_MSG_DBG in my hal/ tree
[03:05:28] <seb_kuzminsky> how many of those are mine? :-)
[03:05:33] <jmkasunich2_> some of those may be in foo^ files, I should really clean those
[03:05:38] <SWPadnos> 182 ;)
[03:05:38] <jmkasunich2_> foo~ I mean
[03:06:17] <seb_kuzminsky> (sidetrack warning: another thing i like about bzr is "bzr clean-tree"), which makes it like a clean checkout at your current revision)
[03:06:46] <seb_kuzminsky> hold on, baby crying
[03:06:48] <SWPadnos> well, CVS can do that too, it's just more than one command
[03:06:54] <jmkasunich2_> in the drivers/mesa-hostmot2 tree, there are 9 INFO and 10 DBG
[03:06:58] <jmkasunich2_> so we can't blame seb_kuzminsky
[03:07:20] <SWPadnos> from the dir above your checkout, rm -rf tree_dir/ && cvs co -d:... :)
[03:07:51] <jmkasunich2_> the reason there are editor leftovers is because I've been editing.....
[03:08:01] <SWPadnos> that makes sense
[03:09:08] <SWPadnos> find . -name *.c | grep -l RTAPI_MSG_INFO | wc -l
[03:09:11] <SWPadnos> err
[03:09:18] <SWPadnos> find . -name "*.c" | grep -l RTAPI_MSG_INFO | wc -l
[03:09:56] <seb_kuzminsky> i'm back, we'll see if that sticks
[03:10:06] <jmkasunich2_> duct tape?
[03:10:16] <seb_kuzminsky> staple gun
[03:10:44] <seb_kuzminsky> brb
[03:11:01] <jmkasunich2_> he's obviously using the wrong tool
[03:11:38] <jmkasunich2_> ok, after clearing editor backups, I have 138 info, 84 dbg
[03:11:53] <jmkasunich2_> that will want a bit of sorting out I think
[03:15:23] <jmkasunich2_> 47 files to be looked at
[03:15:35] <jmkasunich2_> anyway, onward
[03:17:45] <jmkasunich2_> well, when seb gets back
[03:20:16] <seb_kuzminsky> okey im back
[03:20:30] <seb_kuzminsky> uh so... to many INFOs to do the switch now
[03:20:43] <jmkasunich2_> yeah, I'll nibble away at it
[03:20:43] <seb_kuzminsky> so i should move my messages to ERR or WARN if I want them shown
[03:20:55] <seb_kuzminsky> thanks
[03:21:09] <seb_kuzminsky> when i print an err or warn, does it prepend "ERR" or "WARN" to my string?
[03:21:20] <jmkasunich2_> I don't think so, lemme check
[03:22:07] <jmkasunich2_> rtapi.h just says that the level is used to enable/disable
[03:22:12] <jmkasunich2_> checking the .c to be sure
[03:22:22] <seb_kuzminsky> many moons ago i wrote a logging library and i had LOG_ERR and LOG_WARN prepend to the message
[03:22:40] <seb_kuzminsky> i had a LOG_FORCE that made the message go out with nothing prepended no matter what the log level was
[03:23:20] <jmkasunich2_> rtapi_print_msg doesn't prepend anything
[03:23:24] <seb_kuzminsky> ok good
[03:23:30] <jmkasunich2_> if you want unconditional printing, you can use rtapi_print
[03:23:38] <seb_kuzminsky> actually mesa-hostmot2 is worse than you measured
[03:23:49] <seb_kuzminsky> i define shortcut macros and use those
[03:23:54] <jmkasunich2_> lol
[03:24:09] <seb_kuzminsky> a lot wose
[03:24:12] <seb_kuzminsky> *worse
[03:24:22] <jmkasunich2_> lot^2 worse?
[03:24:31] <jmkasunich2_> lot! worse?
[03:24:41] <seb_kuzminsky> does it matter if i use ERR or WARN?
[03:24:45] <seb_kuzminsky> shouldn't, right?
[03:25:05] <jmkasunich2_> well, the default level is ERR, so WARN won't print
[03:25:12] <jmkasunich2_> once we change the default it will be a non-issue
[03:25:14] <seb_kuzminsky> i thought default was 2
[03:25:32] <seb_kuzminsky> n/m, i'll just use ERR for anything i want to show up for now
[03:25:35] <seb_kuzminsky> it'll take me a bit
[03:26:15] <jmkasunich2_> for stuff that should _always_ show up, use rtapi_print(format, args) instead of rtapi_print_msg(level, format, args)
[03:26:26] <seb_kuzminsky> ok
[03:26:33] <jmkasunich2_> dump_state fits that catagory
[03:26:37] <jmkasunich2_> dunno about the pin list
[03:26:45] <jmkasunich2_> other things should probably remain as they are
[03:27:38] <seb_kuzminsky> the debug_foo output i'll make output unconditional
[03:27:56] <seb_kuzminsky> uh that sentence came out hard-to-parse
[03:28:25] <jmkasunich2_> IOW, if it's turned on in the loadrt line, it will be on, you won't have to turn something else on too
[03:28:33] <seb_kuzminsky> exactly
[03:29:06] <jmkasunich2_> that whole level thing didn't turn out exactly as I had hoped
[03:29:19] <jmkasunich2_> for RT, there is a single global level for all modules - good sometimes, bad sometimes
[03:29:39] <jmkasunich2_> for sim, there is NOT such a global level, there is one for every module, and usually no way to change it
[03:29:55] <seb_kuzminsky> in glib there's optional logging contexts that can have different log_levels (and different output mechanisms)
[03:30:13] <jmkasunich2_> bet you a dollar that stuff doesn't work in kernel space
[03:30:21] <seb_kuzminsky> true
[03:30:32] <seb_kuzminsky> but easy to borrow the good ideas and reimplement
[03:30:41] <seb_kuzminsky> if we think it's worth it, which it's prolly not at this point
[03:30:59] <seb_kuzminsky> glib uses an ascii string as the context identifier, and keeps the context states in a hash table
[03:31:02] <seb_kuzminsky> pretty straightforward
[03:31:25] <jmkasunich2_> cleaning up info vs dbg so info is truly stuff that is informational to a user, not just to a coder, and then making info the default, is probaby the right thing
[03:31:41] <seb_kuzminsky> ok we'll work towards this
[03:31:58] <jmkasunich2_> anyway, the next thing
[03:32:03] <seb_kuzminsky> until we're there, i'll make my "INFO" shortcut macro emit at ERR level ;-)
[03:32:13] <seb_kuzminsky> ok, next thing
[03:32:33] <jmkasunich2_> when the watchdog is tripped, the main read function does pretty much nothing at all
[03:32:52] <seb_kuzminsky> yes, that's intentional, but maybe my intention is buggy :-)
[03:32:54] <jmkasunich2_> I'm thinking that it should continue reading stuff
[03:33:07] <seb_kuzminsky> if the watchdog tripped, we dont truly know the state of the FPGA
[03:33:11] <jmkasunich2_> unless there is some case where reading == danger
[03:33:30] <seb_kuzminsky> i imagined that that meant that we couldnt trust what we were getting back
[03:33:47] <jmkasunich2_> what exactly is this watchdog watching? I thought it was the software
[03:34:17] <jmkasunich2_> happy FPGA, EMC/HAL went south, turn off everything
[03:34:26] <seb_kuzminsky> it's a count-down timer, reset by petting, if it expires then all IO pins become pulled-high inputs
[03:34:39] <seb_kuzminsky> encoder-counting continues working within the fpga
[03:35:01] <jmkasunich2_> but if the internal register overflows, the software doesn't know
[03:35:12] <seb_kuzminsky> yep then we lose count and game over
[03:35:16] <seb_kuzminsky> sucks
[03:35:30] <seb_kuzminsky> i did the watchdog stuff at the same time i did the epp timeout stuff
[03:35:37] <seb_kuzminsky> i think i mixed them up in my head
[03:35:55] <jmkasunich2_> ah, epp timeout means you can't trust the data you are getting from the chip
[03:36:02] <seb_kuzminsky> on epp timeout, you can't trust your copy of the fpga's registers; it might have timed out in mid-read
[03:36:04] <seb_kuzminsky> exactly
[03:36:17] <seb_kuzminsky> the driver treats the two conditions the same
[03:36:21] <seb_kuzminsky> perhaps thats bogus
[03:36:25] <seb_kuzminsky> the recovery is:
[03:36:38] <seb_kuzminsky> tell each module driver to totally reinitialize the FPGA to the state the driver thinks it should be
[03:36:42] <seb_kuzminsky> then continue on our merry way
[03:36:52] <jmkasunich2_> hmm
[03:37:33] <seb_kuzminsky> the watchdog stops motion output
[03:37:42] <seb_kuzminsky> so servos should come to a halt pretty quick
[03:37:44] <jmkasunich2_> IMO the reason for the watchdog is so if someone does "unloadrt all" while the PWM is at 95% and the stepgens are cranking away, those things go to zero
[03:38:08] <seb_kuzminsky> the encoder has a signed 16-bit counter for the count, so it shouldnt overflow
[03:38:35] <seb_kuzminsky> jmkasunich: also for epp failure - you trip over the cable, the machine should stop
[03:38:35] <jmkasunich2_> it will overflow in seconds even on a slow axis
[03:38:45] <seb_kuzminsky> no, because the motors have stopped
[03:38:58] <jmkasunich2_> coasting
[03:39:06] <seb_kuzminsky> hm
[03:39:11] <jmkasunich2_> also, not every encoder is being used to monitor an EMC controlled motor
[03:39:28] <jmkasunich2_> thats one of the things that threw me about the SVST nomenclature
[03:39:30] <jepler> ... this is sometimes called PPPoEoE (PPP-over-Ethernet-over-Ethernet). ...
[03:39:38] <jmkasunich2_> it assumes num_encoders == num_pwms
[03:40:05] <seb_kuzminsky> there's 15 bits of encoder-count magnitude, on a 2 K-line encoder that's what, 8 K revs
[03:40:18] <jmkasunich2_> 8 revs
[03:40:28] <seb_kuzminsky> jmkasunich: oh yea, oops
[03:40:35] <seb_kuzminsky> lol @ seb
[03:40:37] <seb_kuzminsky> ok
[03:40:48] <seb_kuzminsky> so you think encoders should read even during watchdog bite?
[03:40:52] <seb_kuzminsky> easy enough to change
[03:41:06] <seb_kuzminsky> jepler: was that for another channel?
[03:41:10] <jmkasunich2_> all inputs I think, unless we can think of a case where reading = danger
[03:41:30] <jmkasunich2_> btw, I agree with the handling of io errors
[03:41:51] <jepler> seb_kuzminsky: no, just something nutty that I couldn't resist pasting
[03:42:22] <jmkasunich2_> I definitely think that raw_read should still run even after wd trip
[03:42:42] <jmkasunich2_> you might want to use it to troubleshoot the condition that tripped the dog in the first place
[03:43:24] <seb_kuzminsky> maybe. not unreasonable
[03:43:49] <jmkasunich2_> these probably are things that most people won't care about
[03:43:58] <jmkasunich2_> I was just trying to get familiar with the board
[03:44:00] <seb_kuzminsky> the watchdog bites (in my experience) when i unplug the EPP cable and when I shut down realtime
[03:44:12] <seb_kuzminsky> never during normal ops with the PCI boards
[03:44:21] <jmkasunich2_> I should hope not
[03:44:40] <seb_kuzminsky> in either of those cases, reading anything wont work
[03:45:17] <jmkasunich2_> I was doing things manually
[03:45:26] <jmkasunich2_> loadrt hostmot; loadrt hm2_pci
[03:45:36] <jmkasunich2_> 1 second later (before addf), it bit
[03:45:53] <seb_kuzminsky> yeah... that's kind of annoying isnt it
[03:46:57] <jmkasunich2_> keep in mind that the execution of a hal file at startup is not a realtime operation - even if you have loadrt on one line, immediately followed by addf, there is no guarantee that one second won't expire between those two operations
[03:47:07] <seb_kuzminsky> i understand
[03:47:20] <jmkasunich2_> I don't know what the answer to that is
[03:47:27] <seb_kuzminsky> i could make the insmod not start the watchdog, and have the first pet_watchdog start it
[03:47:40] <jmkasunich2_> that is what I was thinking
[03:47:59] <seb_kuzminsky> if the user doesnt call pet_watchdog at all, they just dont get a watchdog
[03:48:01] <jmkasunich2_> the only issue is that if someone omits the addf pet, they have no watchdog at all
[03:48:10] <seb_kuzminsky> great minds think alike :-)
[03:48:18] <jmkasunich2_> that option could be a feature, or a bug, depending on how smart the user is
[03:48:37] <cradek> hi guys
[03:48:42] <seb_kuzminsky> hi chris
[03:48:46] <jmkasunich2_> hi cradek
[03:48:49] <cradek> seb_kuzminsky: I'm going to try hm2 tomorrow. I was going to do it tonight, but I notice it's 10pm.
[03:49:10] <seb_kuzminsky> naw, it's only 8 (in Ca)
[03:49:23] <jmkasunich2_> I'm going to get hm2 (stepper) on my shoptask, no later than during my xmas break from work
[03:49:33] <cradek> neat
[03:49:34] <seb_kuzminsky> i'm looking forward to your feedback cradek :-)
[03:49:37] <jmkasunich2_> hopefully sooner, I have some more ambitious stuff I'd like to do during the break
[03:49:44] <cradek> seb_kuzminsky: I'm looking forward to your help :-)
[03:50:06] <seb_kuzminsky> i'll be on and off irc tomorrow during the day, though i'm more of an email kind of a guy really
[03:50:37] <jmkasunich2_> during the day I'm a "very limited email, no IRC" kind of guy ;-)
[03:50:43] <jmkasunich2_> weekdays that is
[03:50:53] <seb_kuzminsky> cradek: for now run with msg_level=debug :-/
[03:51:03] <cradek> will do
[03:51:05] <seb_kuzminsky> or you miss out on all the output
[03:51:14] <jmkasunich2_> I didn't use much vacation this year, I'm gonna be off from 12/12 thru 1/5 woot!
[03:51:21] <seb_kuzminsky> nice!
[03:51:21] <cradek> jmkasunich2_: wooo
[03:51:39] <cradek> I should do that too - but mine renews in july so it's hard to guess how much to burn this early
[03:52:05] <jmkasunich2_> heck, if it renews in july, take it in june
[03:52:10] <jmkasunich2_> the weather is nicer then
[03:52:23] <cradek> that's the problem - what if it's not convenient then.
[03:52:51] <cradek> but yeah - I should travel in the spring.
[03:53:00] <seb_kuzminsky> in your bus no doubt :-)
[03:53:04] <jmkasunich2_> what I like about taking it now is that the vacation days and the holidays and the weekends all add up
[03:53:46] <jmkasunich2_> 12/13 and 14 = weekend
[03:53:50] <jmkasunich2_> 20 and 21, weekend
[03:53:54] <cradek> seb_kuzminsky: can you summarize in a couple sentences how I figure out what hal pins correspond to the screws on my 7i33/7i37 boards?
[03:53:58] <jmkasunich2_> 24 and 25 holiday
[03:53:58] <jmkasunich2_> etc
[03:54:07] <cradek> something about PIN files ...?
[03:54:16] <seb_kuzminsky> cradek: 2 options
[03:54:30] <jmkasunich2_> cradek: echo 4 >/proc/rtapi/debug, then load the driver and look in dmesg
[03:54:31] <seb_kuzminsky> find the PIN file for your BIT file
[03:54:39] <seb_kuzminsky> or what jmk said :-)
[03:54:52] <jmkasunich2_> you'll still have to refer to the 7i33 board to translate from ribbon cable pins to screw terminals
[03:55:04] <seb_kuzminsky> his solution is better, because it shows you what encoders etc are enabled/disabled
[03:55:18] <cradek> ok, I think the PIN file is missing for the firmware I need
[03:55:30] <seb_kuzminsky> you'll be using the IM2 one, right?
[03:55:42] <seb_kuzminsky> peter never gave me a PIN file for it, sorry
[03:55:47] <cradek> I do need index mask so is that right?
[03:55:52] <seb_kuzminsky> yes
[03:55:59] <cradek> ok
[03:56:03] <seb_kuzminsky> so turn on debugging and insmod the driver and look at the dmesg
[03:56:11] <cradek> ok, that sounds easy enough
[03:56:11] <jmkasunich2_> does the driver rely on the PIN file for the dmesg output, or is that independent?
[03:56:19] <seb_kuzminsky> the driver never sees the pin file
[03:56:29] <seb_kuzminsky> the driver gets all the info from the firmware on the FPGA
[03:56:34] <jmkasunich2_> the info is in the bitfile somewhere - cool
[03:56:42] <seb_kuzminsky> there's this array of Pin Descriptors, one for each IO Pin
[03:57:01] <seb_kuzminsky> the driver loads it in, twiddles the bits to make the pins do what the config modparam says, and prints the result
[03:57:51] <cradek> don't hate me for saying this, but wouldn't it be cool if I could tell it what boards I have hooked to what 5i20 connectors and it would give me pins that correspond?
[03:57:59] <seb_kuzminsky> i hate you
[03:58:03] <cradek> darn.
[03:58:07] <seb_kuzminsky> not really
[03:58:12] <cradek> I thought you might.
[03:58:16] <jmkasunich2_> that doesn't really seem like a driver function
[03:58:17] <seb_kuzminsky> yeah that would be super cool
[03:58:23] <cradek> I bet that would be a huge pain to do
[03:58:49] <seb_kuzminsky> actually... that'd be easy to do, in python in userspace before starting realtime
[03:59:00] <cradek> hmm, a simple hal file could make nicely-named nets for you
[03:59:12] <seb_kuzminsky> have a little window where you say waht anyio board you have, and what daughter boards on what connectors
[03:59:19] <seb_kuzminsky> and it poops out a hal file
[03:59:20] <jmkasunich2_> keep in mind that the pinouts are designed to work with the 7ixx boards
[03:59:25] <seb_kuzminsky> picks a firmware for you and all
[03:59:35] <cradek> jmkasunich2_: I understand it's more generic now
[03:59:39] <seb_kuzminsky> cool idea cradek!
[03:59:57] <cradek> but a lot of users are going to have these boards...
[04:00:12] <jmkasunich2_> cradek: not that generic - the SVST2_8 firmware has two servo (PWM + encoder) channels
[04:00:31] <jmkasunich2_> I'd be astonished (and disappointed) if they weren't pinned out to work on two channels of a 7i33
[04:00:38] <cradek> maybe I can do something to help. I will be converting a working HM4 system.
[04:00:45] <seb_kuzminsky> peter watches out for his own, that's for sure
[04:00:46] <jmkasunich2_> but you still need to know which two, and which connector
[04:01:06] <seb_kuzminsky> by convention, servos come before steppers (following the hint in the name of the BIT file)
[04:01:34] <jmkasunich2_> so SVST8_4 has 8 servos, on the first two cables, and 4 steppers on the last cable
[04:01:40] <seb_kuzminsky> yes
[04:01:59] <jmkasunich2_> I'll be messing with servos over the break too - I plan to order one of peter
[04:02:05] <cradek> currently my index masks are on some of the 7i37 isolated inputs
[04:02:07] <jmkasunich2_> peter's 4 channel 100W/chan servo amps
[04:02:18] <seb_kuzminsky> jmkasunich: that's what i've been testing with
[04:02:34] <cradek> (jepler built this firmware for me)
[04:02:58] <seb_kuzminsky> cradek: i think the index pins are on the first pins of the last connector, in the mumble_IM2.BIT firmware in our tree
[04:03:05] <jmkasunich2_> I also want to experiment with extending the driver - I want to connect serial A/Ds
[04:03:20] <seb_kuzminsky> SPI?
[04:03:26] <cradek> let me go poke my estop button and then I'll load the firmware and see what I get
[04:03:34] <jmkasunich2_> some flavor of serial
[04:03:38] <seb_kuzminsky> lol we're keeping cradek up
[04:03:49] <cradek> heh
[04:03:55] <cradek> I'm not tired **yawwwwnn**
[04:04:42] <seb_kuzminsky> another wizard that'd be cool would let you configure a new firmware image (so many encoders, so many steppers, etc, route the pins here), then click submit and it'd compile it on someone's machines (*cough*peter*) and email you the .BIT file
[04:04:52] <jmkasunich2_> I want an A/D specific driver - the chips I'm looking at can sample at 800Ksps, and I want the FPGA to sum samples and provide the sum and a count of samples, then the driver will divide sum by number, and report the average A/D input over the last mS or whatever the thread period is
[04:05:21] <seb_kuzminsky> jmkasunich: cool...
[04:05:27] <seb_kuzminsky> i think the 5i23 has some LVDS drivers on it
[04:05:36] <jmkasunich2_> seb_kuzminsky: that kind of configurability is what I was aiming for with the m5i2x driver tree, and it was too much for me
[04:05:47] <jmkasunich2_> I don't need LVDS
[04:05:54] <seb_kuzminsky> it's serial ;-)
[04:05:55] <jmkasunich2_> I think the A/Ds clock at 16MHz max
[04:06:29] <seb_kuzminsky> jmkasunich: i think it's doable with the hm2 infrastructure, because each firmware image would be quite restricted
[04:06:30] <jmkasunich2_> one clock, 4 data lines (4 A/Ds), one chip-select
[04:06:48] <cradek> ok, button is in...
[04:06:58] <seb_kuzminsky> cradek: are you on TRUNK?
[04:07:02] <cradek> yes
[04:07:15] <jmkasunich2_> seb_kuzminsky: I'm sure it is - even what I was trying to do is "doable", but I'm not a gui programmer, and I just got bogged down in user interface details
[04:07:17] <seb_kuzminsky> ok, so i know what to commit on when it breaks for you :-}
[04:07:25] <seb_kuzminsky> ugh, ui
[04:07:44] <jmkasunich2_> well, you said the dirty word "wizard" first
[04:07:54] <seb_kuzminsky> was it jepler that did the Axis gui?
[04:08:00] <jmkasunich2_> jepler and cradek
[04:08:03] <seb_kuzminsky> because that looks pretty good to me
[04:08:04] <cradek> jeff and I did it
[04:08:08] <seb_kuzminsky> cool
[04:08:33] <jmkasunich2_> the only gui things I've ever done are halmeter and halscope
[04:08:42] <jmkasunich2_> and both have been polished quite a bit by others since then
[04:08:45] <seb_kuzminsky> i like both those things too :-)
[04:08:48] <seb_kuzminsky> use them all the time
[04:08:58] <seb_kuzminsky> i havent run axis for real yet
[04:09:49] <cradek> wow, you start at the bottom
[04:10:11] <jmkasunich2_> I did exactly the same
[04:10:17] <jmkasunich2_> I worked on rtapi first, then hal, then emc
[04:10:49] <jmkasunich2_> and I just touched the interp for the first time a week or so ago ;-)
[04:12:25] <seb_kuzminsky> i touched command for the first time this week and broke it :-(
[04:12:55] <jmkasunich2_> seb_kuzminsky: regarding the "watchdog times out before you even get started" issue - what if we _require_ the user to set the timeout value, and if its not set, there is no watchdog
[04:13:17] <jmkasunich2_> that is a bit more natural - if you don't say how long of a timeout you want, you get no timeout at all
[04:13:35] <jmkasunich2_> at startup, the timeout value is zero, and that means "no dog"
[04:13:45] <cradek> my first problem is I have /lib/firmware/hm2 already installed by the 2.2 deb. can I call it /lib/firmware/hm2-trunk? or is the path magic?
[04:13:56] <seb_kuzminsky> the path can be anything
[04:13:59] <cradek> ok
[04:14:04] <jmkasunich2_> although there is a length limit
[04:14:06] <seb_kuzminsky> but it can't be longer than 40 bytes (boo)
[04:14:20] <jmkasunich2_> might want hm2rip or something
[04:14:20] <seb_kuzminsky> including the /lib/firmware and the NULL, iirc
[04:14:41] <cradek> ok
[04:15:55] <seb_kuzminsky> i like your watchdog suggestion
[04:15:58] <jmkasunich2_> the length applies to the full path, or to the part you pass in? "/lib/firmware/hm2rip/5i20/SVST8_4IM2.BIT" or "hm2rip/5i20/SVST8_4IM2.BIT"
[04:16:24] <seb_kuzminsky> i dont remember now, hold on
[04:17:05] <jmkasunich2_> the longer of the two paths I just listed is 41 (counting the NULL)
[04:17:17] <seb_kuzminsky> i think it's the part after /lib/firmware/
[04:18:19] <seb_kuzminsky> i think the userspace helper prepends the rest
[04:18:39] <jmkasunich2_> that makes sense
[04:18:42] <jmkasunich2_> and is a lot nicer
[04:18:49] <cradek> ok, I got it loaded
[04:18:54] <seb_kuzminsky> and i think it's 30 bytes not 40...
[04:18:55] <jmkasunich2_> whee!
[04:18:59] <seb_kuzminsky> cool!
[04:19:12] <jmkasunich2_> I read 30 in one of your docs in CVS
[04:19:12] <cradek> index masks are pins 48 to 55
[04:19:16] <cradek> of ... something
[04:19:31] <jmkasunich2_> groups of 24, so that would be the third cable
[04:19:38] <seb_kuzminsky> those are io pin numbers, corresponding to the mesa manual
[04:19:51] <seb_kuzminsky> the pin numbers should be prefixed with the connector name
[04:20:09] <jmkasunich2_> I/O 48 is probably 3rd cable pin 1 or 2
[04:20:15] <jmkasunich2_> dunno if the grounds are on odd or even
[04:20:32] <seb_kuzminsky> pins are odd, grounds are even iirc
[04:20:35] <jmkasunich2_> I/O 49 would be 3rd cable pin 3 or 4, etc
[04:20:54] <cradek> http://timeguy.com/cradek-files/emc/hm2
[04:21:03] <jmkasunich2_> 48 = P3-1, 49 = P3-3, 50 = P3-5, etc
[04:21:15] <seb_kuzminsky> add enable_raw=1 to your config
[04:21:47] <seb_kuzminsky> starting at 698786.185513 is the pin descriptor array we talked about earlier
[04:21:51] <seb_kuzminsky> from debug_pins=1
[04:22:22] <cradek> got it
[04:22:36] <jmkasunich2_> the user-oriented list is at xxx.197179, right?
[04:22:37] <cradek> so with that and the manuals for the 7i3* boards I should be able to tell what's what
[04:22:41] <seb_kuzminsky> the juicy bit is at 689786.192179
[04:23:13] <cradek> oh! that IS juicy.
[04:23:21] <jmkasunich2_> heh
[04:23:39] <seb_kuzminsky> it says "IO PIN P2.000", meaning connector P2, pin 000
[04:23:50] <cradek> so index mask is at the beginning of the last connector. I think that's how it's wired now.
[04:23:52] <jmkasunich2_> seb_kuzminsky: not true
[04:24:05] <jmkasunich2_> I/O Pin P4.051: Encoder #3, pin IndexMask (Input)
[04:24:14] <jmkasunich2_> there ain't no pin 51 on any of those cables
[04:24:22] <seb_kuzminsky> pin 000 in Mesa I/O Pin nomenclature, not connector pin
[04:24:27] <seb_kuzminsky> maybe that's confusing
[04:24:35] <seb_kuzminsky> but that's how it is in mesa's manuals
[04:24:44] <jmkasunich2_> it's confusing when you say "connector P2, pin 000"
[04:25:01] <jmkasunich2_> it is "I/O 000, connector P2, pin 1"
[04:25:05] <seb_kuzminsky> yeah, that is kind of bogus now that you meantion it
[04:25:10] <seb_kuzminsky> i'll change it
[04:25:13] <jmkasunich2_> I/O 51, connector P4, pin 3
[04:25:45] <jmkasunich2_> fwiw, typical nomenclature for connector pins is connector number dash pin number
[04:26:13] <seb_kuzminsky> that'll be a HAL change too... GPIOs in HAL have that as part of the name
[04:26:43] <jmkasunich2_> maybe you want something like "I/O Pin 063 (P4-17): Encoder blah blah"
[04:27:03] <jmkasunich2_> the 063 is the mesa number, use that in the HAL name since it is unique
[04:27:44] <jmkasunich2_> I wasn't suggesting that P4-17 should appear in hal names - this listing can be the translator from Mesa/HAL pins to physical connector pins
[04:28:10] <SWPadnos> I'm not sure it would hurt to use parport-like naming, hm2_5120.0.P2-4-in
[04:28:25] <jmkasunich2_> it would hurt
[04:28:27] <SWPadnos> heh
[04:28:33] <seb_kuzminsky> current hal names are like this: hm2_5i20.0.gpio.P4.071
[04:28:42] <jmkasunich2_> oh, they have P4 in them?
[04:28:56] <SWPadnos> see, doesn't hurt :P
[04:28:56] <seb_kuzminsky> well IO 71 is on P4
[04:29:03] <jmkasunich2_> IMO, if they have a P number, they should use the pin number on that connector
[04:29:09] <SWPadnos> agreed
[04:29:11] <seb_kuzminsky> i agree
[04:29:17] <seb_kuzminsky> they aye's have it
[04:29:25] <jmkasunich2_> use _either_ the 0-71 numbers, _or_ the connector number and its pin, not both
[04:29:26] <SWPadnos> or call it IO071
[04:29:38] <seb_kuzminsky> ok ok already
[04:29:41] <jmkasunich2_> lol
[04:29:44] <SWPadnos> heh
[04:29:56] <SWPadnos> if you'd just do it right the first time ... ;)
[04:30:06] <jmkasunich2_> the problem is some users are already using hal pins of the P4.071 form.....
[04:30:21] <seb_kuzminsky> oh yeah, roberto's gonna love this
[04:30:51] <jmkasunich2_> roberto can take a long walk off the nearest short pier as far as I'm concerned
[04:31:05] <jmkasunich2_> he says he started his project months ago
[04:31:23] <jmkasunich2_> but I don't recall an email from him asking about the state of 7i43 support back then
[04:31:34] <SWPadnos> or for help, forthat matter
[04:31:39] <jmkasunich2_> I bet you would have warned him that it was very beta
[04:32:03] <seb_kuzminsky> oh yeah
[04:32:51] <seb_kuzminsky> oh wait, am i thinking of richard acosta? the "pissed-off" guy
[04:32:54] <seb_kuzminsky> anyway...
[04:33:10] <cradek> he sure got reamed the last couple days. let's move on...
[04:33:23] <seb_kuzminsky> moving on, how's cradek's machine?
[04:33:27] <cradek> I wouldn't let him keep you from improving anything, especially in trunk
[04:33:56] <seb_kuzminsky> yeah, i've been enjoying being lazy and just copying my files from trunk to 2.2 before the releases
[04:33:59] <cradek> if it helps me figure out the pins, all the better :-)
[04:33:59] <seb_kuzminsky> that'll have to stop
[04:34:07] <seb_kuzminsky> or convince jeff to release 2.3 :-)
[04:34:24] <cradek> I really don't expect many more 2.2 releases.
[04:34:41] <cradek> seb_kuzminsky: jeff has not volunteered to be the 2.3 release manager... yet ...
[04:34:47] <seb_kuzminsky> right...
[04:34:54] <jmkasunich2_> you don't want jeff/anyone to release 2.3 until everything is working
[04:35:10] <seb_kuzminsky> he seemed somewhat tired of the job when i met him
[04:35:22] <seb_kuzminsky> speaking of working... how's it going cradek
[04:35:24] <cradek> it's kind of a pain, honestly
[04:35:51] <cradek> I was waiting to hear whether you were going to rename all the hal pins tonight...
[04:36:10] <seb_kuzminsky> naw, i'm still on jmk's bug list, take a number :-P
[04:36:11] <SWPadnos> on that note, I saw a few module types listed in the HM2 VHDL that aren't recognized by the driver (like code 128 (LEDs), which JMK noticed in the dmesg output)
[04:36:29] <seb_kuzminsky> yeah, any modules i havent written drivers for it just ignores
[04:36:37] <SWPadnos> bad seb! :)
[04:36:46] <jmkasunich2_> maybe I'll take a shot at writing a module for the LEDs
[04:36:50] <seb_kuzminsky> naw, good seb, focus on the important stuff first :-)
[04:36:55] <SWPadnos> heh
[04:37:12] <jmkasunich2_> I'll need the practice for my A/D project
[04:37:17] <seb_kuzminsky> the leds should be easy, except for the convoluted driver structure i have right now
[04:37:22] <seb_kuzminsky> it's pretty hairy
[04:37:28] <seb_kuzminsky> not to discourage you or anything
[04:37:39] <seb_kuzminsky> i'm thinking of a better structure for firmware-module drivers
[04:37:49] <jmkasunich2_> that's the point - I can learn the structure on a trivial driver, then I won't be so lost when I'm trying to do something non-trivial
[04:37:52] <SWPadnos> the thing to do may be to put the module type constants in the source, and print the name with some note in the info messages
[04:38:10] <seb_kuzminsky> there's a bunch of stuff that needs to happen in the right order at load time and in the rt functions
[04:38:12] <seb_kuzminsky> it's icky
[04:38:14] <SWPadnos> LEDs (unsupported)
[04:38:29] <SWPadnos> can you make a diagram (if you haven't already)?
[04:38:44] <seb_kuzminsky> i need a module abstraction, i've been thinking about it off and on but haven't done anything about it yet
[04:38:46] <jmkasunich2_> also, if I do the LED driver, I'll find at least some of the places where all those "things" aren't documentecd
[04:39:24] <seb_kuzminsky> you think richard got a reaming, wait till you hear jmk after he tries to work with my code ;-)
[04:39:33] <cradek> ha
[04:39:41] <SWPadnos> heh. la la la la
[04:39:46] <SWPadnos> I can't hear anything :)
[04:39:55] <jmkasunich2_> I bet I've seen worse
[04:39:59] <seb_kuzminsky> it's pretty gross
[04:40:09] <seb_kuzminsky> the problem is that not all modules are created equal
[04:40:14] <seb_kuzminsky> the ioport module is special
[04:40:24] <seb_kuzminsky> it's closely tied to the io pins, which are used by all the other modules
[04:40:30] <jmkasunich2_> yep
[04:40:46] <jmkasunich2_> if module X uses a pin as an output, the io module exports different stuff than if its an input
[04:40:48] <seb_kuzminsky> so it there's a bunch of exceptions for the ioport driver to do its stuff after the other module drivers have done theirs
[04:40:52] <seb_kuzminsky> yeah
[04:41:04] <jmkasunich2_> that non-orthoganality is impossible to avoid I think
[04:41:11] <seb_kuzminsky> i agree
[04:41:19] <seb_kuzminsky> at least i havent found a good way to do it
[04:41:37] <SWPadnos> pins are only "claimed" at insmod time, right?
[04:41:37] <SWPadnos> by the other modules
[04:41:45] <seb_kuzminsky> yes
[04:42:00] <SWPadnos> well, maybe - maybe not
[04:42:24] <SWPadnos> the IOPort module always has an "-in" pin, right (so you can look at an I/O from another module)
[04:42:27] <seb_kuzminsky> if hal allowed dynamic creation and destruction of pins & stuff, it could be done differently (and most of config="blah blah blah" would go away)
[04:42:37] <SWPadnos> that would be a harder case, I think
[04:42:51] <seb_kuzminsky> there's no .in for pins that are outputs (pwm, step, dir, etc)
[04:42:57] <jmkasunich2_> seb_kuzminsky: that kind of stuff has been considered
[04:42:58] <SWPadnos> for IOPort, of course it's harder overall because it can't be done yet
[04:43:00] <jmkasunich2_> HAL 2.0
[04:43:06] <seb_kuzminsky> 2.0, sounds good
[04:43:15] <seb_kuzminsky> we talked about it one night and it seems pretty hairy
[04:43:19] <seb_kuzminsky> big change
[04:43:22] <SWPadnos> yes
[04:43:22] <jmkasunich2_> but so far, the features that it would add haven't seemed worth the work and testing that it would entail
[04:43:57] <jmkasunich2_> I know my ambition level isn't up to making that kind of change
[04:44:12] <jmkasunich2_> I'd rather be working on motor control stuff - I want my A/D converters
[04:44:18] <jmkasunich2_> and three phase PWM
[04:44:18] <seb_kuzminsky> :-)
[04:44:25] <SWPadnos> the thing I'd like it for most would be the ability to have separete, non-conflicting HAL files for different functions
[04:44:55] <SWPadnos> you just add a sum or mux when you need it - no counting by hand and then making sure the "module loader" file runs before the others
[04:44:59] <jmkasunich2_> a hal file that sets up a jogwheel, for example?
[04:45:02] <SWPadnos> sure
[04:45:14] <SWPadnos> with counters / muxes / whatever
[04:45:14] <seb_kuzminsky> that'd be nice
[04:45:21] <SWPadnos> spindle input file
[04:45:27] <cradek> with hm4 I had encoder-read, digital-in-read, [pid], misc-update, dac-write, digital-out-write in that order. now I have just read, [pid], write?
[04:45:28] <SWPadnos> spindle control file (adds a stepgen)
[04:45:29] <jmkasunich2_> that needs "newinst"
[04:45:41] <seb_kuzminsky> cradek: and pet_watchdog
[04:45:43] <SWPadnos> yes - I'm saying what I'd want newinst for
[04:46:25] <jmkasunich2_> somehow adding newinst doesn't seem as disruptive as what seb was talking about
[04:46:38] <cradek> I thought we had newinst already
[04:46:52] <jmkasunich2_> cradek: no, at least not for RT
[04:47:13] <jmkasunich2_> I think there is some code in halcmd that parses the command, but afaik, it doesn't do anything
[04:47:15] <jmkasunich2_> * jmkasunich2_ looks
[04:47:43] <jmkasunich2_> trunk halcmd doesn't understand "help newinst"
[04:47:54] <jmkasunich2_> unknown command
[04:48:06] <jmkasunich2_> must be commented out
[04:48:09] <cradek> it might be disabled - I thought the code was there
[04:48:18] <SWPadnos> it "was" there, I don't think it is any more
[04:48:19] <jmkasunich2_> maybe a partial implementation is in there
[04:48:50] <SWPadnos> or did Jeff just have it on his website?
[04:49:25] <jmkasunich2_> no, there are bits and pieces
[04:49:31] <jmkasunich2_> looks like he was using a /proc entry
[04:49:40] <jmkasunich2_> static void hal_proc_clean(void) {
[04:49:40] <jmkasunich2_> if(hal_newinst_file)
[04:49:40] <jmkasunich2_> remove_proc_entry("newinst", hal_dir);
[04:49:40] <jmkasunich2_> if(hal_dir)
[04:49:40] <jmkasunich2_> remove_proc_entry("hal", rtapi_dir);
[04:49:40] <jmkasunich2_> hal_newinst_file = hal_dir = 0;
[04:49:53] <SWPadnos> ah, ok
[04:50:48] <jmkasunich2_> #if 0 /* newinst deferred to version 2.2 */
[04:50:48] <jmkasunich2_> int do_newinst_cmd(char *comp_name, char *inst_name) {
[04:51:36] <jmkasunich2_> 2.3 is too close, but maybe we should revisit that for 2.4
[04:53:02] <cradek> does halcmd know how to set the rtapi debug level?
[04:53:20] <seb_kuzminsky> loadusr echo 4 >| /proc/rtapi/debug ;-)
[04:53:27] <cradek> loadusr echo 4 > /proc/rtapi/debug sure doesn't work
[04:53:27] <jmkasunich2_> I think the -q -Q -v and -V options to halcmd set it
[04:54:30] <jmkasunich2_> but I think those options might only set the user space level for that instance of halcmd
[04:56:15] <cradek> ok, I hacked something up
[04:56:23] <cradek> loadusr some-script-that-does-it
[04:56:42] <jmkasunich2_> odd, the code contains a -c option for halcmd
[04:56:48] <jmkasunich2_> the manpage doesn't mention what it does
[04:57:00] <SWPadnos> that's for command-line completion options
[04:57:04] <SWPadnos> unimplemented
[04:57:19] <jmkasunich2_> ok
[04:57:59] <jmkasunich2_> completion code baffles me - I had a heck of a time figuring it out when I was investigating a segfault on "halcmd lock"
[04:58:37] <jmkasunich2_> dang - midnight
[04:58:52] <jmkasunich2_> gotta walk the dog and get some sleep - goodnight
[04:59:00] <cradek> goodnight
[04:59:08] <seb_kuzminsky> goodnight jmkasunich i'll get the rest of your feedback some other night (or in email)
[04:59:12] <seb_kuzminsky> thanks
[04:59:25] <SWPadnos> ouch. bedtime sounds good
[04:59:29] <SWPadnos> see you guys later
[04:59:34] <seb_kuzminsky> goodnight SWPadnos
[05:00:16] <CIA-38> EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/hal_lib.c: changed a few things from INFO to DBG to avoid cluttering the log
[05:00:16] <CIA-38> EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/utils/scope_rt.c: changed a few things from INFO to DBG to avoid cluttering the log
[05:00:20] <jmkasunich2_> two down, 52 to go
[05:00:25] <seb_kuzminsky> heh
[05:11:40] <cradek> on P4 I have a 7i37. do I have to set is_output for each of the gpio pins that are numbered 48 through 71?
[05:12:07] <seb_kuzminsky> only the ones you want to drive
[05:12:22] <seb_kuzminsky> gpios default to inputs, which means weakly-pulled-high high-impedance input
[05:12:25] <cradek> the card is 8 output, 16 input
[05:12:42] <seb_kuzminsky> the pins that you want to drive, set gpio.is_output to 1, the others leave alone
[05:12:52] <cradek> ok, so I have to set 8 is_outputs
[05:13:12] <seb_kuzminsky> i dont know the 7i37 pisounds right
[05:13:29] <seb_kuzminsky> uh there's a couple ^W's in there
[05:13:37] <seb_kuzminsky> * should have been
[05:16:28] <cradek> ok, the P4 connector has pins 1 through 47, odds only. these are now P4.048 through P4.071
[05:16:40] <seb_kuzminsky> yes
[05:17:10] <cradek> so I have to make 64-71 outputs I think
[05:17:48] <seb_kuzminsky> those are the last pins on P4, dont you have the index masks starting on 48 , at the beginning of P4?
[05:18:36] <seb_kuzminsky> the firmware has the im's at IO 48-51, that's the start of P4
[05:18:46] <seb_kuzminsky> hope that's where the 7i37 wants them!
[05:18:59] <seb_kuzminsky> P4-{1,3,5,7}
[05:19:04] <cradek> yes I think so
[05:19:25] <seb_kuzminsky> so those are the ones that need to be outputs right?
[05:19:34] <cradek> no, index mask is an input
[05:19:41] <seb_kuzminsky> errr.. right
[05:19:45] <seb_kuzminsky> i'm getting sleepy here!
[05:19:54] <cradek> don't let me keep you up
[05:20:12] <seb_kuzminsky> i still have about an hour in me i think ;-)
[05:21:46] <cradek> ok for P3 they are 40-47
[05:22:00] <seb_kuzminsky> you have another 7i37 on P3?
[05:22:04] <cradek> yes
[05:22:24] <cradek> that's what the old config does
[05:22:26] <seb_kuzminsky> 40-47 are the last 8 IOs on P3, so yes, i think
[05:22:33] <cradek> ok
[05:22:45] <seb_kuzminsky> hope we dont smoke your hardware....
[05:22:53] <cradek> ack, don't say that
[05:28:50] <seb_kuzminsky> when your connection times out i'll email jepler and ask him to check on you
[05:29:30] <cradek> ha
[05:31:05] <cradek> dac-00-gain is now pwmgen.00.scale
[05:31:16] <seb_kuzminsky> sounds right
[05:32:02] <seb_kuzminsky> pwmgen duty cycle is value/scale
[05:32:04] <cradek> hm, there is no dac offset
[05:32:15] <seb_kuzminsky> what's that?
[05:32:54] <cradek> a value added to the input? output? of the dac, to null the amp
[05:33:05] <cradek> looks like mine were zero anyway
[05:33:13] <seb_kuzminsky> oh good :-)
[05:33:14] <cradek> I'm just going through the hal file systematically
[05:33:23] <cradek> I turned the knobs instead :-)
[05:33:35] <seb_kuzminsky> for amps that dont output 0 when the input PWM is 0%? that sounds strange
[05:33:59] <cradek> for amps that don't *see* 0 on their input when the pwm is 0%
[05:34:10] <cradek> ground variation, misadjusted amp
[05:34:14] <seb_kuzminsky> hm
[05:34:28] <seb_kuzminsky> one of those "electrical" things eh?
[05:34:37] <seb_kuzminsky> i'm clueless there
[05:34:39] <cradek> yeah, hardware sucks
[05:35:02] <seb_kuzminsky> have you heard this proverb: "hardware is like an erect penis, it stays up as long as you dont fuck with it"
[05:35:35] <cradek> not a prime-time proverb
[05:35:42] <seb_kuzminsky> i figured it's late enough
[05:35:46] <cradek> quite
[05:36:10] <cradek> here's the procedure I used to null my amps
[05:36:15] <cradek> jumper the velocity input to ground on the amp
[05:36:26] <cradek> turn the knob until the axis stops
[05:36:32] <cradek> turn the knob until the axis stops again
[05:36:35] <cradek> do this some more
[05:36:47] <cradek> now it's settled
[05:36:51] <seb_kuzminsky> it would stop & then start again after a bit?
[05:36:56] <cradek> now hook it up to the mesa, with 0 commanded
[05:37:01] <cradek> marvel at how it's no longer balanced
[05:37:10] <cradek> turn the knob for a while longer
[05:37:14] <cradek> mess with ground wires
[05:37:18] <cradek> turn the knob some more
[05:37:21] <cradek> call it good enough
[05:37:24] <seb_kuzminsky> heh
[05:37:29] <seb_kuzminsky> which amp do you use?
[05:37:33] <cradek> I probably left out some steps
[05:37:40] <seb_kuzminsky> i get the picture
[05:37:46] <cradek> the original ones, they are GE mumble mumble
[05:37:50] <seb_kuzminsky> ah
[05:37:53] <cradek> late-70s technology
[05:38:02] <seb_kuzminsky> i think i see your problem
[05:38:11] <cradek> actually they work great
[05:38:47] <cradek> I had to replace a few parts, to make them tune up nicely
[05:45:56] <seb_kuzminsky> ok i lied i dont have an hour
[05:46:03] <cradek> goodnight :-)
[05:46:10] <cradek> this is just busy-work now I think
[05:46:16] <cradek> at least until it's time for the smoke test
[05:46:19] <seb_kuzminsky> until the excitement of power-on
[05:46:21] <seb_kuzminsky> exactly
[05:46:30] <cradek> that's tomorrow
[05:46:35] <seb_kuzminsky> how's it looking? pretty straightforward so far?
[05:46:35] <cradek> thanks again for your help
[05:47:06] <cradek> once I figured the pattern, and made a cheat-sheet, it's just mostly a matter of replacing all the pin names
[05:47:55] <cradek> the cheat sheet, or possibly a script to do this, would really help others who are trying to move to the new driver
[05:48:43] <cradek> the old driver pretty much used the names silkscreened next to the screws... in a lot of ways this is somewhat less straightforward.
[05:48:48] <seb_kuzminsky> send me a copy of your notes, i'll try to type it up somewhere
[05:49:18] <cradek> I will polish them up for you when it passes the smoke test.
[05:49:34] <seb_kuzminsky> the screws... on the 7i37? or on the 5i20?
[05:50:06] <seb_kuzminsky> or your mystery GE servo amp? :-P
[05:50:44] <cradek> screws on the 7i33/7i37 boards
[05:50:47] <seb_kuzminsky> gotcha
[05:51:13] <cradek> so when are you coming to lincoln?
[05:51:45] <seb_kuzminsky> not sure... i'm going to try to come to the next workshop, but that's somewhere else, right?
[05:51:54] <cradek> yeah, IL somewhere
[05:52:05] <cradek> but if you drive, you'll go through lincoln.
[05:52:21] <seb_kuzminsky> I wonder if my truck would make it to IL...
[05:52:28] <seb_kuzminsky> are you going next year?
[05:52:31] <cradek> surely
[05:52:49] <seb_kuzminsky> cool, maybe i could meet you in lincoln and carpool? split gas etc?
[05:53:01] <cradek> of course, that would be great
[05:53:09] <seb_kuzminsky> sweet!
[05:53:16] <seb_kuzminsky> are you taking your bus?
[05:53:33] <cradek> ummmm I would, but jeff wouldn't be caught dead etc etc.
[05:53:38] <seb_kuzminsky> heh
[05:54:06] <seb_kuzminsky> have a good night, hope it works out, and i'll talk to you tomorrow
[05:54:13] <cradek> ok, thanks, goodnight
[06:23:29] <cradek> whee, emc starts, and things look sane
[06:23:32] <cradek> but now, bedtime
[16:10:32] <seb_kuzminsky> cradek: you still alive?
[16:10:39] <seb_kuzminsky> and your computer?
[16:11:24] <jepler> morning seb
[16:11:31] <jepler> I see you're already thinking ahead to next year
[16:11:42] <seb_kuzminsky> heh
[16:11:45] <jepler> the only problem with carpooling is having enough room left in the car for 3 people after packing all the stuff
[16:11:54] <seb_kuzminsky> right, could be a problem
[16:12:02] <jepler> though if we can just talk chris out of taking both a lathe and a mill, that'll help
[16:12:05] <seb_kuzminsky> if it doesnt work it doesnt work, not the end of the world
[16:12:20] <seb_kuzminsky> maybe we could use my truck - plenty of room for cargo, and it'll fit three people in the cab
[16:12:34] <seb_kuzminsky> hold on, brb
[16:13:11] <jepler> I think I'm about to disappear for there rest of the day anyway
[16:17:41] <cradek> last time, nothing interesting happened with the lathe. unfortunately it's the easier one to transport.
[16:19:27] <cradek> seb_kuzminsky: the inputs look right - I have not tried to bring it out of estop yet.
[16:31:16] <skunkworks_> cradek: are you off today? working in the shop?
[16:56:06] <jepler> 'Or you can try the customary drive-by bug report in the comments section ("I tried it on XYZ distro and it didn't work!") which is almost guaranteed to help no one'
[16:56:10] <jepler> hah
[17:20:17] <seb_kuzminsky> cradek: cool!
[18:34:22] <CIA-38> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/hal/halshow.lyx: fix wandering images
[18:39:43] <CIA-38> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/halshow.lyx: fix wandering images
[19:58:52] <cradek> seb_kuzminsky: is it possible the outputs are inverse of what they were before?
[19:59:54] <cradek> I'm getting my coolant pump (and maybe other things) running as soon as I pull out the estop knob
[20:00:06] <cradek> but I verified that hm2_5i20.0.gpio.P3.046.out is FALSE
[20:00:13] <cradek> net Coolant iocontrol.0.coolant-flood m5i20.0.out-06
[20:00:16] <cradek> ^ was
[20:00:31] <cradek> net Coolant iocontrol.0.coolant-flood hm2_5i20.0.gpio.P3.046.out
[20:00:33] <cradek> ^ now
[20:00:58] <SWPadnos> do the IO pin numbers go in reverse order on the connector now?
[20:01:19] <SWPadnos> oh, the inputs are first - nevermind
[20:03:33] <cradek> I checked the 7i37 manual again - seems like I have it right
[20:03:55] <SWPadnos> yeah - I forgot that the inputs are first, taking the numbers 24-39
[20:04:57] <SWPadnos> I can imagine a change where FALSE = 0 = output low, which is often active
[20:05:08] <SWPadnos> rather than FALSE = "not on"
[20:05:22] <SWPadnos> but I haven't looked at the code
[20:05:27] <cradek> I will try inverting them
[20:05:59] <cradek> there is also is_opendrain
[20:07:32] <cradek> inverting them makes it seem right
[20:07:47] <cradek> but I got FE as soon as I enabled the amps ... so moving on to the next thing
[20:08:30] <SWPadnos> heh
[20:09:12] <cradek> I bet it's the OUTPUT_SCALE = -1 that made the dacs work right with the old driver
[20:09:37] <SWPadnos> oh, that makes sense
[20:13:10] <cradek> nope that wasn't it
[20:13:40] <SWPadnos> did you invert the dir output (is that possible?)
[20:13:51] <SWPadnos> though that should happen with the negative scale
[20:15:02] <cradek> oh there's pwmgen output-type... wonder if that's wrong
[20:16:28] <skunkworks_> are you running the mesa dac daughter board?
[20:16:46] <SWPadnos> that's the 7i37
[20:16:47] <cradek> skunkworks_: yse
[20:16:55] <cradek> looks like it is pwm/dir
[20:17:01] <SWPadnos> quad PWM->analog plus quad encoder conditioning inputs
[20:18:27] <alex_joni> this means we'll have a hostmot2 servo config soon.. yay ;)
[20:20:29] <cradek> looks like output-type defaults to the right thing (1, pwm/dir)
[20:20:38] <alex_joni> interesting concept:
http://haxe.org/doc/intro
[20:25:57] <cradek> I think the dac output is extremely low
[20:26:49] <SWPadnos> alex_joni, I prefer Schweine haxen
[20:27:08] <cradek> maybe the pwm rate is wrong
[20:27:23] <alex_joni> is it reversed too?
[20:43:08] <cradek> duty cycle has a range of +-1
[20:43:12] <cradek> dc = value/scale
[20:43:29] <cradek> my "value" is in volts
[20:43:48] <cradek> so it seems like my scale should be 10 now, not 1
[20:43:58] <cradek> but that will make the output even lower
[20:53:39] <cradek> yeah I'm getting no dac output. wonder what's wrong.
[20:53:45] <cradek> I'll wait for seb!
[20:53:57] <seb_kuzminsky> alex_joni: we already have one, contributed by ted hyde, it's in configs/hm2-servo
[20:53:58] <seb_kuzminsky> cradek: hi!
[20:54:02] <cradek> hey you
[20:54:07] <cradek> you're just in time.
[20:54:09] <seb_kuzminsky> when things start, the pins are inputs, but pulled high
[20:54:18] <seb_kuzminsky> so they'll register as logic 1 to external stuff
[20:54:31] <seb_kuzminsky> set the gpio.is-output to TRUE, then the gpio.out should do what you want
[20:54:58] <cradek> ok, the 7i33 wants those inverted, got that, no problem
[20:55:31] <cradek> I think all my IO is correct now. it comes out of estop and seems right. home/limit switches work.
[20:55:34] <seb_kuzminsky> brb
[20:55:42] <cradek> but I'm not getting any dac output
[20:55:44] <cradek> ok
[21:02:28] <cradek> seb_kuzminsky:
http://timeguy.com/cradek-files/emc/show
[21:02:31] <cradek> ^ my halcmd show
[21:03:35] <cradek> I commanded a small Z move before I did this, and you can see Zoutput (pwmgen 2 value) is 2.3 -- scale is 10, so that should give me duty cycle 2.3/10 = 2.3V on the dac output, which should be moving
[21:04:02] <cradek> but there is no motion
[21:05:05] <cradek> the amps do enable (hooked to the enable output of the 7i33)
[21:05:52] <SWPadnos> does a data dump output internal pwmgen variables?
[21:06:04] <cradek> what is a data dump?
[21:06:18] <SWPadnos> setp hm2_5i20.0.raw.dump_state 1
[21:06:30] <cradek> trying
[21:06:34] <SWPadnos> it'll put a lot of stuff in dmesg, but I'm not sure exactly what :)
[21:06:45] <SWPadnos> if you have the correct debug level
[21:06:57] <SWPadnos> or RTAPI message level
[21:07:08] <alex_joni> did you enable the pwmgen's ?
[21:07:18] <cradek> alex_joni: yes
[21:07:20] <alex_joni> not sure if the old m5i20 driver had enables for the pwmgen's
[21:07:22] <alex_joni> ok..
[21:07:35] <SWPadnos> 11 bit IN TRUE hm2_5i20.0.pwmgen.00.enable <== Xenable
[21:07:44] <seb_kuzminsky> ok im back
[21:07:50] <alex_joni> right..
[21:08:18] <cradek> http://timeguy.com/cradek-files/emc/dump-state
[21:08:45] <seb_kuzminsky> looking
[21:08:55] <alex_joni> pwm_val = 0x006D0000 (109)
[21:09:03] <alex_joni> seems like it's doing something..
[21:09:05] <seb_kuzminsky> axis 2 is getting actuated, the others are not
[21:09:15] <cradek> axis 2 is the one I'm trying to jog
[21:09:32] <seb_kuzminsky> axis 0 and 2 are enabled, 1 is not
[21:09:38] <alex_joni> seb_kuzminsky: lathe
[21:09:42] <seb_kuzminsky> ah
[21:09:42] <alex_joni> only X&Z exist
[21:09:50] <SWPadnos> and spindle, as pwmgen 3 :)
[21:10:07] <cradek> yes pwmgen/dac 1 is not hooked to anything
[21:10:09] <alex_joni> cradek: I don't suppose you have a scope handy
[21:10:29] <cradek> no, it's two rooms away
[21:10:37] <alex_joni> ah, crap :D
[21:10:55] <seb_kuzminsky> what's your hm2_5i20.0.pwmgen.pwm_frequency?
[21:11:32] <cradek> I set it to 10000000 which is what the card wants, but it gets set down to 195309 Hz
[21:11:33] <seb_kuzminsky> your output is 109/(something between 512 and 4096, depending on pwm_freq)
[21:11:59] <alex_joni> 0002FAED hm2_5i20.0.pwmgen.pwm_frequency
[21:12:19] <seb_kuzminsky> you should be seeing ~20% duty cycle on pwmgen.02, but you're seeing nothing?
[21:12:26] <cradek> correct
[21:12:29] <cradek> wellllll
[21:12:35] <cradek> I'm seeing nothing on the output of the 7i33
[21:12:52] <alex_joni> doesn't the 7i33 has some additional enable?
[21:13:07] <cradek> the hostmot2 man page says it turns the correct thing on
[21:13:24] <seb_kuzminsky> oh
[21:13:30] <seb_kuzminsky> param pwmgen.02.scale is 10
[21:13:32] <cradek> the 7i33 also has an amp enable *output* that is working. I assume this comes from the same enable signal
[21:13:37] <seb_kuzminsky> so you should be seeing 2% dc
[21:13:55] <seb_kuzminsky> set .scale to 1 and try again ;-)
[21:14:13] <cradek> value is 2.3
[21:14:18] <cradek> scale is 10
[21:14:23] <cradek> isn't that .23 = 23%?
[21:14:38] <cradek> = 2.3 volts from the 7i33
[21:14:48] <cradek> (it was 1, and it still didn't move. I also tried 0.1 scale)
[21:15:12] <seb_kuzminsky> oh yes, that should be fine
[21:15:43] <cradek> 2.3 volts should be getting somewhere in a big hurry... Even .23 volts would be moving pretty decent
[21:16:26] <SWPadnos> can you measure that voltage with a meter?
[21:16:55] <cradek> yes
[21:17:18] <SWPadnos> uh, does that mean you have measured the voltage and it matches, or you can go get a meter and measure? :)
[21:17:21] <alex_joni> SWPadnos: sounds hard to believe that the 7i33 is a suspect, as it works with the m5i20
[21:17:40] <cradek> a few minuts - requires screwdriver.
[21:17:54] <alex_joni> seems the 7i33 needs an active low enable, it then drives an external enable high
[21:17:56] <SWPadnos> it just makes sense to make sure that what's being used as definitive data is actually definitive
[21:18:43] <seb_kuzminsky> the 7i33 gets its /enable from the 5i20, which gets set to the ! of the .enable HAL pin
[21:19:07] <alex_joni> seb_kuzminsky: right, and that seems ok if the output enable actually turns on the drives chris has
[21:19:52] <SWPadnos> the 7i33 hasn't changed though, so if the PWM is outputting, the 7i33 enable output should be the same as it was using m5i20
[21:20:59] <cradek> dac output does measure zero
[21:21:38] <SWPadnos> so it seems the 7i33 isn't being enabled?
[21:21:42] <seb_kuzminsky> can you put the voltmeter between the 5i20 and the 7i33?
[21:21:44] <cradek> I am not going to make the mistake of messing with any wiring or tuning
[21:21:48] <SWPadnos> heh
[21:22:01] <seb_kuzminsky> or is that inaccessible?
[21:22:25] <seb_kuzminsky> i have a 50-pin ribbon-to-screwterminal bob that's been pretty helpful for this kind of debugging
[21:23:14] <cradek> that looks somewhere between hard and very hard to do
[21:23:18] <alex_joni> cradek: can you measure the amp enable outputs from the 7i33 ?
[21:23:21] <cradek> but it sure does seem like an important data point
[21:23:31] <cradek> alex_joni: the amps do enable - it is easy to hear them
[21:23:47] <seb_kuzminsky> you're on a recent TRUNK, right?
[21:23:53] <cradek> yes updated today
[21:24:00] <alex_joni> then I don't think it's that the 7i33 doesn't enable
[21:24:06] <seb_kuzminsky> alex_joni: i agree
[21:24:10] <seb_kuzminsky> cradek: encoders are working?
[21:24:15] <seb_kuzminsky> the input path is ok?
[21:24:16] <cradek> seb_kuzminsky: yes
[21:24:23] <alex_joni> I checked pin files from
http://timeguy.com/cradek-files/emc/hm2 and it seems like the pins match up with the 7i33
[21:24:35] <cradek> I also checked the pinout
[21:24:49] <alex_joni> P2.019 PWM -> pin 39 on the 7i33
[21:25:16] <alex_joni> P2.021 DIR -> pin 43 on the 7i33
[21:25:39] <cradek> I gave both axes a shove and the DROs changed a tiny bit
[21:25:57] <cradek> I can't move them enough to verify the scaling or anything, but they count
[21:26:04] <seb_kuzminsky> good enough for me
[21:26:11] <seb_kuzminsky> do gpio input work?
[21:26:17] <seb_kuzminsky> gpio outputs?
[21:26:21] <alex_joni> hm2_5i20.0.pwmgen.pwm_frequency <- what units does that use?
[21:26:26] <seb_kuzminsky> Hz
[21:26:48] <alex_joni> 195kHz .. should be fine
[21:26:49] <cradek> yes gpio in/out work fine
[21:27:23] <alex_joni> cradek: you set pwm_frequency to 10MHz?
[21:27:39] <cradek> alex_joni: yes, but it gets reduced to that 195 kHz
[21:27:46] <seb_kuzminsky> the driver clips the pwm_freq to the max supported, which is 192KHz
[21:27:48] <cradek> that must be the max
[21:28:10] <cradek> I wish I had not given back jepler's mesa led board
[21:28:16] <alex_joni> hmm.. not that something strange happens..
[21:28:24] <alex_joni> try setting it lower maybe?
[21:28:42] <alex_joni> cradek: want me to mail you one?.. it'll only be a couple weeks :D
[21:28:47] <cradek> ha
[21:28:54] <SWPadnos> Mesa would be faster
[21:28:58] <cradek> I don't think jeff is home or I'd go get it
[21:29:07] <SWPadnos> and not much more expensive, with shipping :)
[21:29:21] <alex_joni> SWPadnos: free imigrants shipping :D
[21:29:24] <SWPadnos> heh
[21:30:02] <seb_kuzminsky> dumb question, but... do the amps have motor power?
[21:30:09] <seb_kuzminsky> looks like all the EMC2 stuff is set up right
[21:30:43] <alex_joni> cradek: did you try moving X?
[21:30:56] <alex_joni> seb_kuzminsky: they wouldn't enable without power
[21:30:56] <cradek> seb_kuzminsky: all the hardware works
[21:31:06] <alex_joni> and the meter would show more than 0V on the 7i33 outputs
[21:31:18] <cradek> this is a working machine, all I have to do is run the old config
[21:31:31] <alex_joni> cradek: try X with the new config
[21:32:03] <seb_kuzminsky> when i test i often turn off the power supply for the motors, and sometimes forget to turn it back on :-/
[21:32:29] <seb_kuzminsky> but yeah, looks like the 7i33 makes its own +- 10 from the +5 & Ground, so it should be showing output nwo
[21:32:52] <cradek> X seems like it will move very slowly
[21:33:24] <cradek> seb_kuzminsky: on this machine, coming out of estop turns on all the powers sequentially, there are no separate switches
[21:33:34] <seb_kuzminsky> gotcha
[21:33:45] <cradek> the motors "sing" when they're on - it's all alive
[21:33:54] <cradek> I'm going to go look for my scope
[21:33:57] <alex_joni> you still have 1 scale for X?
[21:36:06] <cradek> 10
[21:37:37] <alex_joni> hmm.. so what's the ratio of the output?
[21:37:51] <alex_joni> 20% commanded by the driver .. 0.2V measured?
[21:41:04] <cradek> I'm going to try to scope P2 pin 39 (PWM2)
[21:41:13] <seb_kuzminsky> cool
[21:47:21] <cradek> I see a 200kHz square with reasonable looking DC
[21:47:39] <seb_kuzminsky> ok good
[21:47:44] <cradek> it is 3v tall
[21:47:49] <seb_kuzminsky> yep
[21:48:10] <seb_kuzminsky> that's standard for the spartan 3 mesa uses, afaik
[21:48:11] <cradek> the problem space just got a lot smaller didn't it
[21:48:18] <seb_kuzminsky> should be the same on the old m5i20 config
[21:48:35] <seb_kuzminsky> while you got the cable in your hand...
[21:49:03] <cradek> it seems inverted
[21:49:07] <seb_kuzminsky> can you scope or read /ENA2 on pin 47
[21:49:20] <cradek> as it commands more, the DC gets closer to zero
[21:49:32] <alex_joni> * alex_joni was right
[21:50:12] <cradek> no wait, I'm wrong
[21:50:17] <seb_kuzminsky> oh whew!
[21:50:23] <cradek> some moron had the invert button pressed
[21:50:24] <seb_kuzminsky> that about made my head pop
[21:50:39] <seb_kuzminsky> tell that moron to take his take his finger off ;-)
[21:51:02] <cradek> ok what pin did you want me to check next?
[21:51:21] <seb_kuzminsky> /ena2 on P2.47, should be low
[21:52:14] <seb_kuzminsky> if that's as it aught, then the 5i20 is telling the 7i33 the right stuff
[21:53:09] <cradek> it goes high when the amps enable
[21:53:35] <seb_kuzminsky> it should go low to enable the amps
[21:53:42] <seb_kuzminsky> why does it go high
[21:53:54] <cradek> * cradek checks the invert button
[21:54:14] <seb_kuzminsky> heh
[21:54:44] <cradek> ohhhh wait a minute - am I using a gpio for amp enable?
[21:55:02] <seb_kuzminsky> do you have two enables, one for the 7i33 and one for the amps downstream?
[21:55:39] <seb_kuzminsky> Xenable goes to IO 71 on P4
[21:55:45] <seb_kuzminsky> as well as pwmgen.00.enable
[21:56:13] <seb_kuzminsky> Zenable goes to just pwmgen.02.enable
[21:56:24] <cradek> TRUE hm2_5i20.0.gpio.P4.071.out <== Xenable
[21:56:35] <seb_kuzminsky> but you said the 7i33 wasnt outputting anything
[21:56:40] <cradek> ack, sorry
[21:56:41] <seb_kuzminsky> that doesnt reconcile
[21:56:54] <cradek> say again?
[21:57:19] <cradek> I think my hearing the amps coming on is a result of this gpio
[21:57:24] <cradek> ... not the 7i33
[21:57:31] <seb_kuzminsky> if Zenable goes to pwmgen.02.enable, and pwmgen.02.value drives the PWM pin, then you should be seeing something reasonable on the 7i33 outputs
[21:57:54] <alex_joni> unless Zenable is inverted
[21:57:59] <cradek> but it appears to be inverted
[21:58:31] <seb_kuzminsky> no io pins on p2 are inverted (says the dump_state output)
[21:58:45] <seb_kuzminsky> the pwmgen.02.enable pin is TRUE, says the 'show pins'
[21:58:52] <alex_joni> right.. but they are driven inverted
[21:58:54] <seb_kuzminsky> so the /ena2 should be low, says me
[21:59:02] <alex_joni> same issue as with the GPIO's
[21:59:04] <cradek> but when hm2_5i20.0.pwmgen.02.enable is TRUE, my scope says /ena2 is high
[21:59:28] <seb_kuzminsky> odd
[21:59:39] <cradek> let me test that agani to be sure.
[22:00:05] <cradek> 11 bit IN TRUE hm2_5i20.0.pwmgen.02.enable <== Zenable
[22:00:12] <cradek> scope shows 'high'
[22:00:27] <seb_kuzminsky> dump_state says pwmgen's enable reg is 0x5, which means pwm channels 0 and 2 should be enabled
[22:00:48] <cradek> verified scope is on P2.47
[22:00:56] <seb_kuzminsky> the fpga inverts the bits in the pwm enable register, so 1 in the register should output 0 on the pin, enableing the daugherboard
[22:01:00] <seb_kuzminsky> strange
[22:01:29] <alex_joni> seb_kuzminsky: cradek also pointed out that he had to invert the GPIO's (moving from the m5i20 driver to the hm2 one)
[22:02:02] <cradek> alex_joni: only the outputs, but I think that is expected because 7i37 inverts them again
[22:02:19] <cradek> the inputs matched the sense of the old driver
[22:02:50] <seb_kuzminsky> brb
[22:03:39] <alex_joni> would there be another firmware you could try?
[22:03:53] <alex_joni> you probably use a subset of more than one fw.. right?
[22:04:15] <cradek> I need index mask, so there is only one choice
[22:05:49] <alex_joni> for homing..
[22:05:56] <alex_joni> but to try out the 7i33.. it might help
[22:06:37] <SWPadnos> I think the concern here is that this exact hardware works correctly with hal_m5i20, but doesn't with HM2
[22:06:54] <alex_joni> SWPadnos: hm2+one firmware
[22:07:12] <SWPadnos> +different driver
[22:07:16] <alex_joni> if it works with another firmware, then it might be a problem in the fw
[22:07:22] <alex_joni> else it's probably in the driver
[22:07:25] <SWPadnos> sure, could be
[22:08:07] <cradek> setting pwmgen.02.enable=0 does not make it work (probably disables the pwm part of the pwmgen too)
[22:09:57] <alex_joni> right
[22:12:03] <cradek> brb
[22:19:34] <alex_joni> 0x4400Enable register for PWM. Doesn't actually change PWM but is used for
[22:19:35] <alex_joni> enabling PWM driven devices (the ENA pin). 1 bit per PWM channel.
[22:19:35] <alex_joni> Active high --> '1' means enabled = '0' output pin level.
[22:20:09] <alex_joni> sounds like the pwmgen in the FPGA should keep on going even with enable low
[22:21:27] <alex_joni> but it seems like seb fixed that in the driver:
[22:21:36] <alex_joni> in hm2_pwmgen_prepare_tram_write:
[22:21:37] <alex_joni> if (*hm2->pwmgen.instance[i].hal.pin.enable == 0) {
[22:21:37] <alex_joni> hm2->pwmgen.pwm_value_reg[i] = 0;
[22:21:37] <alex_joni> continue;
[22:21:40] <alex_joni> }
[22:22:12] <alex_joni> cradek: might be easiest to comment out this piece of code, and run again with hm2*.pwmgen.enable low
[22:25:25] <alex_joni> or apply this patch backwards:
http://cvs.linuxcnc.org/cvs/emc2/src/hal/drivers/mesa-hostmot2/pwmgen.c.diff?r1=1.6;r2=1.7;f=h
[22:25:52] <alex_joni> good night all
[22:26:00] <alex_joni> cradek: good luck with this ;)
[22:28:45] <SWPadnos> see you Alex
[22:28:58] <cradek> goodnight
[22:29:12] <alex_joni> * alex_joni has some yuckier things to debug in the morning
[22:33:47] <seb_kuzminsky> cradek: try setp hm2_5i20.0.gpio.P2.023.invert-output to TRUE
[22:33:58] <seb_kuzminsky> that'll flip the /ena2 output pin
[22:37:40] <cradek> I commented out the code that alex found, and set -enable to false, and it runs
[22:39:59] <cradek> are they 10, 11, 22, 23?
[22:42:43] <cradek> yes! setting those inverts makes it work.
[22:43:06] <cradek> it homes!!!
[22:44:21] <cradek> that probably means index mask is working - it would take a lot of luck otherwise
[22:44:54] <seb_kuzminsky> yay
[22:45:04] <seb_kuzminsky> sorry, i'm super busy at the office right now, i'll be back in a bit
[22:45:14] <cradek> :-)
[22:46:30] <cradek> the watchdog works - pops into estop as soon as I exit emc
[22:48:38] <skunkworks_> cool!
[22:49:12] <cradek> wheeee
[22:55:39] <BigJohnT> you guys have all the fun :)
[22:58:13] <cradek> bbl, dinnertime
[22:58:20] <cradek> it appears that everything is working
[22:59:36] <seb_kuzminsky> sweet!
[22:59:45] <seb_kuzminsky> yay cradek's lathe :-)
[23:00:10] <seb_kuzminsky> so the only real issue is that the enable output pins seem to be inverted, is that true chris?
[23:10:35] <cradek> seb_kuzminsky: yes I think so
[23:10:59] <cradek> also, I think the pwmgen's direction is backward from what the 7i33 expects
[23:11:14] <cradek> I had to set all three scales to -10
[23:31:54] <seb_kuzminsky> the enable thing is baffling to me... "it works for me here"
[23:32:08] <seb_kuzminsky> can you send me your hal files and i'll try to reproduce it in my secret lab