Back
[01:00:18] <jmkasunich> hello
[01:04:12] <cradek> hi
[01:04:30] <jmkasunich> you guys were (are?) busy today
[01:04:40] <cradek> we got some more stuff ready for the release, i18n mostly, and I fixed emccalib
[01:04:59] <jmkasunich> I got to sit in a stupid corporage bullshit training session
[01:05:01] <cradek> I think the japanese is screwed up, but it's not like I can fix that
[01:05:06] <jmkasunich> tomorrow too, I'm so excited....
[01:05:10] <cradek> oh I forgot about that... what is it?
[01:05:37] <jmkasunich> "Personal Leadership Excellence" or some such crap (I'm not sure I have the E word right)
[01:06:11] <cradek> oh wow
[01:06:14] <cradek> sounds fascinating
[01:06:27] <cradek> only two days? seems like there would be so much to cover, it might take weeks
[01:06:41] <jmkasunich> don't give them any ideas
[01:07:17] <jmkasunich> never saw so much unadulterated wishy-washy marketing oriented crap in my life
[01:07:33] <jmkasunich> would you believe they are subjecting 11,000 people to that shit?
[01:08:03] <cradek> wasting 176000 man-hours?
[01:08:07] <jmkasunich> yep
[01:08:31] <jmkasunich> plus probably a couple hundred kilobucks to the consulting firm that came up with it
[01:09:15] <jmkasunich> trying to get people to drink the corporate kool-aid
[01:09:16] <cradek> I'm guessing on the average salary, but it's > $2e6 wasted
[01:09:25] <jmkasunich> "The Way Forward"
[01:09:48] <jmkasunich> yep, at least
[01:09:49] <cradek> I'm glad my company's not that big yet. we only have small bouts of bull
[01:10:00] <jmkasunich> I think this is unprecedented
[01:10:08] <jmkasunich> virtually everyone has to take it
[01:10:32] <cradek> I don't understand those things
[01:10:38] <jmkasunich> I canceled due to work travel twice, I was hoping to fall off the radar
[01:10:48] <cradek> I can't imagine anyone comes out of it thinking "now I know how to maximize my excellence" or somesuch
[01:10:58] <jmkasunich> but instead, as the last guy in the dept that hasn't done it, I wound up a large blip on the radat
[01:11:01] <jmkasunich> radar
[01:11:09] <cradek> sometimes I really wonder what HR folks see that we don't.
[01:11:41] <jmkasunich> something to compensate for their almost total irrelevance?
[01:12:05] <cradek> the few things we've had like that become legends and we make jokes about them forever - I suggest you try to just enjoy the BS, enjoy drinking coffee and doodling instead of doing your job
[01:12:15] <jmkasunich> I wish
[01:12:20] <jmkasunich> its "interactive"
[01:12:23] <cradek> haha
[01:12:45] <jmkasunich> break into little groups and try to shovel out the kind of bullshit they want to hear
[01:12:52] <cradek> sorry, you really have my sympathy, but it's still a little funny from here
[01:13:16] <jmkasunich> its funny from here too, but funnier after its over
[01:13:20] <cradek> right
[01:13:23] <cradek> so half done?
[01:13:26] <jmkasunich> yep
[01:13:38] <jmkasunich> tomorrow might be a little less painfull
[01:13:48] <cradek> maybe they'll have donuts
[01:13:51] <jmkasunich> "effective meetings" and "dealing with change"
[01:14:06] <cradek> effective meetings is an oxymoron
[01:14:27] <jmkasunich> the meetings part is crap, I already know that 99% of the time the most effective meeting is either "none" or "go to the guy's desk and talk to him"
[01:14:37] <cradek> send an email
[01:14:52] <cradek> sometimes I think a 5 minute meeting can be useful
[01:14:58] <jmkasunich> the change part will be talking about some major upcoming stuff, that might actually be informative
[01:15:03] <cradek> the usefullness starts to decay sharply at 10 minutes
[01:15:24] <jmkasunich> depends on the people and the topic
[01:15:30] <jmkasunich> something like a design review takes time
[01:15:48] <cradek> we're in different professions
[01:17:21] <jmkasunich> you don't ever have anything like a design review?
[01:17:38] <cradek> I guess not
[01:17:54] <cradek> I think we just skip the design phase of everything :-/
[01:18:09] <cradek> that takes up valuable man-hours, you know
[12:21:07] <alex_joni> morning ray
[12:37:42] <rayh> Hi alex. off editing this morning.
[12:37:55] <rayh> I see we got a new testing. Downloading now.
[12:39:15] <alex_joni> * alex_joni goes home
[12:39:23] <alex_joni> rayh: I'll be back later..
[12:39:46] <rayh> okay.
[13:18:08] <cradek> hi guys
[13:38:20] <rayh> I Chris. Just got the upgrade and will try running it this afternoon.
[13:41:37] <cradek> rayh: I made my best guesses about emccalib
[13:41:58] <cradek> it (and halconfig) are not well translated but it basically works
[13:43:06] <cradek> also, some things are broken in halconfig, specifically the modify tab, could you remove the tab on the branch if it won't be working soon?
[13:44:04] <cradek> also maybe you could call out to the translators and have them attack halconfig/emccalib
[13:44:09] <rayh> Modify? It was working when I last committed it. Let me test here.
[13:44:16] <cradek> I think japanese in tkemc is totally wrong, but it's hard to be sure
[13:44:34] <rayh> That was fenn's work I think.
[13:44:37] <cradek> rayh: I think the symptom was when I go to the modify tab and click anything in the tree, it errors
[13:44:49] <rayh> Tom did the chinese version. I've seen it but what do I know.
[13:44:58] <cradek> yeah that's how I am too
[13:45:13] <cradek> I'll ask fenn when I see him around.
[13:45:41] <rayh> Good. I've got an other hour's editing then will test the halconfig --modify.
[13:59:40] <alex_joni> * alex_joni is back
[13:59:43] <alex_joni> hi guys
[13:59:48] <cradek> hi alex
[13:59:58] <alex_joni> hey chris.. how goes it?
[14:00:10] <cradek> it's looking up today
[14:00:43] <alex_joni> heh, nice ;)
[14:00:49] <alex_joni> I'm at my new desk..
[14:01:00] <alex_joni> nice shiny and completely empty.. well besides my laptop
[14:01:01] <alex_joni> :D
[14:01:02] <cradek> yay
[14:01:11] <alex_joni> it'll never look as good again :(
[14:01:22] <cradek> I want a new desk too, but I don't know what to do with all the stuff in the old desk
[14:01:26] <cradek> what's your secret?
[14:02:22] <alex_joni> it's still there :(
[14:02:27] <alex_joni> I need to move it over here
[14:03:02] <cradek> maybe I should empty mine into a box and put it in the basement, and only dig something out if I need it
[14:03:18] <cradek> then in a few years, throw away the box without looking inside
[14:12:19] <alex_joni> yeah, I've done that a few times
[14:12:26] <alex_joni> but I never got to the throwing part :)
[14:13:13] <cradek> maybe I'd just write the date on the outside and leave it for the archaeologists
[14:13:21] <alex_joni> lol
[14:13:29] <alex_joni> bury it in stainless containers
[14:13:29] <alex_joni> :D
[14:32:14] <rayh> I'm a bit confused by what I'm seeing. Is LANGDIR the new way of finding the language stuff?
[14:34:43] <cradek> yes, I think it comes from configure
[14:34:55] <rayh> Okay.
[14:36:05] <rayh> I see the error.
[14:36:12] <jepler> I haven't looked, but I'm not sure that's right.
[14:36:23] <rayh> Don't know why i didn't commit the fix for it.
[14:36:28] <jepler> At least when running installed, the .mo files and the tcl message catalog files will be in different directories
[14:36:40] <cradek> oh ok
[14:36:41] <alex_joni> jepler: both are handled separately
[14:36:44] <cradek> I know nearly squat about it
[14:36:46] <jepler> so the location can't be named by the same variable
[14:36:54] <jepler> I haven't actually looked at these recent changes though
[14:36:56] <alex_joni> what variable?
[14:37:09] <alex_joni> all the variables refer to tcl stuff
[14:37:10] <jepler> LANGDIR is what ray mentioned a minute ago
[14:37:24] <alex_joni> maybe EMC2_LANGDIR
[14:38:12] <jepler> the other problem is that we consistently try environment variables set by the sds2 script first, but then someone complains that something doesn't work when starting something from the commandline (halscope or halcmd usually)
[14:38:41] <cradek> I think halscope and halcmd are now compiled with the paths
[14:38:56] <cradek> it's these tcl programs that depend on the environment that are the problem.
[14:39:42] <alex_joni> cradek: I think we could solve them by making them all .in's
[14:39:51] <alex_joni> but that's not the nicest way
[14:39:51] <cradek> true, but that also sucks
[14:40:17] <jepler> I was working on having a single emc.tcl.in which would be loaded by all the tcl scripts with a 2-liner turd at the top
[14:40:18] <cradek> and having them source a config file is problematic because where is it?
[14:40:35] <jepler> by looking in a location relative to the tcl script itself, which is what axis now does
[14:41:12] <alex_joni> that sounds sane..
[14:41:17] <cradek> agreed
[14:41:29] <alex_joni> * alex_joni has no idea how tcl sourcing works..
[14:41:37] <cradek> all the turds are different and scattered now, which sucks
[14:42:05] <alex_joni> ok, how about having one config.tcl.in in the same place as tkemc & mini
[14:42:14] <alex_joni> and let that be sourced by the others
[14:42:17] <rayh> Yep. All the folk I deal with only work on a rip version.
[14:42:29] <rayh> rayh does not favor sourcing.
[14:42:35] <alex_joni> rayh: that's a mistake imo
[14:42:43] <cradek> I agree. a big one.
[14:42:52] <alex_joni> rip is ok for developers who know what they are doing..
[14:43:05] <alex_joni> but it's a matter of taste in the end..
[14:43:18] <rayh> It's a matter of finding the files you need to change.
[14:43:20] <alex_joni> you need to get confident in apt before advinsing that..
[14:43:21] <jepler> I don't want to get into an rip-vs-installed debate
[14:43:28] <rayh> and getting the permission to do the changes.
[14:43:37] <jepler> but using tcl "source" also allows us to build a library of useful things for the various tcl/tk programs we have
[14:44:04] <jepler> like "set up the message catalog", "tell me where the wizard gif is", etc
[14:44:10] <rayh> Ah but if we are going to build a library of tcl, we ought to use the library functions available.
[14:44:27] <rayh> I did that a long time ago in emc. Still there I think.
[14:45:22] <jepler> rayh: I've tried on several occasions to understand Tcl packages. I still don't "get" them. But I'd be equally happy with a 2-liner turd that ends 'package require Emc' or 'source $somewhere/emc.tcl'
[14:45:59] <cradek> rayh: if you think something is installed with the wrong permissions, let's talk about it, but if you just don't want anything but rip, let's not.
[14:46:34] <jepler> I believe the logic to determine 'somewhere' is the same in both cases; in the package case, it's used to augment whatever variable 'package require' uses
[14:48:16] <rayh> I presume that in the installed case it would sit in /usr/share/emc/tcl/xxx
[14:52:37] <rayh> I guess I'm not able to get my head around the whole installed system.
[14:52:58] <cradek> learning about it would be time well spent, ask questions and we will help
[14:53:37] <rayh> Where do i18n files normally reside.
[14:54:23] <rayh> Or are we facing a major distro issue.
[14:54:27] <jepler> .mo-format files go under $(prefix)/share/locale. .msg-format files seem to go alongside the .tcl files under lib/
[14:55:01] <rayh> what are the differences between these?
[14:55:18] <cradek> tcl does it differently than everyone else, so it has its own format (msg)
[14:55:39] <jepler> They're two different formats. .msg-format is tcl specific, .mo is unix-specific and is used by programs in C and python (among other languages)
[14:55:58] <rayh> Then why is there any issue about where the tcl files ought to be.
[14:56:38] <rayh> If the reside in a fixed location relative to mini, tkemc, halconfig,tcl and emccalib.tcl why would there be any problem.
[14:57:44] <rayh> are we "ragging" on rayh's use of tickle?
[14:58:12] <jepler> no.
[14:58:15] <rayh> If so write the equivalent abilities in something else and I'm content.
[14:59:14] <rayh> If we need a /usr/share/emc/tcl/lib directory let's make it and populate it.
[14:59:42] <jepler> I agree that if everything the tcl scripts use is in the same relative location then there's no problem
[15:00:01] <jepler> but they're not in the same relative location---images and commands (like halcmd) aren't.
[15:00:16] <rayh> I thought that was why jmk insisted on creating a tcl directory under emc2.
[15:00:29] <rayh> and naming all the files with the .tcl extension.
[15:00:39] <rayh> That is not at all like emc.
[15:01:18] <jepler> I don't know what jmk's thinking was
[15:01:50] <rayh> Make supplied the locations for the tcl source files in emc.
[15:02:33] <rayh> and edited the "unknown plat" references in the tcl when it made the source.
[15:03:27] <jepler> That sounds similar to the "make all .tcl files .tcl.in files" approach mentioned earlier. It destroys one of the main strengths of tcl, that you don't have to 'make' after changing the source.
[15:13:03] <rayh> Where are the internationalization files going now.
[15:13:53] <rayh> I suppose that depends upon
[15:13:56] <rayh> set LANGDIR $TCLDIR/../src/po
[15:13:56] <rayh> if {[info exists env(EMC2_LANG_DIR)]} {
[15:13:56] <rayh> set LANGDIR $env(EMC2_LANG_DIR)
[15:13:56] <rayh> }
[15:14:19] <rayh> so run in place is ../src/po
[15:15:31] <rayh> and it looks like the other is tcl/msgs
[15:16:16] <rayh> Do we use any of these po files other places that tcl?
[15:21:25] <rayh> bbl
[15:25:09] <alex_joni> bbl
[15:33:21] <jepler> can someone who knows shell scripts better than me tell me if the "export"s at the top of all the .tcl scripts can possibly make any difference?
[15:33:45] <jepler> I can't see how they could.
[15:35:38] <jepler> hi flo
[15:36:38] <flo-h> hi
[15:44:00] <jepler> On the mailing list, I mentioned "branches".
[15:44:18] <jepler> Are you familar with the concept of CVS branches?
[15:45:03] <jepler> In emc2, we've created a branch called (I think) v2_0_branch. On v2_0_branch, we will only make bugfixes; on HEAD, it's OK to add new features.
[15:45:39] <jepler> If your changes for the i18n support in emc2 are bugfixes, then they must be checked in twice, once on HEAD and once on v2_0_branch
[15:48:34] <jepler> I can help you with checking out v2_0_branch and merging changes if you want.
[15:49:06] <flo-h> no, I don't know about that
[15:50:17] <cradek> jepler: they seem to be necessary, but please test anyway to make sure
[15:52:41] <jepler> flo-h: branches are just a way in CVS to have two independent but related paths of development.
[15:52:55] <jepler> flo-h: to get a copy of the v2_0_branch of emc2, you run a command like this one:
[15:53:36] <jepler> cvs -d :ext:...:/cvs co -r v2_0_branch -d emc2-branch emc2
[15:54:36] <jepler> flo-h: When fixing a bug, first test and check in your fix on HEAD. Then, when you check it in, note the version number of each file you check in.
[15:55:00] <jepler> flo-h: Then inside emc2-branch, run a command like this one: cvs update -jOLD -jNEW example.po
[15:55:16] <jepler> where NEW is the new version number (e.g., 1.15) and OLD is the previous version number (e.g., 1.14)
[15:56:00] <jepler> Then test and check in your change on the branch
[16:03:07] <jepler> I'd be the first to admit it's a bit of a PITA but if we keep adding features to HEAD we'll never be ready to make a release from it.
[16:05:05] <flo-h> I'm trying to understand
[16:52:40] <SkunkWorks> can I browse the new csv?
[16:53:01] <SkunkWorks> Like I could on sourceforge?
[16:54:23] <jepler> SkunkWorks: yes
[16:54:43] <jepler> there's a link at the bottom of
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CVS
[16:55:19] <SkunkWorks> Thanks - I could not find that. sorry.
[16:57:15] <jepler> np
[16:57:50] <cradek> SkunkWorks: the web CVS now keeps up with the developers - on sourceforge it was several hours behind
[16:58:25] <alex_joni> hello
[16:58:29] <SkunkWorks> nice - very fast also. used to take forever to get anywhere on sourcforge.
[16:58:31] <alex_joni> * alex_joni finally is home ;)
[16:59:07] <cradek> hi alex
[16:59:19] <SkunkWorks> wow - someone really put some comments in the fregen :)
[16:59:31] <cradek> oh that's surely jmk
[16:59:37] <cradek> he likes his comments
[16:59:45] <alex_joni> yeah ;)
[17:02:18] <alex_joni> cradek, jepler: what's going on with the tcl & i18n ?
[17:02:22] <alex_joni> anything I can do?
[17:02:36] <SkunkWorks> so it was freqgen that does pseudo pwm.
[17:03:18] <SkunkWorks> cool
[18:24:12] <alex_joni> anyone still around?
[18:25:33] <cradek> not me
[18:26:55] <alex_joni> ok then :)
[18:27:03] <alex_joni> you busted your cover (lol)
[18:28:28] <cradek> darn
[18:29:01] <alex_joni> kidding.. shitty wheather out there.. kinda busted my morale too
[18:29:03] <jepler> SkunkWorks: I'm surprised it feels faster. It's now on a wimpy machine on a wimpy dsl line, I'd expect it to be slower rather than faster.
[18:29:15] <alex_joni> jepler: it is faster
[18:29:22] <cradek> at least it works all the time
[18:29:28] <alex_joni> it was on a fast machine on a fast network before, but configured as crap
[18:29:50] <cradek> I bet it would be really fast on a real computer.
[18:30:03] <alex_joni> * alex_joni has seen some nice servers on ebay
[18:30:12] <alex_joni> quad processor @ 200$
[18:30:28] <jepler> I have two more powerful machines I could have used instead
[18:31:03] <alex_joni> jepler: maybe one day we'll do the switch.. that way we can test backups too
[18:31:31] <cradek> nah, we used a small machine on purpose; it's fast enough
[18:31:55] <alex_joni> it sure feels fast enough
[18:32:14] <SkunkWorks> it is a lot faster.
[19:12:40] <alex_joni> jepler: help :)
[19:16:09] <alex_joni> how do I tell teh buildsystem to look for ncurses.h in /usr/include ?
[19:16:40] <alex_joni> make: *** No rule to make target `ncurses.h', needed by `depends/emc/usr_intf/keystick.d'. Stop.
[19:18:24] <jepler> it will look there automatically
[19:18:35] <jepler> remove the .d file if you've added ncurses.h since it was generated
[19:19:07] <alex_joni> you are right :)
[19:19:21] <alex_joni> I already did that a few times, but not since I installed the -dev package :)
[19:45:37] <alex_joni> jepler: how do I tell it to use the ncurses lib?
[19:46:09] <jepler> Put -lncurses on the link line
[19:46:30] <jepler> ../bin/halmeter: $(call TOOBJS, $(HALMETERSRCS)) ../lib/libemc.a ../lib/libnml.s
[19:46:33] <jepler> o
[19:46:36] <jepler> $(CXX) $(LDFLAGS) -o $@ $^ $(GTK_LIBS)
[19:46:46] <jepler> for halmeter GTK_LIBS includes -lgtk or something
[19:47:25] <alex_joni> yay :)
[19:47:33] <alex_joni> * alex_joni tries it out...
[19:51:24] <alex_joni> keystick is working :)
[19:51:36] <jepler> yay
[19:51:38] <jepler> commit it!
[19:51:50] <alex_joni> ok, I will.. (to HEAD)
[19:52:05] <alex_joni> this presumes we add libncurses-dev as a build dependency
[19:53:02] <jepler> if you know the ubuntu package name, add it to the debian/control file
[19:53:28] <alex_joni> that's the name
[19:53:39] <alex_joni> it's a generic name though, and always reverts to the last version
[19:53:40] <jepler> ok
[19:53:45] <alex_joni> so it's ok imho
[19:55:12] <cradek> you should both add ncurses as a dep and ncurses-dev as a build dep
[19:55:39] <alex_joni> ok, I will in a sec.. need to clean up some warnings from keystick.cc
[19:56:13] <alex_joni> I had to take out quite a few things (log related), and I was lucky as I knew how stuff changed by name *had about 90+ errors on the first attempt )
[19:57:50] <alex_joni> I might have exagerated the other day when I said it's trivial to move it over to emc2 :)
[19:58:17] <jepler> I was going to say that I didn't remember it being that hard to port axis forward, but then I remembered you did it for me
[19:58:27] <alex_joni> nah, that was far easier
[19:58:40] <alex_joni> it's not very complicated
[19:58:43] <jepler> I don't see why it would have been very different
[19:58:47] <alex_joni> just a few things changed the names
[19:59:00] <alex_joni> well.. basicly you followed emc2 along as code changed
[19:59:16] <alex_joni> this is emc1 from quite a while ago.. had to adjust all changes at once
[19:59:33] <alex_joni> but it took me half an hour or so, so it can't be that bad :)
[20:10:35] <jepler> At some point we might want to split the front-ends out into separate subpackages
[20:11:05] <jepler> one reason to have keystick is to have an X-less system, but the emc2 deb will pull in a lot of X stuff for tkemc and halscope
[20:11:25] <alex_joni> yeah, and not have the pickconfig
[20:11:46] <alex_joni> I ran emc2 on a x-less system these days, and it complained about pickconfig
[20:12:06] <cradek> no surprise there
[20:12:07] <alex_joni> even running scripts/emc path/to/ini/with/emccalib
[20:12:15] <jepler> yuck
[20:12:18] <cradek> hmm.
[20:12:24] <alex_joni> or maybe it was the splashscreen that caused problems/
[20:12:26] <alex_joni> ?
[20:12:29] <alex_joni> that might be it
[20:12:50] <jepler> yeah that's more likely
[20:12:56] <jepler> it's in tcl/tk too
[20:13:34] <alex_joni> and it shows an image :)
[20:16:54] <jepler> clearly there's a need for an ascii-art splash screen
[20:17:25] <cradek> yeah, clearly
[20:17:30] <alex_joni> * alex_joni votes we should let giacus take care of it
[20:17:32] <alex_joni> ROFLMAO
[20:20:10] <jepler> alex_joni: How up-to-date are those wiki pages? I don't see STEPGEN items listed there, for instance
[20:20:23] <jepler> and haven't the meanings of INPUT_ and OUTPUT_SCALE changed too?
[20:20:47] <alex_joni> * alex_joni takes his hands away from that..
[20:21:03] <alex_joni> jepler: the ini file stuff has references for emc1
[20:21:12] <alex_joni> and was then used for emc2 too
[20:22:34] <jepler> alex_joni: better just to expunge the emc1 references since nobody uses that old thing anymore :-P
[20:22:57] <alex_joni> jepler: lol
[20:23:01] <alex_joni> if YOU DARE
[20:41:29] <alex_joni> cradek: do I need to add keystick to debian/emc2.files ?
[20:42:03] <cradek> yes I think you have to
[20:42:22] <alex_joni> I see halui is not part of that file.. maybe best for the moment
[20:42:35] <cradek> it's out of date, I think I added it to mine
[20:43:03] <alex_joni> oh, then I'll add them both.. ok?
[20:43:28] <cradek> ok
[20:43:29] <jepler> cradek just needs to start checking in his files
[20:43:32] <cradek> I'll sort mine out later then
[20:43:56] <cradek> well I have this feeling that I'll be screwing it up for BDI, but that's probably not true
[20:44:20] <jepler> cradek: I heard someone say it's already broken for bdi
[20:44:20] <alex_joni> you _really_ think anyone plans on BDI debs?
[20:44:27] <cradek> no idea
[20:44:41] <jepler> paul made a set of broken emc2 debs for bdi
[20:44:41] <cradek> I'll check the stuff in either way, especially on the release branch
[20:44:49] <cradek> it's important that it matches
[20:44:49] <alex_joni> ok..
[20:45:57] <alex_joni> I'm off to bed..
[20:46:01] <alex_joni> good night all
[21:09:30] <jepler> 15:26:56 [freenode] -!- Lerneaen [n=chatzill@c-6230e353.646-1-64736c10.cust.bredbandsbolaget.se]
[21:09:34] <jepler> 15:59:03 -!- Bo^Dick [i=Bo-Dick@c-4016e255.455-1-64736c10.cust.bredbandsbolaget.se] has joined #emc
[21:17:33] <SkunkWorks> those where good questions so I don't thinkit was the same person :)
[22:59:23] <jmkasunich> its officially spring - we had dinner on back porch/deck for the first time this year
[23:27:45] <skunkworks> we have the windows open for the last few days - last night the windows where open over night.
[23:27:52] <skunkworks> finally
[23:29:43] <jmkasunich> still not overnight here, got down to 40F last night
[23:31:02] <skunkworks> we like it cold. :)
[23:31:24] <skunkworks> the house is 58 deg in the winter.
[23:31:56] <skunkworks> I looked at the freqgen source - nice notes. (I was told it was probably your notes) :)
[23:32:19] <skunkworks> I am really excited about trying a pid loop using psudo pwm out of freqgen.
[23:32:38] <jmkasunich> thanks (about the notes)
[23:32:40] <skunkworks> maybe in a week or two I will have something set up.
[23:32:41] <jmkasunich> I like comments
[23:32:51] <jmkasunich> I'm getting senile, need to remind myself what I wrote
[23:32:54] <skunkworks> that is what I heard.
[23:33:09] <skunkworks> not the senile comment - the comments comment
[23:33:14] <jmkasunich> lol
[23:38:02] <skunkworks> I have a question - I am going to use a ir2111 driver. It uses some sort of bootstrap circuit. cap diode - but say you are going to turn the high side first - how does it get charged initialy? does it assume you are running a full h-bridge?
http://www.radiobox.ru/pdf/IR2111.PDF
[23:38:18] <jmkasunich> you can't turn on the high side first
[23:38:35] <jmkasunich> those drivers are very nice, but they have a few limitations
[23:38:46] <jmkasunich> 1) you must turn on the low side first to charge the bootstrap
[23:39:07] <jmkasunich> 2) you can't go to 100% duty cycle on the high side, you must turn on the low side every once in a while to recharge the bootstrap
[23:39:35] <skunkworks> interesting.
[23:39:53] <jepler> if you try to do a 100% duty on the high side, what happens? Something destructive, or something safe?
[23:39:54] <skunkworks> that explains it :)
[23:40:25] <jmkasunich> I'd have to re-read the data sheet to be sure
[23:40:47] <jmkasunich> probably, the high side driver goes into undervoltage lockout and turns off the high side device
[23:41:07] <jmkasunich> alternatively, the high side device gate drive drops until the devide comes out of saturation and gets hot
[23:41:17] <jmkasunich> I'm about 99% sure its the former, not the latter
[23:41:25] <jmkasunich> depending on the load current, the latter could be bad
[23:41:51] <jmkasunich> the devices I use at work would fail in milliseconds (if not sooner) if they were allowed to come out of saturation
[23:41:58] <skunkworks> there is no info about this on the datasheet unless I am blind. I was looking for application notes but could not find it
[23:42:13] <jmkasunich> is there info about undervoltage lockout?
[23:42:25] <skunkworks> charging the bootstrap
[23:42:44] <jepler> I agree, the datasheet is pretty lean on details
[23:43:46] <jmkasunich> Vbsuv+ Vbs supply undervoltage positive going threshold 8.4V typ
[23:44:26] <jmkasunich> since most fets are pretty well saturated at 5V or so (and spec'ed at 10V) that should be fine
[23:44:44] <skunkworks> they talk about application notes but I have yet to find it on ir's site
[23:45:13] <jmkasunich> they show the undervoltage detector(s) on the block diagram too
[23:47:47] <jmkasunich> I seem to recall using something like 10uF for the bootstrap cap (possibly in parallel with a 0.1uF ceramic)
[23:48:08] <skunkworks> in a situation running small servos it probably would not be a problem as the servo "searches" I would think - but the initial startup might be a problem
[23:48:15] <jepler> http://www.irf.com/technical-info/appnotes/an-978.pdf
[23:48:38] <jepler> from
http://www.irf.com/product-info/imotion/imotionappnotes.html
[23:49:01] <jmkasunich> skunkworks: actually I did have startup problems sometimes when I was messing with it
[23:49:35] <jmkasunich> if there is a large initial servo error, the PID might drive it far enough in one direction that random jitter never takes it the other way to bootstrap the drivers
[23:49:56] <jmkasunich> if the initial error was zero (or very close) then jitter got it going pretty reliably
[23:50:29] <jmkasunich> actually, jitter wasn't needed
[23:50:54] <jmkasunich> the outputs of the freqgen module are UP and DOWN
[23:50:59] <skunkworks> jepler: thanks - I thought I was good at finding things. I must have spent a few hours looking for any info
[23:51:12] <jmkasunich> one or the other is always low, which drives the low fet on and does the bootstrap
[23:51:40] <jmkasunich> the only way to get "stuck" is to power up with freqgen already at 100% duty cycle either UP or DOWN
[23:51:53] <skunkworks> ok - that makes sense.
[23:52:08] <jmkasunich> but if UP is even 99% and down is low, both sides get bootstrapped in one PWM cycle
[23:52:10] <jepler> you could easily limit the duty cycle to 95% (or whatever) in your hal configuration
[23:52:14] <jmkasunich> yes
[23:52:18] <jmkasunich> in fact I did that
[23:52:28] <jmkasunich> not for startup, but for running
[23:52:58] <jepler> I was just worried if you turned the computer off, the drive would eat itself and then put Vdrive through the PC too
[23:53:20] <skunkworks> jmkasunich: what was the circuit you made? was it using a bridge driver like this?
[23:53:31] <jmkasunich> yes
[23:53:38] <skunkworks> I am going to put opto-isolators on the inputs.
[23:53:59] <jepler> skunkworks: probably a wise idea
[23:53:59] <jmkasunich> I don't recall the details, a co-worker actually built it over a year ago for a previous engineer's week competition
[23:54:05] <jmkasunich> we reused it this year with freqgen
[23:54:13] <skunkworks> nice.
[23:54:24] <jmkasunich> IIRC he use some monster fets
[23:54:37] <jmkasunich> 10-20mohm things rated at 100A with heatsinking
[23:54:44] <jmkasunich> we didn't bother with heatsinking ;-)
[23:55:14] <skunkworks> the prices have really come down. we where looking at some 30a mosfets (less app to destroy them by accident)
[23:55:27] <skunkworks> 100v
[23:55:46] <jmkasunich> the real thing to look at with mosfets is the on resistance
[23:55:50] <skunkworks> right
[23:55:57] <jmkasunich> amp ratings are figments of the makers imagination
[23:56:44] <skunkworks> we where doing the calcualtion - the voltage drop at full current equaled the max wattage the package could handle
[23:57:00] <jmkasunich> when mounted on an icecube probably
[23:57:08] <jepler> skunkworks: yeah that's what I saw the last time I looked at the rated power of a transistor
[23:57:10] <skunkworks> :
[23:57:12] <skunkworks> :)
[23:57:34] <skunkworks> what are your views on IGBT's?
[23:57:36] <jepler> it was after bo-dick reported that his transistor melted
[23:57:43] <jmkasunich> mine?
[23:57:47] <jepler> I hope you're asking jmkasunich that, I don't have a clue
[23:58:01] <skunkworks> yours
[23:58:02] <jmkasunich> they're the only game in town above 500V and an amp or so
[23:58:22] <jmkasunich> all the stuff I do at work is with IGBTs
[23:59:08] <skunkworks> this isn't an igbt
http://www.alliedelec.com/Images/Products/Datasheets/BM/INTERNATIONAL_RECTIFIER/International-Rectifier_Actives-and-Passives_2732400.pdf
[23:59:11] <jmkasunich> 450A, 1200 or 1700V six packs, either two or four in parallel (with 8 in parallel in the future)
[23:59:29] <skunkworks> wow