Back
[00:14:15] <jmkasunich> back
[00:14:28] <jmkasunich> would you do me a favor and try logging into it?
[00:14:34] <jmkasunich> use jmkasunich.dyndns.org
[00:14:35] <jmkasunich> I
[00:14:52] <jmkasunich> (this is probalby the first real test of the dyndns client)
[00:22:51] <cradek> yep it works
[00:23:22] <jmkasunich> good
[00:23:54] <jmkasunich> I decided to punt on the board... redoing your layout seemed pointless, and a more sophisticated thing, while an interesting project, probably isn't worth the time right now
[00:24:02] <jmkasunich> instead I'm starting a PWM generator component
[00:24:11] <cradek> cool
[00:24:14] <jmkasunich> you are just in time to brainstorm the interface
[00:24:17] <cradek> pwm or pdm?
[00:24:22] <jmkasunich> yes
[00:24:23] <jmkasunich> ;-)
[00:24:41] <jmkasunich> if possible, selected by parameter, if not, by insmod param
[00:25:05] <jmkasunich> basic input will be a float pin, probably called "value"
[00:25:10] <cradek> I updated the cvs backup script to use your new hostname
[00:25:19] <jmkasunich> good
[00:25:50] <cradek> so there's a max param and value goes from 0 to that?
[00:25:54] <jmkasunich> they'll be a scale parameter, value will be either multiplied or divided by value to get duty cycle
[00:26:14] <cradek> ok
[00:26:36] <jmkasunich> max-dc and min-dc would be applied to the duty cycle (or should they be applied before scaling, I dunno?)
[00:26:51] <cradek> do you want a mx+b type thing?
[00:26:58] <jmkasunich> the actual duty cycle after scaling and limiting will be available as a parameter
[00:27:09] <jmkasunich> none of the other components have the +b part
[00:27:14] <cradek> i.e. "I measured my spindle speed at 0v and at 5v input"
[00:27:16] <cradek> ok
[00:27:21] <cradek> not necessary
[00:27:24] <cradek> at 0v it should stop
[00:27:34] <jmkasunich> we have sum blocks for the rare cases that need offset
[00:27:42] <cradek> right
[00:28:18] <jmkasunich> so a couple of decisions to be made: divide or multiply for scale? and limit before or after scaling?
[00:28:41] <SWPadnos> unless the limits define the range for "value", I'd limit after scaling
[00:28:43] <jmkasunich> I'm leaning toward limiting after scaling, the params will be min-dc, not min-value
[00:28:51] <jmkasunich> SWP! you're alive!
[00:28:56] <cradek> I agree
[00:29:03] <SWPadnos> heh - yep
[00:29:28] <jmkasunich> ok, I think we agree, limit after scaling
[00:29:50] <jmkasunich> now, the scale.... if we multiply, the user most likely will be entering reciprocals
[00:30:07] <cradek> steve stalling's board required not-dc, it's natural to set it to 1% - 99%
[00:30:14] <SWPadnos> is the idea to give a pseudo-DAC?
[00:30:31] <jmkasunich> for instance, if he knows that 100% duty cycle will deliver 24V to the motor, he might want to scale so that value = 24 results in dc = 100%
[00:30:44] <jmkasunich> SWP: pseudo-dac, or direct drive to H bridges even
[00:30:49] <cradek> yes
[00:31:01] <SWPadnos> hmmm.
[00:31:13] <jmkasunich> if the scale factor is multiplied, he'll have to enter 1/24, if its divided he can enter 24
[00:31:18] <cradek> or at full-on, my spindle is 1600 rpm, so I want to say 100% is an input of 1600
[00:31:32] <SWPadnos> then the limits should be on duty cycle (or in "value" units, as "DC")
[00:31:33] <jmkasunich> right, so you'd rather set scale to 1600 than 1/1600
[00:31:38] <cradek> yes
[00:31:54] <SWPadnos> and the "scale" should be "this is what should provide 100% duty cycle"
[00:32:00] <jmkasunich> yes
[00:32:11] <SWPadnos> and you need to divide ;)
[00:32:17] <jmkasunich> scale divides, max-dc and min-dc are applied after scaling
[00:32:18] <SWPadnos> (you = the component)
[00:32:31] <jmkasunich> right, not a problem, other components do the same
[00:32:40] <jmkasunich> check for too close to zero, if so change it to one
[00:32:45] <SWPadnos> yep - I'm agreeing that it should be that way
[00:32:48] <cradek> me too
[00:33:06] <jmkasunich> max-dc and min-dc apply to the absolute value
[00:33:27] <jmkasunich> so if min-dc is 1%, you can still command -5% and thats what you'll get
[00:33:31] <SWPadnos> offset would be good, for things that need a mid-scale setpoint for 0
[00:33:55] <jmkasunich> I'm anti-offset, mostly for consistency reasons
[00:34:18] <SWPadnos> this is like an ADC, and those definitely should have offset
[00:34:26] <SWPadnos> oops - DAC
[00:34:35] <SWPadnos> well, either needs offset anyway
[00:34:39] <jmkasunich> heh
[00:34:49] <jmkasunich> is there an offset in the canonical DAC interface?
[00:35:01] <SWPadnos> there should be. didi I ever commit that stuff?
[00:35:07] <SWPadnos> I did, I think
[00:35:09] <cradek> where are these documents?? I couldn't find the encoder one
[00:35:17] <jmkasunich> I asked because I'm too lazy to check
[00:35:17] <SWPadnos> documents module
[00:35:25] <cradek> duh
[00:35:26] <jmkasunich> the hal_intro doc
[00:35:28] <SWPadnos> lyx/something ;)
[00:35:36] <cradek> argh
[00:35:42] <SWPadnos> or emc2/lyx/something
[00:35:46] <jmkasunich> lyx/emc2/several somethings now, because we split it into chapters
[00:36:06] <cradek> so you also have no idea where it is?
[00:36:09] <SWPadnos> this begs for inclusion in the main tree, as the suggested in recent list discussion
[00:36:14] <jmkasunich> heh
[00:36:29] <SWPadnos> I vote yea, if that means anything
[00:36:49] <jmkasunich> I talked to ray yesterday or the day before (/msg) and he said go ahead and make the motion, he might vote no but he expects it to pass and can live with it
[00:36:51] <cradek> is it documents/lyx/emc2/hal_general_ref.lyx?
[00:36:52] <jmkasunich> I should do that
[00:37:04] <jmkasunich> cradek, is there a pdf in there?
[00:37:08] <cradek> no
[00:37:17] <SWPadnos> yes it is - that's the one last edited by me
[00:37:22] <SWPadnos> and the comment matches ;)
[00:37:30] <cradek> yeah I only guessed by the log message
[00:37:46] <jmkasunich> that reminds me I have a significant uncommitted change from before the fest
[00:37:46] <SWPadnos> I guess it was a good log message then
[00:37:46] <cradek> remind me why programmer documentation is in lyx format?
[00:37:54] <SWPadnos> because it's text?
[00:37:56] <jmkasunich> its everybody documentation
[00:38:18] <jmkasunich> what format do you have in mind?
[00:38:24] <cradek> brb
[00:38:49] <SWPadnos> ok. scale and offset are in there
[00:39:00] <jmkasunich> is scale dividing or multiplying
[00:39:05] <SWPadnos> thinking like 4-20 mA outputs and the like
[00:39:09] <SWPadnos> I don't think it's specified
[00:39:41] <jmkasunich> I'm updating, I'll check
[00:39:51] <jmkasunich> if its not specified, it should be (and I can fix it now)
[00:40:19] <SWPadnos> it says "this should be set so that an input of 1 will make 1V appear at the output
[00:40:24] <SWPadnos> but that's probably wrong
[00:40:27] <jmkasunich> heh
[00:41:17] <SWPadnos> hi Ray
[00:41:26] <jmkasunich> hi ray
[00:42:00] <jmkasunich> SWP: yeah, I think the analog out canon interface needs tweaked
[00:42:16] <SWPadnos> yep. note the log message "first stab ..." ;)
[00:42:23] <jmkasunich> ;-)
[00:42:42] <jmkasunich> value and enable are fine
[00:42:52] <jmkasunich> offset - need to be clear when that is added
[00:43:03] <SWPadnos> yep, and whether it's added or subtracted
[00:43:05] <jmkasunich> is it in "value" units
[00:43:14] <SWPadnos> I think it should be, but I'm not sure
[00:43:42] <rayh> Hi guys
[00:45:17] <SWPadnos> an interesting point came up earlier - alex pointed out that libnml is actually LGPL, not GPL
[00:45:26] <jmkasunich> it is?
[00:45:32] <SWPadnos> that was my reaction as well
[00:45:50] <SWPadnos> no wait - that was Robin. mine was "is it?"
[00:46:17] <jmkasunich> well, I kinda think thats OK
[00:46:20] <SWPadnos> specifically so that people could make custom GUIs on top of it
[00:46:34] <SWPadnos> right - kinda eliminates a lot of the issues we discussed after dinner
[00:46:55] <jepler> yeah, it does
[00:47:17] <jepler> can someone still get smithy to pay him for a LGPL version of libnml?
[00:47:22] <jepler> *innocent expression*
[00:47:38] <SWPadnos> well, nobody has to tell *them* that
[00:47:46] <jmkasunich> hmmm, don't jump so fast...
[00:47:58] <jmkasunich> libnml might be LGPL (the protocol)
[00:48:01] <jepler> the next day after the dinner, I tried to make the point that to get cam software X to be well-supported by emc2, you just have to buy a copy of it for a developer.
[00:48:01] <SWPadnos> it's the GUI that they want anyway
[00:48:08] <jmkasunich> but emc.hh (the emc vocabulary) is GPL
[00:48:08] <jepler> I don't think the idea was taken seriously, but I meant it
[00:48:29] <SWPadnos> heh
[00:49:02] <SWPadnos> I suppose a seat of SolidWorks Office or whatever they call it would be good for somebody ;)
[00:49:56] <jmkasunich> not me
[00:50:16] <jmkasunich> I still wouldn't be able to do the needed work, no matter how much info I had about the CAM
[00:50:17] <SWPadnos> it does help to have a fairly modern PC running Windows (XP only after 2006)
[00:51:23] <jmkasunich> popping one level off the stack: even tho libnml is LGPL, emc.hh is not, so they still can't do a custom GUI
[00:52:17] <SWPadnos> makes LGPL'ing libnml kinda useless I guess
[00:52:19] <fenn> rip it out
[00:52:22] <fenn> kill!!
[00:52:25] <jmkasunich> rip what out?
[00:52:53] <fenn> sorry, gut reaction to anything nml
[00:53:00] <jmkasunich> heh
[00:53:45] <jmkasunich> LGPL on libnml means somebody could use NML for a completely different project if they wish, using their own vocabulary
[00:53:56] <fenn> if they were so foolish
[00:53:56] <jmkasunich> which could be LGPL or proprietary
[00:54:38] <SWPadnos> alex seemed to think that the reason for LGPL was so that people could make their own GUIs - that may have a bit of misguided thought
[00:55:10] <jmkasunich> or that may have been exactly the intention, but the GPL status of emc.hh might have been overlooked
[00:57:51] <rayh> I'm pretty sure that I don't understand why emc.hh being gpl makes it impossible to build a proprietary gui.
[00:58:15] <jmkasunich> because emc.hh defines all the NML messages that EMC uses
[00:58:38] <jmkasunich> and you need to include emc.hh in your proprietary code if you want to talk to EMC
[00:58:38] <rayh> so we just step back to the public domain version and begin again with new words.
[00:58:44] <rayh> That is shit.
[00:59:06] <jmkasunich> (I'm ignoring the emcsh approach, I assume they want to use C or C++)
[00:59:32] <jmkasunich> emcsh is a valid way of getting around it, if you are into tcl
[00:59:37] <rayh> No I'm saying that one could easily write a new version of emc.hh
[01:00:00] <rayh> Since that came from public domain.
[01:00:00] <jepler> everything in emc.hh looks trivial, but what about the code that emc.hh has prototypes for?
[01:00:24] <jmkasunich> emc.cc, likewise GPL'd
[01:00:39] <rayh> likewise public domain versions exist.
[01:01:19] <jmkasunich> 2 years old
[01:01:29] <jmkasunich> I'm diffing now, curious how much has changed
[01:02:24] <rayh> I admit I was surprised when Alex said that libnml was lgpl.
[01:02:54] <jepler> hardly any of the changes to axis since its inception have been due to incompatible changes in the nml interface of emc
[01:03:02] <jepler> most have been due to incompatible changes in the canon interface
[01:03:12] <rayh> My presumption was that it was done so that folk could attach whatever gui's they wanted.
[01:03:24] <jmkasunich> well, G50/51 are new NML messages
[01:03:35] <rayh> Perhaps making the .hh and .cc GPL was a mistake?
[01:03:38] <jmkasunich> and I think when you added velocity and accel to the line/arc commands that changed it
[01:04:01] <jmkasunich> rayh, whether it was a mistake depends on your intent
[01:04:20] <jmkasunich> if "you" (we) intend to allow proprietary GUIs, yes, it was a mistake
[01:04:32] <rayh> If the intent of lgpl in libnml was to allow proprietary guis.
[01:04:33] <jmkasunich> if you intend to prevent them, it was correct
[01:04:52] <rayh> I don't intend anything. I didn't gpl
[01:05:24] <rayh> proprietary gui's is essential to industrial applications.
[01:05:28] <jmkasunich> technically it was paul who put the notice in there (as part of a wholesale labeling 2 years ago)
[01:05:41] <rayh> as are proprietary boards and hal modules.
[01:10:31] <jmkasunich> sorry, too many conversations going on
[01:10:38] <jmkasunich> the stack is about 5 deep right now
[01:11:10] <jmkasunich> re prop. guis.... the only way to really know what the situation is is for someone to try writing one, and see which files do and do not need to be linked into it
[01:11:44] <jepler> libraries = ["emc", "nml", "m", "stdc++", "GL"],
[01:11:47] <jepler> I link axis with these libs
[01:12:03] <jepler> rather, the 'emc' module which is enough stuff to control emc with
[01:12:07] <jepler> manual, mdi, auto, etc
[01:12:21] <jepler> but libemc is probably a lot more than emc.cc
[01:12:35] <jmkasunich> I haven't a clue
[01:12:36] <jepler> I include rcs.hh emc.hh inifile.hh
[01:13:32] <jmkasunich> rcs.hh is LGPL
[01:13:37] <jmkasunich> inifile.hh is GPL
[01:14:10] <jmkasunich> the inifile code really has nothing to do with NML and was put in rcslib as a catchall
[01:14:15] <jmkasunich> same as posemath, for example
[01:14:36] <jmkasunich> the ini stuff could be clean-room rewritten without tremendous effort
[01:14:47] <jmkasunich> or just go back to the PD stuff
[01:15:09] <jmkasunich> (although I think Paul transmogrified it from a C API to a C++ class after sticking GPL on it)
[01:15:10] <jepler> these files are in libemc: emcglb.c emc.cc emcargs.cc emcops.cc iniaux.cc iniaxis.cc inicool.cc inilube.cc inispin.cc initraj.cc initool.cc interpl.cc
[01:16:08] <jmkasunich> all GPL I'm sure
[01:22:58] <jmkasunich> well, this conversation has gone from a HAL PWM component, to the generic analog HAL interface, to (L)GPL and prop. GUIs, to solidworks, and back to GUIs.....
[01:23:08] <jmkasunich> I wanna write some PWM code tonight ;-)
[01:23:25] <fenn> i wanna make an led blink
[01:23:43] <jmkasunich> thats easy
[01:23:55] <rayh> Good plans all.
[01:24:00] <jmkasunich> led, resistor, 9v battery, connect and disconnect as needed
[01:24:04] <rayh> catch you later.
[01:24:20] <jmkasunich> that was a very short visit from ray
[01:24:47] <SWPadnos> indeedy
[01:27:29] <jepler> these two source files are enough of a "libemc" for axis: emcglb.c emc.cc
[01:40:58] <jmkasunich> jepler: both are gpl, right?
[01:43:40] <jmkasunich> jepler: interested in my approach to encoder divider?
[01:45:50] <cradek> I am if he's not
[01:45:55] <jmkasunich> heh
[01:45:57] <cradek> my board is already made :-)
[01:46:14] <jmkasunich> I thought he was writing software for your board?
[01:46:23] <jmkasunich> asking SWP about rotate instructions on the AVR, etc...
[01:46:38] <cradek> yes I think so
[01:46:57] <SWPadnos> oh yeah - 3 cycles minimum, I think (due to that darned carry)
[01:46:58] <cradek> I don't know the difference in your two approaches - don't know which is better
[01:47:15] <jmkasunich> won't know until you count cycles
[01:47:23] <jmkasunich> I don't know his approach
[01:47:27] <SWPadnos> any table lookup will be slower, guaranteed
[01:48:05] <jmkasunich> SWP: table lookup (alone) vs. rotate (alone) isn't the issue
[01:48:11] <SWPadnos> possibly as fast as 3 cycles, if the high byte of the table address can be preloaded for all channels
[01:48:14] <SWPadnos> true enough
[01:48:31] <jmkasunich> what matters is the total time from reading the fast input bits to outputing the slow output buts
[01:48:33] <jmkasunich> bits even
[01:48:45] <SWPadnos> heh
[01:48:49] <jmkasunich> and the LUT can do both quadrature decode, and divide by 16, at the same time
[01:49:22] <jmkasunich> take current state, OR in new inputs, look up new state (which includes the proper outputs), done
[01:49:25] <cradek> jepler was doing two encoders at a time with one table
[01:49:41] <jmkasunich> nifty
[01:49:56] <jmkasunich> but why is he messing around with rotates then
[01:49:57] <SWPadnos> right - a 256-element table can do that
[01:50:14] <jmkasunich> SWP: how?
[01:50:26] <jmkasunich> to just decode quadrature, sure
[01:50:40] <SWPadnos> 2 bits per channel for current position, 2 bits per channel for last position = 8 bits of indexing
[01:50:53] <SWPadnos> but the table doesn't hold the prerotated state bits for the next pass
[01:51:00] <jmkasunich> so you're doing the divide by 8 or 16 elsewhere?
[01:51:08] <SWPadnos> yes
[01:51:34] <jmkasunich> and how much time does the "elsewhere" cost you, compared to doing one channel per lookup and getting everything at once?
[01:51:34] <SWPadnos> (I probably would, so the dividecould be more flexible)
[01:52:35] <cradek> there is room for many? 256 byte tables if you want configurable divide
[01:52:53] <SWPadnos> what kind of divide ratios are you looking for?
[01:53:01] <jmkasunich> x8 or x16
[01:53:03] <cradek> 8 or 16
[01:53:10] <SWPadnos> ok
[01:53:49] <jmkasunich> I was thinking of a "loop" of 64 states
[01:54:11] <SWPadnos> yep
[01:54:39] <jmkasunich> current state = 6 bits, plus 2 new inputs, gives next state and two bits of output
[01:55:20] <jmkasunich> (you could also use the actual state bits for output if you number the states wisely, that lets the new state value have 00 where you are gonna OR in the new bits, saves a masking AND
[01:55:34] <SWPadnos> so then you use the rotates to move bits from different channels into the bottom two bits (or top two)
[01:55:57] <jmkasunich> if you have the right pinout you could
[01:56:11] <jmkasunich> they also have individual bit test, set, and clear instructions, I was just planning on that
[01:56:20] <SWPadnos> well - whichever two bits they need to be in - hopefully adjacent
[01:56:27] <jmkasunich> assuming the new bit positions are already clear:
[01:56:46] <SWPadnos> sbrc / sbr / sbrc / sbr - 4 cycles
[01:56:51] <jmkasunich> test-bit-skip-if-clear portX.bitENC1-A
[01:56:59] <jmkasunich> setbit state.0
[01:57:00] <SWPadnos> 2 cycles there
[01:57:05] <jmkasunich> test-bit-skip-if-clear portX.bitENC1-B
[01:57:09] <jmkasunich> setbit state.1
[01:57:12] <SWPadnos> you want to read the port and work on a register
[01:57:24] <jmkasunich> exactly, there is a test-port-bit instruction
[01:57:38] <SWPadnos> which is 2 cycles, rather than 1 for a register bit test
[01:57:39] <jmkasunich> don't have the table handy, hence my non-standard mnemonic
[01:57:50] <jmkasunich> oh
[01:58:28] <SWPadnos> SBIS and SBIC for I/O set / clear test, respectively
[01:58:50] <jmkasunich> skip if io bit set?
[01:58:51] <SWPadnos> SBI and CBI to set or clear an I/O bit (also 2 cycles)
[01:59:07] <SWPadnos> yep - skips, not branches
[01:59:12] <jmkasunich> IF the pinout allowed, you could do it faster with rotates and such
[01:59:33] <jmkasunich> I was aiming for arbitrary pins in and out (the hardware guy wants to make layout easy ;-)
[01:59:37] <SWPadnos> just define the input bits as pairs of adjacent bits on the same port
[01:59:41] <SWPadnos> heh
[01:59:48] <SWPadnos> that should still be easy
[01:59:55] <jmkasunich> yeah
[02:00:12] <jmkasunich> so one clock to read the port into a register, then the rotates, etc
[02:00:21] <jepler> jmkasunich: aha, I'm starting to understand how your table-based approach is supposed to work
[02:00:24] <jmkasunich> heh, mine is just as fast if you read the port into a register
[02:00:28] <SWPadnos> I think the read and write are also 2 cycles
[02:00:43] <jmkasunich> well, we both have to do the read I think?
[02:01:11] <SWPadnos> yep
[02:01:32] <SWPadnos> the table approach is faster overall, but only works for power-of-two divides, I think
[02:01:40] <jmkasunich> right
[02:01:41] <SWPadnos> I was thinking of a more generic solution (the software guy ;) )
[02:01:54] <jepler> my code is also written for only power-of-two divides, because it uses bit testing and masking to find when you've overflowed the count
[02:01:58] <jmkasunich> anything other than power of 2 would be messy for no good reason
[02:02:24] <SWPadnos> the AVR is just about as good at "normal" math as it is at bit ops
[02:02:37] <SWPadnos> cp / sub is pretty quick
[02:02:41] <jepler> buggy pseudocode for my concept:
http://emergent.unpy.net/files/sandbox/quadquad.txt
[02:02:45] <jmkasunich> the really fast approach is the LUT with a prom and an HC374
[02:02:47] <SWPadnos> (1 cycle per, just like masking)
[02:02:51] <jmkasunich> clock that bugger at 10MHz if you want
[02:03:13] <SWPadnos> 1 MHz would still work ;)
[02:03:27] <SWPadnos> faster than the AVR
[02:03:36] <jmkasunich> for 1MHz, you can reuse the prom
[02:04:06] <jmkasunich> tristate all but one HC374 output (all 374 outputs drive the prom addresses)
[02:04:17] <jmkasunich> clock that one, tristate it and enable another one
[02:04:26] <SWPadnos> the AVR can emulate a PROM pretty quickly - just use a 374 and an AVR
[02:04:27] <jmkasunich> could do 8 channels at a 1MHz
[02:05:06] <jmkasunich> one 374 per channel tho, gets big (even if cheap) fast
[02:05:35] <SWPadnos> just clocking the 374 at 1x rate, not true quadrature?
[02:05:46] <SWPadnos> (ie, A=clock, B=up/down)
[02:05:48] <jmkasunich> clocking the 374 at some fixed rate
[02:05:51] <SWPadnos> ah
[02:06:01] <jmkasunich> its a sampled system, just like the AVR LUT approach
[02:06:04] <jepler> A=clock, B=up/down doesn't work
[02:06:15] <jmkasunich> just can get an order of magnitude faster sample rate with the 374
[02:06:16] <SWPadnos> it's more susceptible to noise, but should work fine
[02:06:18] <jepler> cradek, john, and I were all fooled for a bit that it did
[02:06:31] <jepler> http://emergent.unpy.net/sandbox
[02:06:36] <jmkasunich> SWP: imagine sitting right at one edge, and jittering the shaft back and forth
[02:06:41] <jmkasunich> jeplers pic shows it best
[02:06:46] <jepler> s/pic/ascii art/
[02:06:51] <jmkasunich> whatever
[02:06:52] <SWPadnos> = susceptible to noise ;)
[02:07:01] <jepler> that's not noise; it's legitimate movement of the shaft
[02:07:09] <SWPadnos> ok - true enough
[02:07:12] <jmkasunich> thats not noise, thats actual mechanical movement that should count +1, -1, +1, -1
[02:07:23] <jmkasunich> but instead counts +1, +1, +1, +1
[02:07:26] <SWPadnos> hold on - that's legitimate movement ;)
[02:07:59] <jepler> SWPadnos: the more people who hit on this wrong way of counting quadrature, the better I feel about it
[02:08:03] <jmkasunich> ohh, just realized something....
[02:08:05] <SWPadnos> heh
[02:08:11] <jepler> this person did too:
http://members.home.nl/jmnieuwkamp1/AVRlib/docs/html/encoder_8h-source.html
[02:08:18] <jmkasunich> the new scheme is still vulnerable
[02:08:30] <SWPadnos> it works for me in my pulse generator
[02:08:58] <jmkasunich> because there are 4 places around the cycle where a +1 or -1 on the input causes the output to also go +1/-1 at the same (too fast) rate
[02:09:17] <SWPadnos> you shouldn't be able to get that dither though, since the motor should be pinging back and forth from one of the divided counts
[02:09:40] <jmkasunich> you gotta assume you can get that dither
[02:09:59] <SWPadnos> right - you have to stretch dither so it's at the slower rate
[02:10:00] <jmkasunich> maybe the motor is totally unpowered, the wheel is right on the borderline, and the machine is vibrating
[02:10:11] <SWPadnos> sure - noise happens
[02:10:25] <jmkasunich> actually, I think you don't have to stretch the dither
[02:10:42] <jepler> if you're reacting right to all the edges it doesn't matter if there's dither as long as you sample fast enough
[02:10:45] <jmkasunich> if the PC sees the dither, it counts +1/-1
[02:10:50] <SWPadnos> you do if you want the computer to be able to see it, I think
[02:10:51] <jmkasunich> if it doesn't, it doesn't count at all
[02:10:56] <jepler> I don't understand how the '374 approach works so I don't know if it's got a problem
[02:11:15] <jmkasunich> 374 is exactly the same as the software LUT
[02:11:18] <SWPadnos> you'd end up dithering the output at the same rate as the input dithers
[02:11:30] <jmkasunich> infact the SW approach is based on the 374, not the other way around
[02:11:51] <jmkasunich> 374 is an 8-bit edge triggered latch
[02:12:01] <jmkasunich> its outputs go to the address of the rom (LUT)
[02:12:25] <jmkasunich> (old state + new bits)
[02:12:47] <jmkasunich> 2 of the 374 inputs come from the new bits, the other 6 come from the prom data lines (new state)
[02:13:04] <cradek> sounds like it's hardware for state=lut[state]
[02:13:09] <jmkasunich> every time you clock the 374, old-state is replaced with new-state
[02:13:14] <jmkasunich> exactly
[02:13:17] <SWPadnos> cradek, exactly
[02:13:28] <SWPadnos> state = lut[state + inputs]
[02:13:35] <jmkasunich> and the fancy shifts and rotates to merge the new bits and pick off the output, are simply wires
[02:13:39] <jepler> where does the clock come from? It's just some free-running, fast clock?
[02:13:43] <jmkasunich> yeah
[02:13:53] <jmkasunich> it sets the sample rate
[02:14:10] <jmkasunich> you could run it at 1MHz, 10MHz, 100KHz, as long as its faster than the count rate of the encoder
[02:14:40] <cradek> I know eproms are dead slow - some other common proms aren't?
[02:14:51] <jmkasunich> dead slow is still 150-200nS
[02:15:20] <cradek> I tried to use 2716s for logic at video rates once
[02:15:37] <jmkasunich> actually the prom is the biggest problem, try buying a 256 byte memory these days
[02:15:48] <SWPadnos> more than an AVR
[02:15:51] <SWPadnos> and you need a programmer
[02:16:04] <SWPadnos> and possibly a UV eraser
[02:16:09] <SWPadnos> haven't seen those in a while
[02:16:10] <cradek> not a big obstacle for me
[02:16:11] <jmkasunich> OTP man
[02:16:21] <SWPadnos> fixed divide rate ;)
[02:16:31] <jmkasunich> the biggest penalty with that concept is just the chip count
[02:16:34] <jmkasunich> 2 for one channe
[02:16:35] <cradek> nah, simple matter of reprogramming the eprom
[02:16:42] <jmkasunich> 2+n for N channels
[02:16:43] <cradek> true
[02:17:04] <jmkasunich> 3+n actually
[02:17:11] <jmkasunich> not counting the clock source
[02:17:44] <jmkasunich> the avr is much more compact, even tho slower
[02:17:48] <cradek> so is there a suboptimal but good enough solution for the board I already built that will make my lathe work?
[02:18:01] <cradek> or am I still barking up the wrong tree?
[02:18:05] <jmkasunich> sure, the AVR implementation of the same ckt
[02:18:23] <jmkasunich> we're still ignoring index, but your board doesn't have a pin for that anyway
[02:18:37] <cradek> yeah
[02:19:03] <jmkasunich> index stretch is easy for the uC
[02:19:07] <cradek> the next problem with index is when I divide 500/8 or 500/16 I don't get an integer
[02:19:20] <jmkasunich> hmm
[02:19:30] <jepler> isn't it 2000/8?
[02:19:33] <jmkasunich> don't think it really matters
[02:19:46] <cradek> oh duh, it's 4096/8
[02:19:53] <SWPadnos> that's easier
[02:19:54] <cradek> I forgot, different encoder
[02:19:54] <jmkasunich> you reset to zero on an index, then allow the thing to count until you finish the threading pass
[02:20:05] <jmkasunich> wouldn't matter if it was 1349 per rev
[02:20:09] <cradek> jmkasunich: multiple passes have to line up
[02:20:09] <jepler> I mean, even if it was a 500-pulse encoder, thats 2000 counts, which does divide 8
[02:20:19] <jmkasunich> cradek, they will
[02:20:35] <cradek> ok I see what you mean
[02:20:52] <cradek> so can I just stretch index with rc?
[02:21:11] <cradek> with tc of a base period or two
[02:21:20] <jmkasunich> not RC, unless you have a diode-R-C, and a schmidt buffer to square it back up
[02:21:37] <jmkasunich> I was thinking more like:
[02:21:48] <cradek> you need the pc to clear the index latch
[02:21:58] <jmkasunich> test input, if high set cnt to <somenum>
[02:22:10] <jmkasunich> if cnt > 0, dec cnt, set output
[02:22:12] <jmkasunich> else clear output
[02:22:34] <jmkasunich> probably 4-6 instructions of avr ode
[02:22:35] <jmkasunich> code
[02:22:48] <jmkasunich> and you only need to do it for one channel
[02:23:03] <jmkasunich> somenum is chosen to stretch it "enough"
[02:23:15] <cradek> ok
[02:23:22] <jmkasunich> you need at least one base-period, could be many because only the leading edge is used
[02:23:37] <SWPadnos> could have a problem with reversals though
[02:23:44] <SWPadnos> not htat those would be expected
[02:23:46] <SWPadnos> that
[02:23:51] <jmkasunich> spindle reversal during threading doesn't work anyway
[02:24:03] <cradek> if it does, it will be with index disabled
[02:24:10] <cradek> I mean, eventually
[02:24:22] <jmkasunich> yeah, index is used only to start the pass
[02:24:29] <jmkasunich> after that, only A & B are used
[02:24:36] <jmkasunich> until its time to start the next one
[02:24:43] <SWPadnos> sure - you just have the same jitter problems as the clock/dir approach
[02:24:56] <jmkasunich> ?
[02:26:21] <SWPadnos> it shouldn't matter in the application, but if the encoder bounces near the index, then you get a very long index pulse
[02:26:40] <SWPadnos> which is probably OK, since it's still near the index
[02:27:14] <jmkasunich> any edge (regardless of which way you are turning) will generate an index pulse
[02:27:29] <SWPadnos> yep
[02:27:33] <jmkasunich> if you are going backwards it will happen one encoder count sooner or later
[02:27:46] <jmkasunich> but you're dividing by 8 anyway, so +/- 1 don't matter
[02:27:49] <SWPadnos> I suppose it's just a retriggerable one-shot
[02:27:55] <jmkasunich> exactly
[02:28:07] <jmkasunich> and emc only cares about the leading edge
[02:28:27] <jmkasunich> and only the first leading edge, it doesn't re-arm itself until its time to start the next threading pass
[02:28:50] <jmkasunich> so index, can retrigger, bounce, do anything it wants
[02:29:36] <jmkasunich> hell, you could skip the stretcher if you wanted.... assuming a divide by 8, that means you have at least a 1 in 8 chance of seeing it without stretching
[02:29:54] <jepler> you'll see it "before long", eh?
[02:29:55] <jmkasunich> so at the beginning of a threading pass you might sit idle for several revs before you see the index, big deal
[02:30:00] <jmkasunich> yeah
[02:30:26] <jmkasunich> I certainly wouldn't ship something like that, but if cradek wants to test with the existing board, just wire the index straight to the parport
[02:30:56] <jepler> it sucks that the AVR doesn't have a barrel shifter. 3 instructions and 3 cycles to shift by 3 bits.
[02:31:20] <jmkasunich> * jmkasunich smacks jepler with a wet shifter
[02:31:22] <SWPadnos> 2 cycles to shift by 3 bits - there's a swap instruction
[02:31:25] <jmkasunich> don't shift!
[02:31:36] <jepler> jmkasunich: what then?
[02:31:40] <jmkasunich> bit set, bit test
[02:31:51] <jmkasunich> skip-if-bit-set, etc
[02:32:16] <jmkasunich> something like:
[02:32:29] <jmkasunich> read input to working reg R-IN
[02:32:43] <cradek> that's a good thought, I'll just be able to wire it up
[02:32:50] <jmkasunich> state[1-3] are three more registers
[02:33:07] <jmkasunich> skip-if-bit-set R-IN.bit-XENC-A
[02:33:22] <jmkasunich> set-bit STATE[1].bit0
[02:33:24] <cradek> even without dividing the spindle, I can thread as fast as at fest
[02:33:26] <jmkasunich> skip-if-bit-set R-IN.bit-XENC-B
[02:33:31] <jmkasunich> set-bit STATE[1].bit1
[02:33:51] <jmkasunich> STATE[1]=LUT[STATE[1]}
[02:34:12] <jmkasunich> skip-if-bit-set STATE[1].7
[02:34:30] <jmkasunich> set-bit R-OUT.outX-A
[02:34:33] <jmkasunich> skip-if-bit-set STATE[1].6
[02:34:36] <jmkasunich> set-bit R-OUT.outX-B
[02:34:45] <jmkasunich> repeat for state 2 and 3
[02:34:53] <jmkasunich> then write R-OUT to the port
[02:35:16] <jmkasunich> followed by the index stretcher, then back to the beginning
[02:35:17] <SWPadnos> this is for 3 encoders? (state 1-3)
[02:35:20] <jmkasunich> yeah
[02:35:35] <jmkasunich> actually the STATE[3] thing is dumb
[02:35:42] <jmkasunich> they're not really an array
[02:35:53] <SWPadnos> no matter - theyd be registers anyway
[02:35:55] <jmkasunich> STATE1, STATE2, STATE3 is more like it (or 0, 1, 2)
[02:36:01] <jmkasunich> right
[02:36:32] <jmkasunich> you'd unwrap the 1 to 3 loop, theres no cache here, no reason to loop it
[02:36:58] <jmkasunich> oh, I cheated a little
[02:37:05] <jmkasunich> you can't do LUT[STATE1]
[02:37:12] <SWPadnos> 14 cycles for the first channel
[02:37:17] <jmkasunich> you have to copy STATE1 to ZLO
[02:37:31] <jmkasunich> set ZHI (once at boot) so Z points to the LUT
[02:37:35] <SWPadnos> another 12 for each additional
[02:37:47] <SWPadnos> oops - maybe 16 for the first
[02:37:58] <jmkasunich> what are the extras?
[02:38:09] <SWPadnos> input and output from/to the I/O ports
[02:38:15] <SWPadnos> done once for all channels
[02:38:25] <jmkasunich> 2 clks for in and 2 for out
[02:38:43] <SWPadnos> yes
[02:38:46] <jepler> maybe better than skip/set is bst/bld
[02:38:52] <SWPadnos> nope
[02:38:58] <jepler> nope?
[02:39:02] <SWPadnos> no better
[02:39:11] <jmkasunich> no worse I don't think?
[02:39:12] <jepler> it can save you a masking off
[02:39:12] <SWPadnos> the skip / set is 2 cycles, bst / bld is 2 cycles
[02:39:18] <jepler> because it can put a 0 or a 1, not just a 1
[02:39:35] <SWPadnos> that's true, but the table would be craftily constructed to leave those bits at 0
[02:39:48] <jmkasunich> jepler: you can avoid the masking off, since the old value of state came from the LUT... just make the low 2 bits zero in every LUT entry
[02:40:10] <jmkasunich> gotta admit the bst/bld is clearer to read
[02:40:13] <jepler> do I have enough bits?
[02:40:41] <jmkasunich> yeah, if you choose state numbering carefully
[02:40:50] <jmkasunich> actually the bst/bld gives you more options
[02:41:04] <jmkasunich> because the LUT bits 0 and 1 can be the desired output bits
[02:41:12] <jepler> yeah that's the code I wrote
[02:41:36] <jepler> but if I can make the output bits be in the desired place in my word it's even better
[02:41:48] <jmkasunich> after the LUT, use bst/bld to copy bits 0/1 to the output, then next time use bst/bld to overwrite them with the new input
[02:41:51] <jmkasunich> thats better
[02:41:54] <jmkasunich> no faster, but better
[02:42:16] <jepler> (I'm working on a 1-channel version to fit on something like attiny13)
[02:42:22] <jmkasunich> you can't, if you are using the same lut for all channels
[02:42:33] <jmkasunich> oh, then yes
[02:43:13] <jepler> for the 4-channel version, have 4 LUTs; you load ZH once per channel but you turn 4 cycles of bit-shuffling into a mask
[02:43:19] <jmkasunich> state = state | (input port & mask)
[02:43:24] <jmkasunich> state = lut(state)
[02:43:35] <jmkasunich> out = state & othermask
[02:43:56] <jmkasunich> yeah
[02:44:04] <jepler> maybe you only save 1 cycle
[02:44:26] <jmkasunich> well, you gots 4 cycles of bit shuffling to get the new bits into state, and 4 more to get the output bits out
[02:44:42] <jmkasunich> if you replace _both_ sets of bitshuffling with masks, what do you gain?
[02:44:51] <SWPadnos> you have to load the mask, or save the IN register, so I don't think there's a savings
[02:45:13] <jmkasunich> I like the bitshuffling version myself
[02:45:37] <jmkasunich> as long as all ins are in one port and all outs are in another, you can have arbitrary pinout... your layout guy will thank you
[02:45:39] <SWPadnos> it has the advantage of working with bits in any position, and for the most part on any port
[02:45:55] <SWPadnos> you just read all ports, and the bits can be on any port as well
[02:46:09] <jmkasunich> at the expense of 2 clocks per extra read
[02:46:29] <SWPadnos> that would be 2 clocks overall, probably - you still need an output port or two
[02:46:44] <SWPadnos> same number of outputs as ionputs anyway
[02:46:46] <SWPadnos> inputs
[02:47:12] <jmkasunich> worst case is if you scatter inputs and outputs all over all the ports
[02:47:19] <jmkasunich> you might read em all and write em all
[02:47:31] <SWPadnos> right - then masking is needed for the outputs, and multiple accesses to the same port
[02:47:37] <SWPadnos> but it's easy to not be that dumb
[02:47:49] <SWPadnos> regardless of how much the layout guy will like you ;)
[02:48:04] <cradek> the layout guy already clocked out
[02:48:09] <SWPadnos> heh
[02:49:04] <jmkasunich> and the layout guy did _not_ mix inputs and outputs in the same port
[02:49:15] <jmkasunich> I think all ins are on one port and all outs are on another
[02:49:33] <cradek> right
[02:49:50] <cradek> in 0..6 on one port out 0..6 on another
[02:49:58] <cradek> 0..5
[02:50:06] <jmkasunich> so for this specific case, one read, twiddle some bits, one write
[02:51:11] <SWPadnos> well. time for me to go to bed. let's se ehow many aches and pains go away overnight
[02:51:23] <jmkasunich> ?
[02:51:32] <jepler> am I right in thinking that the maximum divisor with an 8-bit LUT and 2 of the bits used for the output, I can't divide by more than 16?
[02:51:39] <cradek> goodnight swp
[02:51:45] <jmkasunich> goodnight swp
[02:51:46] <SWPadnos> night guys
[02:51:48] <jepler> see you SWPadnos
[02:51:50] <SWPadnos> SWPadnos is now known as SWP_Away
[02:52:14] <jmkasunich> jepler, yeah, 64 possible "current states", each full quadrature cycle is 4
[02:52:32] <jmkasunich> so the complete "circle" is 16 full quadrature cycles, and generates one output cycle
[02:53:27] <jepler> so there's not much point in going faster than 16 * 50 kHz = 800kHz
[02:53:46] <jmkasunich> where did 50KHz come from?
[02:53:53] <jepler> 20uS base_period
[02:53:58] <jmkasunich> oh
[02:54:09] <jepler> I'm firmly in the context of "for use with emc"
[02:54:12] <jepler> "on a stupid parallel port"
[02:54:18] <jmkasunich> counting at 50KHz when you are sampling at 50KHz, is very iffy
[02:54:39] <jmkasunich> for rock solid counting, you should assume max encoder rate is 50% of the interrupt rate
[02:55:07] <jmkasunich> counting at 100% relies on perfect quadrature (90 degrees between A and B, exactly 50/50 duty cycle on both A and B)
[02:55:33] <jmkasunich> real encoder signals always vary a little (sometimes a lot)
[02:55:58] <jmkasunich> I've seen encoders spec'ed with 35% min and 65% max duty cycle
[02:56:30] <jmkasunich> anyway, assume that the PC can count at 25KHz with a 20uS base period
[02:56:49] <jmkasunich> 25KHz * 16 = 400KHz
[02:56:52] <jepler> are you saying there is or isn't virtue in sampling faster than 16 * BASE_PERIOD on the divider circuit?
[02:57:24] <jmkasunich> sampling faster is better
[02:57:58] <jmkasunich> the uC sampling the real encoder has the same issues as the PC sampling the divided one
[02:58:03] <jmkasunich> you want some margin
[02:58:14] <jmkasunich> the PC samples at 50KHz, and can count 25KHz
[02:58:28] <jmkasunich> if the uC samples at 200KHz it can reliably count at 100KHz
[02:58:34] <jmkasunich> count = divide
[02:59:01] <jmkasunich> if you are dividing by 16, then ideally you'd sample at 16x the PC rate
[02:59:11] <jmkasunich> more does no harm, but has no real benefit either
[02:59:29] <jmkasunich> less and the uC sampling rate becomes the limiting factor instead of the PC rate
[03:00:11] <jmkasunich> I think unless the uC is blazing fast and you are only doing one channel, the uC _will_ be the limiting factor
[03:00:38] <jepler> like I mentioned earlier, I am fiddling with a 1-channel version
[03:00:50] <jepler> a little quadrature divider daughter card
[03:01:16] <jmkasunich> 16 clocks for the first channel, 12 each for the other 2, is 40, plus say 6 clocks for an index stretcher and 2 for loop overhead, = 3uS on a 16MHz uC
[03:01:44] <jmkasunich> ok, say 18 clocks then, you'd be sampling just under 1MHz
[03:02:09] <jmkasunich> thats a good match with the PC at 50KHz
[03:03:55] <jepler> * jepler ponders how to build the table
[03:04:12] <jmkasunich> by hand
[03:04:14] <jmkasunich> in binary
[03:04:15] <jepler> I'll figure it out tomorrow
[03:04:18] <jmkasunich> lol
[03:04:20] <jepler> nah, I'm sure it involves a python program
[03:04:29] <jmkasunich> right, joking
[03:04:31] <cradek> goodnight jepler
[03:04:45] <jmkasunich> I'd use a C program, but same thing
[03:04:47] <jmkasunich> goodnight
[03:05:24] <jmkasunich> state machines are fun
[03:05:28] <jepler> your C program will run way faster than my Python program
[03:05:58] <jepler> you'll be able to generate thousands of state tables per second
[03:06:00] <jmkasunich> yeah, mine will produce the output (the one time I need it) in 1mS compared to your 10mS
[03:06:25] <jmkasunich> I can write it in C faster than I can write it in Python
[03:06:30] <jmkasunich> mostly because I don't know Python
[03:08:31] <jmkasunich> hmm, 11pm
[03:08:42] <jmkasunich> started talking about PWM component at 8pm
[03:09:00] <jmkasunich> stopped talking about PWM component 8:05pm
[03:09:19] <cradek> sigh
[03:09:29] <jmkasunich> pop, pop, pop, pop, pop
[03:09:30] <jmkasunich> there
[03:09:32] <cradek> we got a spec worked out though?
[03:09:40] <jmkasunich> not really
[03:09:50] <jmkasunich> I'm jsut gonna code something
[03:09:58] <cradek> oh you guys were talking about offset
[03:10:13] <cradek> I'm sure whatever you code will be 90-100% of what we want
[03:10:15] <jmkasunich> we got into the generic analog interface and before making much progress the stack just got deeper and deeper
[03:10:41] <fenn> backtrace:
[03:10:42] <cradek> actually I'm reasonably sure it'll be 100% of what I want
[03:10:52] <jmkasunich> I think I've figured out why I stay up so late - that's when everybody else goes away
[03:10:56] <jmkasunich> sometimes I need to talk things over
[03:11:09] <jmkasunich> other times I need to block it out, which I'm not good at doing
[03:11:17] <cradek> what a good idea: the /topic should be a stack
[03:11:26] <jmkasunich> heh
[03:11:27] <cradek> jmkasunich: I had that problem at fest, I hardly coded anything
[03:11:33] <cradek> /topic pop
[03:11:37] <jmkasunich> yep
[03:12:21] <jmkasunich> happens to be at work all the time too
[03:12:43] <jmkasunich> I swear I get more done between 4 and 6pm than I do between 9am and 4pm
[03:13:09] <jmkasunich> thats why I stayed so late at the fest
[03:13:10] <cradek> I would too, but I leave at 4 because I have to go in on time
[03:13:20] <cradek> their loss
[03:13:47] <cradek> anyway, get to work :-)
[03:13:54] <jmkasunich> :-P
[03:14:03] <cradek> I bet jepler and I can work out quadrature for my board now
[03:14:08] <jmkasunich> yeah
[03:14:16] <cradek> well, either of us could, but he may already have it written
[03:14:26] <cradek> my pulleys/belts came today
[03:14:30] <cradek> so I'm anxious to get the baord working
[03:14:52] <jmkasunich> oh, I just remembered something that should be good for one clock per channel
[03:15:14] <jmkasunich> copy the array into ram at boot, and use load indirect instead of load indirect from program space
[03:15:19] <jmkasunich> I think its a clock faster
[03:15:24] <cradek> yes it is
[03:15:49] <cradek> easy to get it on a "page" boundary too then
[03:16:08] <jmkasunich> also... there are three index registers you can use for ram, only one for program space
[03:16:23] <jmkasunich> you can eliminate the moves from STATE1 to ZLO
[03:16:33] <jmkasunich> just use XLO, YLO, and ZLO as the state vars
[03:16:54] <cradek> cool
[03:17:02] <jmkasunich> that way you could have different tables for each channel if you want, just set XHI, YHI, and ZHI different
[03:17:19] <jmkasunich> (uses 3/4 of the ram tho, not like you're using it for anything else)
[03:17:34] <cradek> yeah no problem there
[03:17:40] <cradek> should be all in regs
[03:17:49] <jmkasunich> heh, two LUTs, one for /8 and one for /16
[03:18:03] <jmkasunich> set the HI regs based on what you want each channel to be
[03:18:38] <cradek> that would be easy to get from jumpers
[03:18:42] <jmkasunich> one thing I noticed when I was messing with the layout...
[03:19:00] <jmkasunich> because of all the encoder sigs, the parport has to run in input mode
[03:19:05] <cradek> right
[03:19:08] <jmkasunich> there are only 4 outputs, and PWM uses them all
[03:19:11] <cradek> right
[03:19:13] <jmkasunich> so no spindle control
[03:19:15] <cradek> right
[03:19:51] <jmkasunich> thats what got me off on a tangent of some other communication (like parallel with handshaking or something) and counting/pwm/etc in the uC
[03:21:16] <jmkasunich> tangents tend to be time sinks
[03:21:44] <cradek> I'll have to go to a second parport for that if I want it eventually
[03:21:49] <fenn> i am aliving breathing time sink
[03:21:53] <cradek> argh my internets are flaky again
[03:22:00] <cradek> dammit
[03:22:26] <cradek> yeah I figure if I want to use one parport, i'll have to turn the knob for speed control
[03:22:40] <jmkasunich> at least this time around
[03:22:51] <cradek> parallel byte at a time with handshaking is very appealing
[03:23:00] <cradek> but right, not on the first try
[03:23:05] <fenn> using the EPP protocol
[03:23:11] <fenn> *ahem*
[03:23:37] <cradek> sure has been done before, hasn't it
[03:23:57] <cradek> I don't want to compete with that, I want simplicity, at least right now
[03:24:06] <jmkasunich> you know what is really intriguing? if you have bidirectional parallel with handshaking, you have your flash programming interface.....
[03:24:21] <fenn> using a bootloader of some sort
[03:24:26] <jmkasunich> yeah
[03:24:39] <fenn> why bother?
[03:24:46] <cradek> you don't want to program every time, it's limited cycles
[03:25:01] <jmkasunich> the hal driver would ask the board (bootloader) "what code do you have" and it would respond with a checksum or hash or maybe just a version string
[03:25:09] <jmkasunich> it would compare, and if not right, reflash
[03:25:30] <cradek> you do not want random parport signals to cause a reflash
[03:25:33] <jmkasunich> makes it easy to set divide ratios, etc
[03:25:38] <cradek> you want to require a jumper to allow it or something
[03:26:14] <cradek> but yeah I've done some parport stuff that could be reprogrammed just by adding a jumper
[03:26:35] <cradek> the step/dir-to-phasedrive jepler and I made was like that
[03:27:07] <jmkasunich> hal driver -> dmesg : "board firmware is at version FOO, driver is at version BAR, install jumper JP1 and try again to update"
[03:27:30] <cradek> sure that would be fine
[03:27:43] <cradek> it's interesting that the new firmware could be in a new emc release
[03:27:54] <jmkasunich> divide ratio would be even easier, just store the LUT in ram
[03:28:12] <jmkasunich> no wearout there, copy from PC to ram, instead of flash to ram
[03:28:30] <cradek> yes
[03:28:33] <cradek> that would be cool
[03:28:37] <fenn> why would you divide if you have bidir comms?
[03:28:42] <jmkasunich> true
[03:28:43] <cradek> there is that
[03:29:06] <jmkasunich> I have no interest in competing with Jon, but a small board with onboard drivers (L298) for low power would be cool
[03:29:15] <cradek> yes
[03:29:29] <jmkasunich> and could be a fraction of his cost, he has a lot of overhead because of the large drives and multi-board structure
[03:29:34] <cradek> his stuff is not hobby level
[03:29:38] <cradek> this would be
[03:29:46] <jmkasunich> right
[03:29:55] <fenn> welcome on board guys
[03:29:58] <jmkasunich> no opto-22 modules for I/O, etc
[03:29:59] <cradek> his stuff is not free/open, this would be
[03:30:19] <cradek> well at least if I did it
[03:30:24] <jmkasunich> right, thats where the flash from PC part is nice
[03:30:31] <cradek> because I'm allergic to making money apparently
[03:30:32] <fenn> www1.atwiki.com/gibery_machines/pages/iskewb if you want to contribute :)
[03:30:36] <fenn> aw damn
[03:30:50] <cradek> 404
[03:30:54] <jmkasunich> cradek: you make money selling the boards, not the design
[03:31:03] <fenn> sorry my crumb-laden fingers cant type right now
[03:31:15] <jmkasunich> not much money mind you
[03:32:09] <fenn> http://www1.atwiki.com/gingery_machines/pages/iskewb
[03:33:21] <cradek> I'll take two
[03:33:29] <jmkasunich> fenn: what kind of quantites do you expect to make?
[03:33:49] <fenn> well i got enough for 10 prototypes
[03:33:59] <fenn> i have no idea what kind of demand there is though
[03:34:15] <fenn> i'll post it on pminmo.com if its any good
[03:34:17] <cradek> how will it communicate with emc?
[03:34:21] <jmkasunich> if you have commercial boards made, most of your cost will be the glass
[03:34:25] <fenn> a custom hal module
[03:34:32] <cradek> epp parport?
[03:34:35] <fenn> yes
[03:34:35] <jmkasunich> I suggest SMT parts for things like bypass caps, saves space
[03:34:41] <fenn> epp == ieee1284
[03:35:26] <cradek> do you run pminmo?
[03:35:30] <fenn> no
[03:35:40] <fenn> he seems open to contributions though
[03:35:44] <cradek> ah
[03:35:45] <jmkasunich> what is pminmo?
[03:35:57] <cradek> the guy who designed the drivers running my mill
[03:35:57] <fenn> a webpage with a bunch of stepper driver designs
[03:36:10] <cradek> that pretty board I showed you last night
[03:36:28] <jmkasunich> you showed me a pretty board?
[03:36:34] <jmkasunich> senlilty must be kicking in
[03:36:34] <fenn> afaik there are no open true servo designs out there, mostly due to the popularity of mach
[03:36:40] <cradek> I think that's how you described it
[03:36:43] <cradek> on timeguy.com
[03:37:06] <jmkasunich> ok, that one
[03:37:10] <cradek> fenn: I'd sure like there to be
[03:37:59] <cradek> I think I'll have to stay here for the night because there's a kitten asleep on me
[03:38:12] <jmkasunich> heh
[03:38:28] <jmkasunich> fenn: re: stupid little gray pads
[03:38:38] <jmkasunich> the trick is to get the losses down low enough to use no heatsinks
[03:39:16] <jmkasunich> the motors are 12V and 10ohms?
[03:39:28] <jmkasunich> that means locked rotor current is only 1.2A
[03:39:53] <cradek> my little motors are also about 1A stalled
[03:40:23] <jmkasunich> even 100mOhm fets at 1.2A = 144mW, a TO-220 can do that without a heatsink
[03:40:29] <fenn> i wanted to design the h bridge to be able to drive beefire motors
[03:40:53] <jmkasunich> you'll pay then
[03:40:53] <fenn> and i'll be running the motors at 24 (or 32?) volts
[03:41:07] <fenn> i did find the little grey pads for $0.25
[03:41:32] <jmkasunich> still, 4 of em is $1.00, and then you have the heatink itself
[03:42:03] <jmkasunich> you should match the drive to the motor if you want to call it a "integrated motor module"
[03:42:17] <fenn> http://fenn.dyndns.org/pub/irc/iskewb.ps if you would please thrash this design for me sir, i would be grateful
[03:42:42] <jmkasunich> not tonight, but if you mail me something I'll take a look at it
[03:42:45] <fenn> oh and i know 32V is too much for some of the components on there
[03:42:51] <jmkasunich> pdf is better than ps
[03:42:53] <fenn> i'll try to apply my fixes and see what happens
[03:43:20] <fenn> http://fenn.dyndns.org/pub/irc/iskewb.pdf
[03:43:42] <jmkasunich> I bet you don't need 4700uF for your main cap
[03:43:49] <jmkasunich> (again, not for 1.2A anyway)
[03:44:07] <cradek> I bet you'll blow past Vbe on Q2,8
[03:44:24] <fenn> yes
[03:44:28] <jmkasunich> that kind of cross drive makes me shudder
[03:44:39] <fenn> that should be mpsa05 (?)
[03:44:46] <fenn> what should the low side look like?
[03:44:47] <jmkasunich> pick a current rating thats reasonable and I'll come up with a power stage for you
[03:44:49] <cradek> use a divider: 44v, r1, base, r2, emitter
[03:44:54] <fenn> 5A
[03:45:00] <cradek> err
[03:45:12] <cradek> use a divider: 44v, r1, pnp's base, r2, npn's collector
[03:45:13] <jmkasunich> all N channel I assume?
[03:45:22] <fenn> well i'd prefer to use the parts i've got already
[03:45:31] <jmkasunich> so all N channel it is
[03:45:40] <jmkasunich> cheaper if all the fets are the same
[03:45:50] <cradek> I've done that for high-side switches on nixies (250v) with Vbe(pnp) of 10v or so
[03:46:01] <jmkasunich> you have an actual supply that is greater than the main rail?
[03:46:12] <fenn> cradek: i knew there was a way to do that
[03:46:18] <fenn> jmkasunich: no not yet
[03:46:35] <jmkasunich> I mean "you need an actual supply that is greater than the main rail?"
[03:46:39] <fenn> i need to just breadboard this and see what goes pop
[03:47:16] <jmkasunich> are there diodes in series with the motor?
[03:47:31] <fenn> 30V zeners
[03:47:32] <jmkasunich> D1 and D2
[03:47:44] <jmkasunich> not in series with the motor!
[03:48:02] <fenn> thanks for pointing that out :)~
[03:48:13] <cradek> haha
[03:48:23] <jmkasunich> you'll dissipate more power in the zeners (think 0.6V drop) than in the mosfets
[03:49:15] <cradek> for 1-2A <45v half of an L298 replaces all of this nicely
[03:49:22] <fenn> yes i know
[03:49:31] <cradek> but costs more?
[03:49:38] <fenn> * fenn whines
[03:49:38] <jmkasunich> I bet you can parallel both halves too
[03:49:51] <cradek> yes I think you can
[03:50:04] <cradek> or there's a different one L295? that's meant as a motor driver
[03:50:11] <fenn> actually it costs more
[03:50:24] <cradek> I don't doubt it, I think they're $8 or so
[03:50:26] <fenn> l298 is $3 vs 4*$0.37
[03:50:33] <jmkasunich> no!
[03:50:40] <cradek> only $3 for two motors?
[03:50:47] <jmkasunich> you can't compare 4 fets to a L298
[03:50:49] <fenn> unless there is extra stuff in an l298 i dont know about
[03:50:54] <jmkasunich> what about the drive circuitry?
[03:51:03] <cradek> all the drive is in there
[03:51:04] <fenn> some resistors and transistors?
[03:51:04] <jmkasunich> L298 is TTL in, and drives the transistors
[03:51:20] <jmkasunich> (far better than your drive circuit too)
[03:51:22] <fenn> that was the part i didnt understand, why there are all these fancy mosfet driver IC's
[03:51:28] <jmkasunich> (no offense, but that makes me shudder)
[03:51:42] <jmkasunich> because driving mosfets is non-trivial
[03:52:20] <jmkasunich> if all you are doing is turning on/off a non-inductive load at low frequencies, you can drive a mosfet gate with a high impedance source
[03:52:39] <jmkasunich> if you are switching motor windings at PWM frequencies, you need to do it right
[03:52:53] <jmkasunich> guaranteed dead-time (no shoot-thru)
[03:53:26] <fenn> dont i only have to worry about that when reversing?
[03:53:28] <jmkasunich> controlled switching speed - too slow means high conduction losses, too fast means L*dI/dT or C*dV/dT noise
[03:53:43] <jmkasunich> depends on your switching pattern
[03:54:23] <jmkasunich> actually, now that I look closer, I suspect your bridge will burn out the first time you switch it
[03:54:37] <jmkasunich> assume Q5 and Q4 are on
[03:54:56] <jmkasunich> current is flowing from the supply, to the left, down, thru the motor left to right, down, and into ground
[03:55:08] <jmkasunich> now you remove the command voltage from PWMA
[03:55:13] <jmkasunich> Q5 turns off
[03:55:22] <jmkasunich> current is still flowing thru the motor inductance
[03:55:44] <jmkasunich> that means the left side of the bridge moves down (voltage drops)
[03:56:02] <jmkasunich> eventually the current winds up flowing thru the Q3 freewheel diode
[03:56:12] <jmkasunich> meanwhile, the dropping voltage turns off Q4
[03:56:23] <jmkasunich> the inductive current pushes the right side up
[03:56:40] <jmkasunich> eventually the Q6 freewheel diode turns on
[03:57:05] <jmkasunich> current is now flowing thru the two FWDs, up thru Q3, left to right, and up Q6
[03:57:24] <jmkasunich> since the right side is high, Q3 turns on (even tho the current is in the diode, the fet is on too)
[03:57:41] <fenn> so i want q4 to stay on and dump the current into ground?
[03:57:42] <jmkasunich> now later you turn PWMA back on, turning on Q5 while Q3 is on
[03:57:52] <jmkasunich> poof
[03:57:55] <jmkasunich> yes, probably
[03:58:17] <jmkasunich> that cross-connection might work with a resistive load, but never with inductive or motor load
[03:58:29] <fenn> so the signal to turn on the gate of q4 and q5 should be tied together?
[03:58:48] <jmkasunich> they both need to turn on and turn off under the control of PWMA
[03:59:04] <jmkasunich> you can't just tie them together, tho, Q5 is high side, Q4 is low side
[03:59:17] <jmkasunich> Q5 needs level shifting and Q4 doesn't
[03:59:20] <fenn> right
[03:59:44] <jmkasunich> you might be able to hook Q4's gate directly to PWMA, depending on how big Q4 is and what you are driving PWMA with
[04:00:01] <jmkasunich> likewise with Q3 and PWMB of course
[04:00:36] <jmkasunich> another approach (more flexible if you have the pins) is to have independent uC control of all four FETs
[04:00:47] <jmkasunich> (four control wires instead of 2)
[04:01:11] <jmkasunich> just make sure you never turn high and lo on the same side on at the same time
[04:01:40] <fenn> that sounds too easy :)
[04:02:10] <jmkasunich> power up and power down are the fun cases... is your micro guaranteed to keep all outputs low when the power supply is at say 2 volts?
[04:02:52] <jmkasunich> the need for an extra supply just for high side drive is also a problem
[04:02:59] <jmkasunich> one way or another that is gonna cost
[04:03:15] <jmkasunich> either a transformer winding, diode and cap, or a dc-dc converter, or something
[04:03:26] <jmkasunich> thats why most fet drivers use bootstrapping
[04:03:47] <fenn> what is bootstrapping?
[04:03:52] <fenn> a dc/dc converter?
[04:03:54] <jmkasunich> no
[04:04:09] <jmkasunich> say you have a 12V supply for gate power
[04:04:28] <jmkasunich> separate from your motor power supply, that can be 12, 24, 48, 480, doesn't matter
[04:04:46] <jmkasunich> for the low side, just drive the gate with 0-12V, done
[04:05:06] <jmkasunich> for the high side, put a 10uF cap, negative lead connected to fet source
[04:05:15] <jmkasunich> positive lead connected to whatever drive circuit you have
[04:05:24] <jmkasunich> connect a diode from +12 to the top of the cap
[04:05:48] <jmkasunich> when the low side FET is on, the high side source is held near ground, and the cap charges to +12 thru the diode
[04:05:54] <jmkasunich> then you turn off the low side and turn on the high side
[04:06:01] <jmkasunich> as it turns on, its source goes up
[04:06:05] <jmkasunich> the cap goes up with it
[04:06:18] <jmkasunich> eventually the source is just a little below the main motor supply rail
[04:06:27] <jmkasunich> and the top of the 10uF cap is 12V above the rail
[04:06:37] <jmkasunich> pulled itself up by its own bootstraps
[04:06:46] <jmkasunich> (the diode turns off during this of course)
[04:07:03] <jmkasunich> you can't hold at 100% high duty cycle, because the cap eventually runs down
[04:07:13] <fenn> ok so you're using the high side fet as part of a dc/dc converter
[04:07:13] <jmkasunich> but thats usually not a major problem
[04:07:29] <jmkasunich> I suppose thats one way of looking at it
[04:07:38] <jmkasunich> but its a darned cheap converter
[04:08:56] <jmkasunich> looking at your webpage again...
[04:09:02] <jmkasunich> the motor connector thing
[04:09:18] <jmkasunich> why not whack off the existing motor connector and solder the leads right to the board
[04:09:35] <jmkasunich> I thought you were doing an "integrated motor and driver" thing?
[04:09:49] <fenn> how would that be better?
[04:10:10] <fenn> the only reason i didnt just buy a connector was i didnt know how to look for it
[04:10:11] <jmkasunich> cheap (in both parts and labor)
[04:10:30] <jmkasunich> if the board is fastened to the back of the motor, who needs a connector?
[04:11:11] <fenn> when testing things with little equipment it helps for things to be modular, so you can swap in a known good module and isolate the source of the problem
[04:11:30] <jmkasunich> ok, fine... as long as you are talking about testing I agree
[04:11:46] <jmkasunich> your webpage talks as if it is your plan for a "product"
[04:12:29] <fenn> well this is my first project i've needed more than one of
[04:12:38] <fenn> like, a lot more than one of
[04:12:57] <fenn> and i figure if i'm gonna be making a lot i might start selling them eventually
[04:13:07] <fenn> but i really did just need a name to refer to it
[04:13:38] <jmkasunich> ;-)
[04:14:21] <jmkasunich> if you are at all serious about a motor/drive module, you should figure out the max motor current, and design for that
[04:14:37] <jmkasunich> I bet you can loose the heatsinks and gray pads right off the top
[04:14:48] <fenn> i still need a box to put it in
[04:15:01] <jmkasunich> can't attach the board to the back of the motor?
[04:15:09] <fenn> the idea was to heatsink the motor so i could get more power out of the motors
[04:15:10] <jmkasunich> I guess you want more protection than that
[04:15:28] <fenn> and while i was making a custom heatsink to go on the motor i'd make it a watertight enclosure for the electronics
[04:15:29] <jmkasunich> that will be of minimal benefit unless its a really strange motor
[04:15:57] <jmkasunich> (heatsinking the motor that is)
[04:16:09] <jmkasunich> if its a normal DC motor, the thing that gets hot is the rotor winding
[04:16:24] <jmkasunich> which doesn't have good thermal contact to the case
[04:17:03] <jmkasunich> heat has to travel either across the airgap to the frame, or along the shaft and thru the bearings to the frame (or along the shaft and then directly to the air)
[04:18:08] <jmkasunich> thats one of the big advantages of brushless motors - the windings are on the frame where you can get the heat out of them
[04:18:58] <fenn> but still, if i cut down on the case temperature it will get heat out of the windings faster due by radiation
[04:19:57] <jmkasunich> true, but not by a lot
[04:20:01] <jmkasunich> 10% maybe
[04:20:08] <jmkasunich> 20% if you are really lucky
[04:20:27] <jmkasunich> heat goes as the square of current, torque goes as current
[04:20:45] <jmkasunich> so 20% more heat is only 10% more current (approx) and 10% more torque
[04:23:43] <fenn> why do i see h bridge designs with this criss-cross stuff on the bottom then?
[04:23:53] <jmkasunich> where do you see them?
[04:25:41] <fenn> well here is one
http://www.armory.com/~rstevew/Public/Motors/H-Bridges/Blanchard/nch-brdg.htm
[04:25:59] <fenn> here is another (sorta)
http://openservo.com/moin.cgi/Schematic2
[04:28:42] <fenn> ok that is all :)
[04:28:45] <jmkasunich> just read the first one
[04:29:23] <jmkasunich> he doesn't mention anything about how it works during the time right after turn-off when the inductance of the motor is still pushing current thru the freewheel diodes
[04:29:43] <jmkasunich> maybe he _always_ waits until the current decays before turning it back on
[04:30:08] <jmkasunich> he doesn't say anything about PWM, maybe he only does forward/off/reverse
[04:30:58] <jmkasunich> read the third sentence in the last paragraph
[04:31:24] <jmkasunich> that one little sentence just touches on some real world stuff that he really hasn't addressed at all
[04:32:11] <fenn> "MOSFETS turn on very fast..."?
[04:32:18] <jmkasunich> sorry, I guess I shouldn't be so harsh
[04:32:35] <jmkasunich> its just that these strike me as very amateur circuits
[04:32:55] <fenn> well, i see a lot of stuff that is very professional and a lot that is very amateur
[04:33:11] <fenn> but there's nothing that explains _why_ they are doing what they do
[04:33:28] <fenn> or else i havent spent enough time searching yet
[04:33:56] <jmkasunich> you want to learn about mosfets you need to get an international rectifier HEXFET data book and read the app notes and introductory chapters
[04:34:06] <jmkasunich> that stuff might be online, dunni
[04:34:08] <jmkasunich> dunno
[04:34:13] <fenn> probably
[04:34:13] <jmkasunich> I learned in the days of paper
[04:34:45] <fenn> i am still reading a lot of different things at once
[04:34:52] <fenn> but i'm getting impatient
[04:35:31] <fenn> usually i learn things really fast, i guess i must be doing something wrong
[04:35:57] <jmkasunich> are you in school (college)? done?
[04:36:01] <fenn> done :)
[04:36:06] <jmkasunich> what major?
[04:36:10] <fenn> mirobiology BS
[04:36:21] <jmkasunich> no electronics?
[04:36:25] <fenn> was more interested in molecular biology and genetic engineering
[04:36:52] <jmkasunich> ok, so you are basically an interested beginner when it comes to electronics
[04:36:59] <fenn> my previous electronics experience is a 555 timer pretty much
[04:37:20] <jmkasunich> you know ohms law, V=L*dI/dT, CV=IT, etc, and can apply them where needed?
[04:37:27] <fenn> i am finally able to recognize a voltage divider, bypass cap, r/c filter
[04:37:49] <jmkasunich> basic circuit analysis, kirkcoffs law, etc? (I spelled it wrong, but...)
[04:38:12] <fenn> i dont know about that last one
[04:38:32] <fenn> ok yeah
[04:38:32] <jmkasunich> you may know it without knowing the name
[04:38:52] <jmkasunich> I have a suggestion for you
[04:39:09] <jmkasunich> Horowitz and Hill: The Art of Electronics
[04:39:13] <fenn> no! i hate that book!
[04:39:33] <jmkasunich> why?
[04:39:41] <fenn> i must have sat down to read that like 20 times when i was a kid and it never made any sense
[04:40:10] <jmkasunich> you don't read it like a novel
[04:40:37] <jmkasunich> you look up what you are trying to figure out, and read a few pages
[04:40:58] <jmkasunich> if you get lost, then you need to go to an earlier chapter and read a few pages about some more fundamental thing
[04:41:27] <jmkasunich> you know basic op-amp circuits? inverting, non-inverting, etc
[04:41:37] <jmkasunich> can you make a gain of 10 op-amp ckt?
[04:41:41] <fenn> no
[04:42:08] <jmkasunich> you need a good basic electronics book
[04:42:21] <jmkasunich> maybe not The Art Of, but something
[04:43:15] <jmkasunich> Horowitz covers an enormous amount of stuff in one book, maybe too much
[04:44:03] <jmkasunich> http://www.irf.com/technical-info/guide/
[04:44:20] <jmkasunich> take a look at basic circuit theory
[04:44:32] <fenn> wow
[04:44:41] <fenn> they go right down to the nuts and bolts eh
[04:44:53] <jmkasunich> yeah
[04:45:08] <jmkasunich> skip the next two sections, device physics is for eggheads
[04:45:44] <jmkasunich> actually the last half of the third section isn't bad
[04:46:08] <jmkasunich> damn, not enough detail
[04:46:25] <jmkasunich> they have a pic of a boost converter, but they don't explain the operating cycle
[04:47:55] <fenn> i expected there to be more than 3 circuits
[04:48:00] <jmkasunich> ?
[04:48:05] <fenn> http://www.irf.com/technical-info/guide/apps.html
[04:48:44] <jmkasunich> they skip a lot of stuff
[04:48:57] <jmkasunich> http://www.irf.com/technical-info/guide/circuit.html
[04:49:03] <jmkasunich> figure 7
[04:49:15] <jmkasunich> the basics of switching power devices
[04:49:34] <jmkasunich> you need to _understand_ what is going on in that pic
[04:50:01] <jmkasunich> they ignore gate drive details there, focus on the output side
[04:50:14] <jmkasunich> FET (DUT) turns on
[04:50:24] <jmkasunich> drain voltage drops to near zero
[04:50:37] <jmkasunich> vdd is still on the right side of the inductor
[04:50:44] <jmkasunich> so there is voltage from right to left
[04:50:53] <jmkasunich> that drives an increasing current from right to left
[04:51:07] <jmkasunich> (dotted scope trace, sloping up)
[04:51:11] <jmkasunich> follow me so far?
[04:51:14] <fenn> yes
[04:51:20] <jmkasunich> then they turn it off
[04:51:25] <fenn> what does AS stand for?
[04:51:29] <fenn> in I(AS)
[04:51:44] <fenn> anode/source?
[04:51:46] <jmkasunich> not sure
[04:51:52] <jmkasunich> s is probably source
[04:52:15] <jmkasunich> that just shows where they are measuring the current
[04:52:23] <jmkasunich> normally it would just be Is
[04:52:37] <jmkasunich> voltages are always between two points (even if one is ground)
[04:52:51] <jmkasunich> so Vds, Vgs, Vce, Vbe, etc
[04:53:01] <jmkasunich> currents flow thru a single wire
[04:53:07] <jmkasunich> Ib, Ic, Id, Is, etc
[04:53:58] <jmkasunich> the meaning of the letters isn't that important here, you can match up the scope trace labeled Ias with the point on the ckt labeled Ias, thats what counts
[04:54:12] <fenn> why is V(BR)DSS square at the top?
[04:54:18] <fenn> shouldnt it go to infinity?
[04:54:26] <fenn> er, the diode reverse breakdown
[04:54:30] <jmkasunich> yep
[04:54:41] <fenn> ah
[04:54:42] <jmkasunich> notice the diode symbol looks like a zener
[04:54:48] <jmkasunich> any real part has some breakdown voltage
[04:55:22] <jmkasunich> normally its bad news to break it down, but some fets are "avalanche rated" which means they can absorb a certain amount of energy that way
[04:55:37] <jmkasunich> this is an abusive test
[04:55:45] <fenn> ok
[04:56:17] <jmkasunich> but if you had a relay coil for example, with a fairly low inductance and low current (maybe 100mA or something) and wanted to use a small fet to drive it, you could do that and let the fet absorb the energy
[04:56:36] <jmkasunich> its better to provide someplace else for the energy to go
[04:56:49] <jmkasunich> like a diode from the left side of the coil in the pic to the right
[04:56:53] <jmkasunich> there are tradeoffs tho
[04:57:01] <fenn> with a lower breakdown voltage?
[04:57:10] <jmkasunich> no, it doesn't break down
[04:57:15] <jmkasunich> arrow points right
[04:57:39] <fenn> oh so the energy is dissipated in the coil
[04:57:39] <jmkasunich> when fet is on, left side is near ground, right side is at Vdd, diode is reverse biased
[04:57:53] <jmkasunich> when it turns off, the left side starts to shoot up
[04:58:23] <jmkasunich> but when it gets 0.6V above Vdd, the diode conducts, and the current can circulate thru diode and inductor until it dies out
[04:58:41] <jmkasunich> the tradeoff is that it takes much longer for the current to decrease
[04:58:53] <jmkasunich> with the original circuit, the voltage went very high on the left
[04:58:58] <fenn> what if you had a resistor in series with the diode?
[04:59:07] <jmkasunich> that would make it die out faster
[04:59:30] <jmkasunich> but the voltage on the fet would be higher too, by the initial coil current times the resistor value
[05:00:06] <jmkasunich> but you're catching on, that is one technique... pick the right resistor to compromize peak voltage (don't break down the fet) and current decay time
[05:00:27] <jmkasunich> the rate of current rise and fall depends on the voltage and the inductance
[05:00:34] <jmkasunich> that is V=L*dI/dT
[05:01:05] <jmkasunich> (re-arrange to dI/dT = V/L, or I = V*T / L
[05:01:45] <jmkasunich> with the diode in there, V is only 0.6V, current decays slowly
[05:02:11] <jmkasunich> without the diode, V (after turn off) is breakdown voltage Vbr - Vdd, and the current decays fast
[05:03:11] <jmkasunich> anyway, this kind of thing, where you look at the current in the inductor, and see where it is going to flow, is needed to analyze more complex circuits like H bridges
[05:04:38] <jmkasunich> I'm kind of dissapointed in IRs website
[05:05:05] <jmkasunich> they older app notes and such (from when mosfets were fairly new) were much more educationsl
[05:05:19] <fenn> have you been looking at the app notes online?
[05:05:23] <jmkasunich> now everything is focused on some specific part for some specific niche
[05:05:33] <jmkasunich> browsing the titles
[05:06:07] <jmkasunich> notice they start at AN-978?
[05:06:16] <jmkasunich> they used to start at AN-1 ;-)
[05:06:31] <jmkasunich> you would probably benefit a lot more from the first few dozen
[05:06:36] <fenn> sounds like it
[05:06:52] <fenn> that is what i meant by there is a lot of professional and a lot of amateur stuff but nothing in between
[05:07:03] <jmkasunich> yeah
[05:07:33] <jmkasunich> there is some, but you kind of already have to know the stuff to know when you've found a good source
[05:07:38] <jmkasunich> chicken/egg problem
[05:07:38] <fenn> my library probably wont have anything good, but i'll check
[05:08:01] <fenn> i think i've looked at the electronics section 5 or 6 times and was disgusted
[05:09:07] <jmkasunich> http://www.irf.com/technical-info/appnotes/mosfet.pdf
[05:09:13] <jmkasunich> "power mosfet basics"
[05:09:37] <jmkasunich> it starts out yucky, I dunno why these folks always feel they have to go into device physics
[05:09:45] <jmkasunich> but it gets better a few pages down
[05:10:14] <jmkasunich> the part about gate charge is usefull to understand how mosfets switch
[05:10:31] <fenn> while i'm at it, what's the difference between a FET, a MOSFET, an IGFET, and an IGBT
[05:10:41] <fenn> er, scratch IGBT from that list
[05:10:46] <jmkasunich> heh
[05:11:05] <fenn> wait, igbt doesnt have a gate charge does it?
[05:11:10] <jmkasunich> yes it does
[05:12:53] <jmkasunich> FET is a blanket term for several kinds of devices
[05:13:19] <jmkasunich> IGFET isn't used often, but I think it means Insulated Gate FET
[05:13:38] <jmkasunich> one of the two main types of fets, the other is JFET, Junction FET
[05:14:12] <jmkasunich> MOSFET is Metal Oxide Semiconductor FET, which is a specific type of Insulated Gate FET
[05:14:32] <jmkasunich> (where the gate electrode is metal and the insulation is silicon oxide)
[05:14:50] <fenn> oh, i thought metal oxide was like, alumina
[05:15:02] <jmkasunich> since 99.9% of IGFETs are MOSFETs, you don't hear IGFET much
[05:15:18] <jmkasunich> not when talking about semiconductors
[05:15:36] <jmkasunich> oxide = silicon oxides, similar to glass
[05:15:44] <fenn> ok
[05:16:28] <jmkasunich> poo, I'm really dissipointed in IRs website
[05:17:04] <jmkasunich> I learned much of what I know from their databooks, and that stuff is just plain gone now
[05:17:20] <fenn> how did you get those books?
[05:17:47] <jmkasunich> in the days before the web, vendor salesmen would come to electronics companies with boxes of databooks
[05:17:55] <jmkasunich> and all engineers had shelves full of them
[05:18:20] <jmkasunich> or you could call up the vendor and ask for a databook and they would send it to you
[05:18:38] <fenn> a databook is like, datasheets for a part family?
[05:19:01] <jmkasunich> heh, the datasheets you get on the web are like, pages ripped out of a databook ;-)
[05:19:11] <fenn> so everything beginning with IRF5 would be a databook?
[05:19:26] <jmkasunich> they had a book for all their mosfets
[05:19:33] <jmkasunich> maybe 1.5" thick
[05:19:37] <fenn> no way
[05:19:44] <fenn> there are like millions of them now
[05:19:46] <jmkasunich> they have a lot more mosfets now
[05:20:06] <jmkasunich> databooks use thin paper
[05:20:10] <jmkasunich> think phone book
[05:20:24] <jmkasunich> anywhere from 300 to 800 pages
[05:20:29] <jmkasunich> 2-3 pages per part
[05:21:15] <jmkasunich> when IR first started selling mosfets, there was only one part numbering scheme
[05:21:20] <jmkasunich> IRFXYY
[05:21:34] <jmkasunich> X was 1,2,3,4,5 and indicated the voltage group
[05:21:47] <jmkasunich> YY was 10,20,30,40,50 and indicated the current
[05:22:04] <jmkasunich> (not directly, just 20 was bigger than 10)
[05:22:20] <jmkasunich> so an IRF450 was the big boy
[05:22:40] <jmkasunich> TO-3 cases
[05:22:44] <jmkasunich> then the numbers started over
[05:23:01] <jmkasunich> IRF510 was the same as IRF110, except in a TO-220 case
[05:23:08] <jmkasunich> ditto up to IRF950
[05:23:14] <jmkasunich> and that was it
[05:23:23] <jmkasunich> this was probably early 80's
[05:23:40] <jmkasunich> since they were so new, thats why the databooks had so much good educational stuff in them
[05:23:45] <fenn> right
[05:23:50] <jmkasunich> _everybody_ had to learn how to use them
[05:25:48] <jmkasunich> http://www.web-ee.com/primers/Tutorials.htm
[05:26:30] <jmkasunich> some decent stuff there
[05:26:38] <jmkasunich> four on mosfets
[05:26:41] <fenn> NEETS is good stuff, but old and based on tubes
[06:56:16] <LawrenceG> jmkasunich: hi.... :{ lost the bid on your raritan switch, but I did bid it up in price!
[06:58:08] <alex_joni> how much did it go for?
[07:02:24] <LawrenceG> I'll check... about $30 I think
[07:03:01] <LawrenceG> yea... $29.58 plus $145 shipping !!
[07:03:17] <LawrenceG> kidding...
[07:04:25] <alex_joni> lol
[07:04:31] <LawrenceG> Item number: 9731348795
[07:04:54] <LawrenceG> time for bed here.... just past midnite
[07:10:43] <alex_joni> g'night
[13:15:11] <SWP_Away> SWP_Away is now known as SWPadnos
[14:17:39] <Roguish> SWPadnos: got just a minute? what's the latest in regards to the m5i20? i have seen some work being 'committed'. also, Peter W mentioned he is doing some additional work. what's your take?
[14:18:04] <SWPadnos> I haven't had a chance to look at it in the past few weeks
[14:18:22] <SWPadnos> I have a newer version of the FPGA code, for 8 axes, I think
[14:18:29] <SWPadnos> it also fixes one or two bugs
[14:18:48] <SWPadnos> I haven't had a chance to check it, compile it for the FPGA, and commit the changes yet
[14:18:56] <Roguish> bugs?
[14:19:15] <SWPadnos> I think there was an issue with the secondary encoder counters or something
[14:20:13] <SWPadnos> yep - 8 axis instead of 4, and the bug was in some secondary encoder connections
[14:20:20] <Roguish> my large gantry router client just had a smaller router machine literally burn up over the weekend. he now needs another machine, fairly quickly.
[14:20:26] <SWPadnos> bummer
[14:20:33] <Roguish> not for me!!!
[14:20:41] <SWPadnos> heh
[14:20:54] <Roguish> it was old, home brew.... i warned them repeatedly.
[14:21:01] <SWPadnos> the new stuff Pete W was talking about is a step/dir version instead of PWM
[14:21:10] <SWPadnos> I don't think that's done yet
[14:21:16] <Roguish> most probably an electrical problem.
[14:22:21] <SWPadnos> that's not good
[14:22:31] <Roguish> i am not too interested in step/direction. stepper are not appropriate for my systems. i need industrial strength ac/dc drives and motors.
[14:22:54] <SWPadnos> ok. then the 8 axis PWM version would be ideal
[14:23:06] <Roguish> has anyone put together a hal file for a gantry system?
[14:23:09] <SWPadnos> though the 4 axis version (as it is now) would probably be fine
[14:23:32] <SWPadnos> they're generally the same as for a mill, just the accel/vel parameters need to change (and of course the limits)