Back
[00:08:42] <cradek> ah, much better
[00:11:43] <jepler> $ uname -a; head -2 /proc/rtapi/status; emc2/bin/halcmd show thread
[00:11:41] <jepler> Linux tall 2.6.20.12 #2 PREEMPT Wed May 30 18:08:58 CDT 2007 x86_64 GNU/Linux
[00:11:41] <jepler> ******* RTAPI STATUS ********
[00:11:41] <jepler> RT Modules = 3
[00:11:41] <jepler> Realtime Threads:
[00:11:45] <jepler> Period FP Name (Time, Max-Time)
[00:11:48] <jepler> 999980 NO thread ( 136, 2317 )
[00:11:48] <jepler> 1 and2.0
[00:11:56] <cradek> whee
[00:12:02] <jepler> I must say: holy shit, I never expected to get here in less than 4 hours
[00:12:21] <cradek> I sure wouldn't have expected that either.
[00:12:49] <cradek> but I guess that only means that 4 hours in, you still don't know what the insurmountable problem will be :-)
[00:12:58] <cradek> (sorry)
[00:13:00] <skunkworks> amd kernel?
[00:13:12] <jepler> cradek: I'm sure you're right
[00:15:17] <jepler> contrary to my fear/expectation, floating point doesn't immediately break everything:
http://emergent.unpy.net/index.cgi-files/sandbox/siggen-realtime-amd64.png
[00:15:29] <cradek> wow
[00:15:38] <cradek> (ENOENT)
[00:16:10] <jepler> oops, EAGAIN
[00:16:51] <jepler> now disturbingly, my load is 14 and it says I'm using 100% CPU...
[00:16:56] <cradek> hmm
[00:17:02] <cradek> I notice halscope works too
[00:18:01] <jepler> Unexpected realtime delay: check dmesg for details.
[00:18:49] <jepler> 3D_Chips seems to be milling in tkemc
[00:19:05] <cradek> that's unpossible
[00:19:27] <jepler> I must be doing something wrong, such as actually running the simulator
[00:19:36] <jepler> halcmd: loadrt hal_parport
[00:19:36] <jepler> halcmd:
[00:20:10] <jepler> hm this is not what I expected in the log:
[00:20:11] <jepler> [ 3830.008262] In recent history there were
[00:20:11] <jepler> [ 3830.008263] 2009142, 1908, 2010087, 2008173, and 2009117
[00:20:11] <jepler> [ 3830.008265] elapsed clocks between calls to the motion controller.
[00:20:13] <jepler> [ 3830.008266] This time, there were 2007608 which is so anomalously
[00:20:16] <jepler> [ 3830.008267] large that it probably signifies a problem with your
[00:20:16] <jepler> [ 3830.008268] realtime configuration. For the rest of this run of
[00:20:19] <jepler> [ 3830.008270] EMC, this message will be suppressed.
[00:21:00] <cradek> ouch
[00:21:12] <cradek> that one seems a little on the short side.
[00:22:32] <SWPadnos> not if you add the magic number 2097152 or something
[00:26:47] <jepler> .. it's running the nist lathe ..
[00:26:54] <SWPadnos> cool
[00:27:10] <SWPadnos> this is UP?
[00:27:17] <jepler> yes, amd64 but with UP kernel
[00:27:20] <SWPadnos> ok
[00:28:19] <jepler> OK, here's the first sign of weirdness: "Cannot move rotary axes with G76"
[00:28:57] <SWPadnos> isn't that some peck drilling cycle or something?
[00:29:09] <jepler> threading canned cycle
[00:29:18] <SWPadnos> ok
[00:29:47] <SWPadnos> that error makes sense to me, but I don't know if it's "normal"
[00:30:00] <jepler> there are no rotary axes defined
[00:30:11] <SWPadnos> oh, well that could be a weirdness ;)
[00:30:28] <jepler> though I accidentally used an old tree, so it may be the "# joints" thing that got fixed in the last month or so
[00:31:47] <SWPadnos> well, you've discovered a bug in the documentation - the fact that a rotary axis move isn't allowed with g76 isn't in the manual
[00:33:59] <cradek> ha
[00:38:54] <cradek> lathe-pluto cut its first thread (using tool offsets, in non-native units)
[00:40:34] <skunkworks> again. You guys are unreal
[00:42:34] <cradek> it's such a relief to have the tool table working - I really need it for this machine
[01:00:08] <jepler> I ran a threading cycle in the air
[01:01:04] <jepler> the motors sounded good the whole time. on that run I didn't get the "unexpected realtime delay" message.
[01:01:36] <cradek> nice
[01:01:40] <cradek> I can't believe you have that working already
[01:02:28] <jepler> there are a number of gross hacks in emc2
[01:02:39] <cradek> nah I can't believe that
[01:03:28] <SWPadnos> gross as in large, or gross as in "ewwww"
[01:03:31] <jepler> ewwww
[01:03:54] <SWPadnos> of course, the two aren't mutually exclusive
[01:26:09] <jepler> http://axis.unpy.net/01180573281 <-- kernel configuration, emc2 patch, and general instructions just in case anybody else is interested in this
[01:26:34] <SWPadnos> thanks
[01:26:41] <SWPadnos> I'm definitely interested
[01:27:33] <SWPadnos> I had a problem where the SMP kernel would boot if I used MODVERSIONS, but not without it
[01:27:38] <SWPadnos> which didn't work so well with RTAI ...
[01:27:39] <cradek> I'm intersted even though I'm not going to use it
[01:31:09] <SWPadnos> hmmm - did you just use "mkinitramfs", or was it mkinitrd? (and what command line options if any?)
[01:32:29] <jepler> from memory: mkinitramfs -o /boot/initrd.img-2.6.20.12 2.6.20.12
[01:33:52] <SWPadnos> ok, so nothing special, just the name and version as expected
[01:34:25] <jepler> yes
[01:34:38] <SWPadnos> I used mkinitrd. I wonder if that was a problem (though I did the same thing for the working and nonworking kernels)
[01:34:47] <cradek> hm, I think my following errors might be due to power supply sag
[01:35:10] <SWPadnos> you mean an actual hardware problem?
[01:35:13] <SWPadnos> cool
[01:35:27] <cradek> yeah
[01:35:36] <cradek> well, not sure I like it
[01:35:52] <SWPadnos> what's the supply voltage/current?
[01:35:58] <jepler> don't run your lathe while the AC is on, I guess..
[01:37:36] <cradek> my 25v supply sags to about 15+-3 at full load (one axis)
[01:37:57] <SWPadnos> hmmm
[01:38:08] <SWPadnos> what's the current rating?
[01:38:31] <cradek> the transformer is ... round
[01:38:38] <SWPadnos> so it's rated for current then? ;)
[01:38:48] <cradek> rated for some current, yes
[01:39:11] <SWPadnos> let's start from the other end then. what's the current rating of your motors? :)
[01:39:17] <skunkworks> yah - that could be a problem. :)
[01:39:52] <SWPadnos> (I only ask because it's possible I have a higher capacity transformer you could swap in at Fest)
[01:40:46] <cradek> the motors are ... cylindrical
[01:41:00] <cradek> I think the stall is something like 1.5A
[01:41:01] <SWPadnos> ok, now we're getting somewhere!
[01:41:07] <jtr> so in round numbers, then...
[01:41:13] <SWPadnos> 000
[01:41:29] <SWPadnos> 36890 are all round numbers
[01:41:39] <SWPadnos> depending on the font
[01:41:57] <cradek> drat, I can't find my notes about the transformer
[01:42:30] <SWPadnos> so if you had a 24V 5A supply, it would probably be enough?
[01:42:54] <cradek> you know, I'm measuring at the motor, I should measure at the supply
[01:43:02] <cradek> because maybe the motor wires are too small
[01:43:33] <SWPadnos> it seems unlikely that you could handle a wire that's tioo small for 1.5A
[01:43:39] <SWPadnos> without breaking it
[01:44:46] <cradek> they're pretty small.
[01:47:36] <cradek> http://timeguy.com/cradek-files/emc/dscn6313.jpg
[01:48:12] <SWPadnos> ah yes
[01:48:17] <cradek> this is two sweeps, the jaggy one is me twisting the motor off position
[01:48:19] <SWPadnos> what am I looking at? :)
[01:48:30] <cradek> the other two (straight) lines are the virtually unloaded pwm
[01:48:42] <cradek> 10v/div
[01:49:11] <SWPadnos> what's the sweep time?
[01:49:16] <cradek> 2ms/div
[01:49:45] <SWPadnos> ok, so the zigzag is due to PID, not you
[01:50:14] <cradek> no, the zigzag is 120Hz
[01:50:29] <SWPadnos> ah, ok
[01:50:46] <cradek> 4div = 8ms = 125Hz
[01:50:57] <SWPadnos> right - close enough
[01:51:55] <cradek> so it looks like about 12-17v
[01:51:58] <SWPadnos> that looks like an amazing amount of sag
[01:52:03] <cradek> I could add more caps, but that seems unlikely to help
[01:52:28] <skunkworks> I see 150ipm in your future ;)
[01:52:54] <cradek> yes this could explain why I seem to have a lot less headroom than before
[01:53:11] <cradek> I was using a very large switching supply
[01:54:02] <SWPadnos> what's the max voltage your drivers can take?
[01:54:09] <cradek> 40-45
[01:54:17] <cradek> the current limit is the problem really
[01:54:22] <SWPadnos> I have a 24VAC 500VA transformer that might help a little
[01:55:02] <cradek> let me measure it at the transformer just for good, uh, measure
[01:55:13] <SWPadnos> ok
[01:55:14] <cradek> (that's a lot harder of course)
[01:55:32] <SWPadnos> that transformer would give you ~33V at 8.18A or thereabouts
[01:55:56] <cradek> I bet it's big...
[01:56:10] <SWPadnos> not small enough to fit in that slim case of yours
[01:56:12] <cradek> I don't have much room left unfortunately
[01:56:18] <SWPadnos> but not too big
[01:58:06] <SWPadnos> 4.5" square, 3.75" high. the terminals stick out a little, making it more like 5.5 in one dimension
[02:02:05] <cradek> I see 17-23 in the box
[02:02:43] <cradek> I guess some would be lost in the H bridge, some in the wiring
[02:03:03] <cradek> 17 is pretty low - I could probably help that some with capacitance
[02:06:14] <cradek> http://timeguy.com/cradek-files/emc/dscn6314.jpg
[02:06:34] <cradek> same kind of pic - three traces, ground, unloaded, loaded by twisting the motor
[02:06:44] <cradek> this is right on the rectifiers
[02:08:05] <jtr> That looks funny to be on the rectifiers - normally the leading edge is steeper, isn't it?
[02:08:13] <jepler> is "ground" the top trace, or?
[02:08:18] <cradek> yes
[02:08:55] <jtr> ok, that explains the slope issue.
[02:08:56] <jepler> so it is steeper going away from GND
[02:09:57] <jtr> yep. brighter trace is GND.
[02:10:07] <cradek> yeah sorry for not explaining that
[02:10:58] <cradek> on the H bridge output I see about 13-20, so not much of the drop is in the wiring.
[02:11:39] <jtr> 's ok - I need to think from time to time.
[02:12:06] <jtr> How much cap do you have?
[02:12:34] <cradek> about 2200 uF
[02:13:32] <cradek> I have room for another one - I could add that easily enough
[02:13:36] <cradek> if I can find one
[02:15:09] <cradek> I do have one more that size, I'll add it
[02:15:20] <jtr> there was a rule of thumb about how many uF/amp - googling now.
[02:15:26] <cradek> but it's really not going to help much I don't think
[02:16:11] <jepler> units "1A 1|120s /2200 micro F" "V"
[02:16:12] <jepler> * 3.7878788
[02:16:51] <cradek> so it will raise the minimum at most a volt or two?
[02:17:30] <SWPadnos> yes, that sounds more or less right
[02:17:42] <SWPadnos> Mariss' formula is 80000*I/V uF
[02:18:12] <SWPadnos> though the "/V" part is so the ripple is some percentage of voltage, rather than some particular drop
[02:20:11] <cradek> sure sounds like I need a better transformer doesn't it
[02:21:09] <skunkworks> uh oh.
[02:21:40] <SWPadnos> hmmm
[02:23:18] <jepler> according to horowitz & hill, p-p ripple = IT/C when the load is constant-current (page 330)
[02:23:30] <SWPadnos> yep
[02:23:35] <SWPadnos> Q=C dV/dT
[02:23:54] <SWPadnos> argh
[02:23:56] <SWPadnos> Q=CV
[02:24:10] <SWPadnos> I=C dV/dT (derivative WRT time, C is constant)
[02:25:35] <jepler> so I guess I am interested in hearing what adding C does -- doubling it should halve the ripple
[02:25:40] <SWPadnos> exactly
[02:25:56] <SWPadnos> so 3.78/2 V difference (in theory)
[02:26:10] <SWPadnos> per amp
[02:26:10] <jepler> (if 1A is the right estimate of current)
[02:26:24] <SWPadnos> IT=2200 uF
[02:26:35] <cradek> with double the C, I get about 18-22V at the rectifiers
[02:26:55] <SWPadnos> T=8333 uS
[02:27:14] <SWPadnos> (or did I slip a decimal there?)
[02:27:38] <jepler> yes, 1/120 is 8333 micro
[02:27:44] <cradek> huh, that seemed to help a lot then
[02:27:45] <SWPadnos> ok, phew]
[02:27:58] <cradek> I said 13-20 before, now 18-22
[02:28:30] <cradek> let's see what it is at the motor now
[02:28:36] <cradek> (don't clip to ground, don't clip to ground)
[02:28:42] <SWPadnos> heh
[02:29:18] <SWPadnos> ripple looked like 15V, so ~15 = I * 0.008333 / 0.0022
[02:29:45] <SWPadnos> or ~4A
[02:29:50] <SWPadnos> hey - that may have worked!
[02:30:15] <jepler> I don't think so -- 4A is the limit of an L298 package, and I think that's with heavy heatsinking
[02:30:37] <jepler> I don't think cradek saw 15V ripple
[02:30:40] <SWPadnos> well, my eyechrometer may have read the ripple wrong
[02:30:42] <jepler> 21:27:56 <cradek> I said 13-20 before, now 18-22
[02:30:56] <cradek> 14-17 at the motor, no better really
[02:30:55] <jepler> so maybe 7V / 2A?
[02:31:06] <SWPadnos> could well eb
[02:31:06] <SWPadnos> be
[02:31:25] <SWPadnos> yeah - I guess it looks like ~8V or so
[02:31:35] <SWPadnos> the lines are pretty thick in that photo
[02:31:40] <jepler> won't the motor develop something less than the supply voltage across it, since the PWM duty cycle is limited to less than 100%?
[02:31:51] <cradek> I changed it to 100%
[02:31:53] <jepler> oh
[02:31:56] <jepler> forget it
[02:32:16] <SWPadnos> I'm not sure that would matter
[02:32:27] <cradek> SWPadnos: photo of an analog scope - be happy you get that much :-)
[02:32:47] <SWPadnos> heh - I note that it's a ...orage scope :)
[02:32:49] <jepler> I think SWPadnos will be giving away free digital scope to everyone
[02:33:04] <jepler> you mean "rageoscope"
[02:33:07] <SWPadnos> only if I win some lottery or something ;)
[02:33:08] <SWPadnos> heh
[02:33:09] <cradek> SWPadnos: :-P
[02:33:20] <skunkworks> * skunkworks is still here also
[02:33:22] <cradek> funny it doesn't seem orange here
[02:33:37] <jepler> cradek: your seeing meat performs image processing algorithms all the time
[02:33:46] <SWPadnos> jepler was right - it;'s a rageoscope
[02:34:16] <cradek> jepler: the camera is set for white balance for the flash - it must be very blue
[02:34:41] <jepler> I think you're right -- flashes are quite blue
[02:35:05] <jmkasunich> hi guys
[02:35:09] <cradek> haha those are terrible photos
[02:35:10] <cradek> hi jmk
[02:35:17] <SWPadnos> hi
[02:35:24] <skunkworks> cradek: I think we have the same scope.
[02:35:28] <jmkasunich> thats the transformer I sent you?
[02:35:29] <cradek> jmkasunich: I demand my money back for this transformer
[02:35:34] <cradek> double my money back even
[02:35:45] <jepler> and free return shipping!
[02:35:51] <jmkasunich> ok, that means you owe me twice the shipping cost
[02:36:06] <cradek> hmmmm
[02:36:28] <jmkasunich> so is your scope upside down, or just the camera?
[02:36:36] <jmkasunich> or did you biuld a postiive ground power supply?
[02:36:48] <cradek> brain is upside-down
[02:37:21] <jmkasunich> whats the volts per div in those pics?
[02:37:31] <cradek> I was using add/invert for measuring at the motor, so it ended up upside-down
[02:37:31] <cradek> 10
[02:37:41] <jtr> cradek: top left corner of the dsc6316.jpg is the model # and description - 66 rage oscope
[02:37:57] <cradek> jtr: ha
[02:38:04] <cradek> jtr: I couldn't figure out what he was talking about
[02:38:25] <jmkasunich> ok, so about 26V no load, 22-23 peak and 17 valley under load
[02:38:31] <jmkasunich> any idea what the load current is?
[02:38:48] <cradek> nope
[02:39:10] <jmkasunich> is this a full wave bridge, or center tapped? (I don't recall the xfmr details
[02:39:14] <cradek> jmkasunich: once it's through the H bridge, it's more like 13v
[02:39:20] <cradek> center tap
[02:39:37] <jmkasunich> divide and conquer - look a the supply first
[02:39:51] <cradek> yeah that's the 14 photo
[02:40:05] <jmkasunich> thats the one I'm lookin at
[02:40:31] <jmkasunich> the supply - center tap of xfmr grounded, two diodes from the ends pointing at the top of the cap?
[02:40:41] <cradek> yes
[02:40:49] <jmkasunich> you got two probes for that scope?
[02:40:52] <cradek> yes
[02:41:06] <jepler> L298 source saturation voltage = 2V typ @ 2A, sink saturation voltage = 1.7V typ @ 2A (
http://www.st.com/stonline/products/literature/ds/1773.pdf page 3)
[02:41:12] <jmkasunich> put one on one end of the xfmr, other one on the top of the cap
[02:41:20] <jmkasunich> (both grounds on circuit common of course)
[02:41:39] <jmkasunich> jepler: and they call that a power switch?
[02:41:42] <jmkasunich> pathetic
[02:42:12] <cradek> so you want the probes across one diode?
[02:42:25] <jmkasunich> I want two traces, one on each end of the diode
[02:42:29] <jmkasunich> (not difference mode)
[02:42:38] <cradek> ok
[02:43:03] <jepler> you want to see .. the conduction angle?
[02:43:21] <jmkasunich> among other things
[02:43:40] <jmkasunich> the side of the xfmr thats not conducting will be unloaded and have minimal droop
[02:44:03] <jmkasunich> if the side that is conducting flattops, it points at transformer impedance being high (wimpy xfmr)
[02:44:27] <jmkasunich> and the downslope during the non-conducting period tells us the current, assuming we know the total C
[02:45:16] <cradek> anything else while I have it set up?
[02:45:27] <SWPadnos> it looks like ~2A or thereabouts
[02:45:31] <jmkasunich> don't un-set up it until we look at the pic
[02:46:06] <jmkasunich> I thought I did a crude analysis of that transformer and concluded it was about 120VA
[02:46:20] <cradek> the pain is getting the photos... one sec
[02:46:21] <jmkasunich> so 24V at 2A shouldn't knock it down like that
[02:46:54] <jmkasunich> I wonder what the market for an A/D card for the 5i20 would be?
[02:47:14] <jtr> 'night guys - I'll have to get the rest from the logger.
[02:47:21] <SWPadnos> see you
[02:47:25] <jepler> night jtr
[02:47:29] <jmkasunich> night jtr
[02:47:35] <cradek> http://timeguy.com/cradek-files/emc/dscn6315.jpg
[02:47:52] <SWPadnos> mesa makes a few A/D cards, at least one of which has an FPGA on it as well (though fewer gates than the 5i20)
[02:47:55] <jmkasunich> ewwwww
[02:48:18] <cradek> pretty sure I had them both zeroed - but don't trust my scope's calibration
[02:48:33] <jmkasunich> I'm thinking more of an AD7886 - 1Msps 12 bit serial A/D in a 6 pin SOT-23 for something less than $5
[02:48:46] <jmkasunich> the flat-topping is just horrible
[02:49:03] <jmkasunich> damn, I thought that transformer had some balls
[02:49:31] <SWPadnos> so AI should bring my transformer then? :)
[02:49:50] <skunkworks> AI?
[02:49:50] <jmkasunich> and your enclosure enlarger
[02:49:54] <SWPadnos> -A
[02:49:57] <cradek> yeah that's the sad part
[02:50:04] <SWPadnos> I can rent a sawz-all
[02:50:12] <skunkworks> :) thought maybe you where going to send your robot
[02:50:14] <cradek> I have an air powered nibbler...
[02:50:18] <jmkasunich> the physical size of the transformer you already have doesn't match up with what we're seeing
[02:50:42] <jmkasunich> could it be that most of the xfmr's output was intended to come from the lower voltage winding?
[02:50:55] <cradek> I thought we calculated that this was the high power winding
[02:51:03] <jmkasunich> so did I
[02:51:19] <jmkasunich> but that either has a lot of DCR, or a lot of inductance, or both
[02:51:52] <cradek> sadly, my scribbled notes about the measurements are gone
[02:52:55] <jmkasunich> thats a real bummer
[02:52:59] <cradek> probably they're on google somewhere
[02:53:03] <jmkasunich> (the xfmr, not the notes)
[02:53:35] <cradek> could it be damaged? shorted turn?
[02:53:44] <SWPadnos> that would reduce V
[02:53:47] <jmkasunich> when unloaded, is the transformer signal a nice sine wave, or is it still kinda flat on top?
[02:54:12] <cradek> still not very siney
[02:54:45] <jmkasunich> are you using the other winding for anything?
[02:54:45] <cradek> it has corners, like a V with the point flattened
[02:54:48] <cradek> no
[02:54:57] <jmkasunich> can you scope it - is it siney?
[02:55:53] <jmkasunich> if a completely unloaded winding is distorted, either you have distorted input power (not bloody likely) or the transfomer core is being pushed close to saturation
[02:56:41] <skunkworks> Have fun guys. Night
[02:56:47] <jmkasunich> goodnight
[02:56:59] <jmkasunich> jepler: # this is a hack until I find out how we're really supposed to do it
[02:56:59] <jmkasunich> sys.path.append("../../../../../lib/python")
[02:57:22] <cradek> the unloaded one is just as bad
[02:57:35] <jmkasunich> I want to run the py file from the directory it is in - src/hal/drivers/mesa_5i2x/firmware
[02:57:53] <jmkasunich> whatever magic is being done to let py import from lib/python doesn't seem to work there
[02:57:56] <jepler> jmkasunich: during the build process, you mean?
[02:58:25] <jmkasunich> when I'm building a new fpga config
[02:58:39] <jepler> from "make"?
[02:58:41] <jmkasunich> cradek: so it looks kinda like the bottom half of the one you posted
[02:58:50] <cradek> yes
[02:58:51] <jepler> or manually?
[02:58:49] <jmkasunich> jepler: from the make in the firmware directory
[02:59:04] <jmkasunich> but right now I'm running it manually from within that directory
[02:59:44] <cradek> hey this has a setting for 100V mains - maybe I should switch it to that
[03:00:05] <jmkasunich> might be interesting
[03:00:16] <cradek> at least I think I remember seeing that
[03:00:19] <jmkasunich> the distortion might get even worse, but if it does, thats a data point
[03:00:29] <cradek> it would not be pretty, but it might be enough to cut parts
[03:00:28] <jepler> jmkasunich: for 'make', we should make sure a PYTHONPATH environment setting like the one created by emc-environment exists
[03:00:47] <jepler> jmkasunich: for running manually, you should ". scripts/emc-environment" assuming you are doing a RIP build
[03:00:54] <jmkasunich> ok, thats what python reads to set sys.path?
[03:00:56] <jepler> jmkasunich: yes
[03:01:22] <jepler> jmkasunich: it's not complicated, except that emc-environment accomodates the case where PYTHONPATH already has a value and the case where it doesn't
[03:01:33] <jepler> (usually Python works just fine without a PYTHONPATH set)
[03:01:40] <jepler> (as long as everything is installed in the correct location)
[03:02:00] <jmkasunich> I think this only has to worry about RIP mode
[03:02:08] <jmkasunich> because I'm not really "running" emc at all
[03:02:08] <cradek> heh, I'm scared of these caps even though they're harmless at 24V, I'm used to working with 450V caps
[03:02:27] <jmkasunich> cradek: I didn't know you were a drives guy?
[03:02:33] <cradek> jmkasunich: radios
[03:02:34] <jmkasunich> or is it tubes
[03:04:05] <jmkasunich> how about 45,900uF charged to 650V?
[03:04:51] <cradek> I'll be in the next room, thanks
[03:05:54] <SWPadnos> wimpy
[03:06:23] <SWPadnos> how about ~100000 uF charged to 1300V? :)
[03:06:29] <cradek> 30V unloaded now
[03:06:56] <jmkasunich> SWPadnos: I'll be in the next state, thanks
[03:07:01] <jepler> jmkasunich: I guess the change I just checked in won't help you, since you're not running the top-level make
[03:07:03] <jmkasunich> jepler: thanks
[03:07:04] <SWPadnos> hegh
[03:07:40] <cradek> 22-26 at the bridge now
[03:07:45] <cradek> that might just make the difference I need
[03:07:48] <jmkasunich> jepler: well, eventually I'll figure out the right thing and put it in the fpga makefule
[03:08:05] <jepler> jmkasunich: it will be some variant of "set PYTHONPATH", I can tell you that much
[03:08:04] <jmkasunich> that will be the only thing that invokes these two py programs
[03:08:09] <jmkasunich> right
[03:08:15] <jepler> since you know the relationship between that dir and the lib/python location, you can code whatever you need
[03:08:42] <jmkasunich> thats not the only path fixes I need - the xilinx tools have a script that you need to source to set up their env vars too
[03:08:49] <jepler> oh
[03:08:55] <jepler> then maybe "use emc-environment" is good enough
[03:09:12] <jepler> good night all
[03:09:17] <jmkasunich> goodnight
[03:09:37] <cradek> cool, that keeps it around 20V at the motor
[03:09:50] <jmkasunich> cradek: keep an eye on the transformer, make sure it doesn't heat up at that setting
[03:10:04] <jmkasunich> if you're pushing the rated voltage, core loss will go up
[03:10:20] <cradek> ok, not warm yet
[03:10:31] <jmkasunich> it will be a slow process
[03:10:36] <jmkasunich> just don't ignore it for a couple hours
[03:10:43] <jmkasunich> or go to sleep with it powered up
[03:10:56] <cradek> ok I'll run some programs for a while
[03:11:01] <jmkasunich> (at least until you know how warm it does/doesn't get)
[03:15:24] <SWPadnos> hmm. I guess it's time for bed. night guys
[03:15:30] <jmkasunich> goodnight
[03:15:39] <cradek> halscope is so very cool
[03:15:58] <cradek> watching pid output and FE in roll mode...
[03:18:11] <jmkasunich> ;-)
[03:18:16] <jmkasunich> hypnotic?
[03:20:11] <jmkasunich> its a curse I tell you
[03:20:33] <jmkasunich> the compile farm ALWAYS decides its time for a full build while I'm hare
[03:20:51] <jmkasunich> can it do it during the day when I'm at work? nooooooo
[03:21:03] <jmkasunich> can it do it 2 hours ago while I was out? nooooooo
[03:21:41] <jmkasunich> have I gotten off my ass and moved the farm to the new machine yet? nooooooo
[03:24:30] <jmkasunich> cradek: what the heck is this bug report for halscope?
[03:24:44] <jmkasunich> you want grayed out menu items?
[03:24:51] <jmkasunich> do I look like a GUI programmer or something?
[03:27:15] <cradek> haha
[03:27:21] <cradek> (notice I didn't assign it like I usually do)
[03:37:47] <cradek> hey my program runs now
[03:38:05] <cradek> barely - I can see pid occasionally saturating
[03:52:36] <cradek> jmkasunich: no detectable warmth in an hour or so
[03:54:20] <jmkasunich> good
[17:12:22] <Unit41> why am I having so many problems understanding emc as a whole...
[17:13:24] <SWPadnos> hmmm. it might be because you don't get it. :)
[17:13:47] <SWPadnos> there are a lot of parts, and the connections between them are not obvious at first
[17:14:28] <Unit41> the code deffinatly looks worth learning
[17:14:44] <SWPadnos> oh, the code will take lots longer to understand
[17:15:27] <Unit41> I think lack of good IDE is my problem
[17:15:56] <SWPadnos> hmmm. ther eare some who would say that dependence on an IDE is the root problem there ;)
[17:17:09] <Unit41> im just using pad
[17:17:26] <SWPadnos> pad? programmer's notepad?
[17:17:26] <Unit41> gedit to be exact
[17:17:30] <SWPadnos> ah
[17:17:58] <SWPadnos> gedit or kate (as long as you remember not to trigger the crash that occurs when you try to compare the buffer to a changed file on disk)
[17:18:19] <Unit41> lol
[17:18:26] <SWPadnos> I like kate a bit better becaus eit has the nice file list, plus an integrated terminal that tracks what directory the active file is from
[17:18:38] <SWPadnos> and I can usually remember not to diff ;)
[17:20:50] <SWPadnos> yay! time to wire up this Yaskawa motor and controller. bbl
[17:21:21] <Unit41> has anyone seen MFD cut rack and pinion
[17:21:27] <Unit41> that wood
[17:21:38] <SWPadnos> MDF?
[17:21:41] <Unit41> ya
[17:21:46] <SWPadnos> not me
[17:23:26] <Unit41> would be neat to see a sample cut out
[17:23:30] <Unit41> make the pinion like a flower
[17:26:06] <Unit41> use a little bit of fantastic plastic to stick the pinion on
[17:34:44] <Unit41> does anyone here use an IDE ?
[17:36:29] <Unit41> Im allmost ready to give code::blocks a chance on linux
[17:41:40] <Unit41> I'll try to import it into Kdevelop
[17:44:28] <Unit41> much better
[17:57:23] <jepler> Unit41: personally I'm a die-hard vim user, but I try not to evangelize it too much
[17:59:35] <cradek> we use both kinds of development environments here: vi and emacs
[18:01:48] <jepler> I have never used a Visual Studio-type IDE, but my editor allows me to easily go to the definition of a function, macro or variable through "tags", to go to sites where an identifier is used through "swish" full-text search, and to execute the build process and easily visit lines where the compiler had errors or warnings.
[18:15:33] <Unit41> I like being able to see what functions are where and a nice easy list to click on to open source files
[18:15:44] <Unit41> its handy
[18:16:30] <Unit41> specially for foreign code
[18:16:58] <Unit41> alien more like
[18:17:05] <Unit41> huhu
[18:39:43] <cradek> I'm pondering another interp change.
[18:39:48] <jepler> uh oh
[18:39:50] <jepler> what's that?
[18:40:10] <cradek> if tool offsets (G43) are in effect when you change tools, you get the new offsets automatically
[18:40:24] <cradek> if G43 is in effect and you unload the tools (T0) they cancel (like G49)
[18:40:33] <jepler> what if a tool offset from G43.1 is active?
[18:40:36] <cradek> unload the tool
[18:40:57] <cradek> jepler: as I have it written, it would be replaced with the one from the tool table
[18:41:06] <cradek> it could do anything else of course
[18:41:19] <cradek> (right now we don't keep track of G43 vs G43.1 in effect
[18:41:22] <cradek> )
[18:44:02] <jepler> is G49 about the same as G43.1 I0 K0 ?
[18:45:07] <cradek> yes
[18:45:57] <cradek> in fact that changes to G49 in "active g codes"
[18:49:08] <alex_joni> hi
[18:49:16] <cradek> hi alex
[18:49:24] <alex_joni> hey chris
[18:49:44] <cradek> this would change the meaning of some legal (but probably buggy/wrong) ngc programs
[18:50:02] <cradek> currently you can change tools with g43 active, and the offsets don't change
[18:55:09] <cradek> jepler: strange, you and petev think the g43 part of the spec says lengths should be positive; I think it says indexes should be positive
[18:55:21] <cradek> (it certainly isn't clear though)
[18:56:27] <jepler> a negative index is dumb
[18:56:41] <jepler> let me read it again...
[18:56:42] <cradek> (and illegal)
[18:57:57] <cradek> it *does* say that after M6, "no other changes will be made"
[18:58:27] <jepler> "It is expected that all entries in this table will be positive."
[18:58:36] <cradek> (I've noticed you can change tools while in radius comp mode too)
[18:59:03] <jepler> this had to mean "length", because it's established separately that the indexes must be nonnegative
[18:59:09] <cradek> jepler: well it CAN'T mean that, since the spec talks about negative diameters
[18:59:45] <cradek> hmmmm
[19:00:36] <cradek> ok I think you're right
[19:08:33] <jepler> I think that what they anticipated is that you would make a length of 0 be the spindle with no tool inserted .. there is *some* length that is shorter than all tools you can possibly use
[19:09:12] <jepler> this is not true on lathes, though
[19:09:23] <cradek> right (I agree with both statements)
[19:10:29] <jepler> but I'm not sure why my line of reasoning doesn't also apply to tool diameter
[19:10:34] <jepler> it seems like there is *some* diameter that is smaller than all possible tools
[19:10:48] <cradek> sure, it's 0
[19:11:06] <cradek> but, negative diameters have a special meaning in ngc
[19:11:06] <jepler> indeed, that was my guess
[19:11:20] <jepler> yeah, they mean "whoops, I actually meant the Other Left"
[19:11:30] <alex_joni> lol
[19:11:31] <cradek> this doesn't really matter, I shouldn't have brought it up
[19:12:12] <jepler> perhaps "negative tool lengths are permitted" bears mentioning in the Differences section, and at least the "expected to be positive" text should be removed from the G43 specification
[19:12:20] <jepler> so it does matter and I'm glad you brought it up
[19:13:12] <cradek> someone who knows about canned cycles should try switching units between them - I bet it's the last thing that's still broken
[19:13:55] <jepler> yeah, the sticky "retract height" is probably in undefined units
[19:14:08] <cradek> and the repeat distance
[19:14:17] <jepler> yuck
[19:14:20] <cradek> maybe other things are sticky
[19:14:46] <cradek> wait, are repeat distances sticky?
[19:14:53] <cradek> (I've never used those)
[19:15:18] <jepler> I don't know, I've never used them either
[19:15:23] <jepler> I bet the documentation says
[19:15:40] <cradek> s/someone who knows/someone who cares/
[19:52:22] <cradek> jepler: all M are executed before the G, so Tx M6 G43 will give the expected thing
[19:58:04] <cradek> I was trying to remember something related to this that bit ray a while back - I think it was G21 G1 X10 F600
[20:13:20] <jepler> huh, how lucky for everyone who wants to divide by 12 that the segment called "c" is on for all digits but "2".
[20:16:46] <jepler> (though I'm still not sure I understand the full trick -- it's only alluded to by this "4026" datasheet)
[22:35:09] <rob-h> hello
[22:35:50] <skunkworks> Hi
[22:36:32] <a-l-p-h-a> Bonjour
[22:36:36] <a-l-p-h-a> et, bonjourno!
[22:36:59] <rob-h> was just wundering if any one in here could give us a quick hand on an EMC setup prob im having?
[22:37:41] <skunkworks> Actually - this might be better on #emc channel
[22:37:50] <skunkworks> /join #emc
[22:38:24] <rob-h> ok sure
[22:56:35] <jepler> whee, I think I just finished integrating all the 64 bit rtai patches into TRUNK
[22:56:49] <jepler> I'll come back later to check on the farm output :-P
[23:03:59] <cradek> jepler: the build is broekn for me
[23:04:25] <cradek> /usr/src/linux-headers-2.6.17-rtai3.5/include/asm-generic/bitops/fls64.h:10: error: 'fls' was not declared in this scope
[23:18:32] <cradek> jepler:
http://timeguy.com/cradek-files/emc/typescript
[23:39:38] <jepler> cradek: thanks for letting me know
[23:39:54] <cradek> fwiw sim+ppc does build
[23:40:53] <jepler> can you pastebin me your fls64.h?
[23:42:00] <cradek> http://pastebin.ca/526790
[23:43:13] <jepler> I assume you have $ASM_BITOPS_H_USABLE from configure?
[23:43:18] <jepler> try forcing it to 'no'
[23:43:42] <cradek> BITOPS_DEFINE = -DASM_BITOPS_H_USABLE
[23:43:57] <jepler> yeah that
[23:45:20] <cradek> looks fine without that so far
[23:48:37] <cradek> ah crap I forgot to cvs up first
[23:50:47] <jepler> forgot to cvs up? I assume you were trying this with the latest trunk..
[23:51:03] <cradek> yes I had done -D"hour ago"
[23:51:08] <jepler> oh
[23:51:10] <cradek> trying again now
[23:51:13] <jepler> that had made it work OK?
[23:52:19] <jepler> oh duh
[23:52:22] <jepler> of course it did
[23:53:18] <cradek> yes it builds with that change
[23:53:52] <jepler> I wonder if anything *doesn't* build with -UASM_BITOPS_H_USABLE
[23:54:53] <jepler> I think that all x86, x86-64, and ppc would work with -UASM_BITOPS_H_USABLE and that's approximately the whole world
