Back
[00:02:11] <alex_joni> jmkasunich: remember I talked in here about a german user with a puma-typed robot?
[00:02:17] <alex_joni> a couple months ago
[00:02:22] <jmkasunich> yeah
[00:02:34] <alex_joni> it seems he finally got it to work as it should
[00:02:43] <alex_joni> jogging in joint and world view works ok
[00:02:44] <alex_joni> kins ok, etc
[00:03:07] <alex_joni> joypad for jogging
[00:03:12] <jmkasunich> nice
[00:03:26] <alex_joni> yup..
[00:05:12] <LawrenceG> jmkasunich: I am back
[00:06:38] <LawrenceG> jmkasunich: yea... 3 phase sounds interesting
[00:09:15] <jmkasunich> I'm not entirely sure a .comp file is the way to go
[00:09:37] <jmkasunich> like stepgen and pwmgen, this component will require more than one function, a fast one and a slow one
[00:09:52] <jmkasunich> I think comp can do that, but I'd have to read up
[00:10:22] <jmkasunich> the single/three phase variations would also have to export different pins for the different modes
[00:10:43] <jmkasunich> I would not try to do this as an addition to pwmgen
[00:10:43] <LawrenceG> looking at pwmgen, I thought it would be a good starting point....
[00:11:01] <jmkasunich> copy pwmgen, gut it, and use it as a foundation, yes
[00:11:08] <jmkasunich> for some value of "gut"
[00:11:56] <LawrenceG> I was thinking that it could use the sync pulses to define the period of the output....
[00:12:24] <LawrenceG> then its just a percentage of the number if pulses for on/off
[00:12:48] <LawrenceG> the rate of the fast fucntion call would determine the resolution
[00:13:10] <LawrenceG> no sync pulses, no output
[00:13:33] <jmkasunich> I'm not sure I follow
[00:13:48] <jmkasunich> I think pwmgen's core algorithm isn't appropriate for this tho
[00:14:13] <jmkasunich> phase control is more like a bunch of one-shots
[00:14:21] <LawrenceG> for 120hz sync, there is 8.3ms between sync pulses... that will be some number of fast fuction calls
[00:14:22] <jmkasunich> sync pulse comes in - start timer A
[00:14:35] <jmkasunich> timer A runs for 0 to 180 degrees, based on the control signal
[00:14:52] <jmkasunich> when timer A times out, start timer B and turn on the output pin
[00:15:02] <LawrenceG> I think it will need 2 stages of delay
[00:15:04] <jmkasunich> timer B runs for a constant (programmable) time
[00:15:13] <jmkasunich> 180 deg for single phase, 60 deg for three phase
[00:15:20] <jmkasunich> when B times out, turn off the output
[00:15:28] <LawrenceG> one to align sync input with the actual zero crossing at triacs
[00:15:48] <LawrenceG> then a holdof before firing gate
[00:15:51] <jmkasunich> yeah, that would be an additional offset added to timer A
[00:17:16] <LawrenceG> with 8.33ms period and a 20us fast call, there are about 417 counts/cycle
[00:17:35] <LawrenceG> that should be plenty for phase control
[00:17:56] <jmkasunich> yep
[00:20:20] <LawrenceG> how much have you worked with SSR's.... I am thinking of using one of the hockey pucks as an isolated triac, but I am not sure if they have extra logic inside the ssr whhich might prevent pwm control
[00:21:05] <LawrenceG> they work fine for on/off, but they may have significant gate filtering
[00:22:42] <jmkasunich> I haven't used SSRs much
[00:23:09] <jmkasunich> I used to do a lot with hockey pucks - before my current job (AC drives) I worked on DC ones
[00:23:33] <jmkasunich> your hockey pucks are SCRs, not triacs, right?
[00:24:09] <LawrenceG> all my hockey puck experience was from before the time PLC's came popular for sequence control
[00:25:03] <LawrenceG> I think it is a triac.... when one I get full output.... not 1/2 wave rectified a/c... could be back to back scrs
[00:25:14] <LawrenceG> when on...
[00:25:19] <jmkasunich> ok
[00:25:37] <jmkasunich> I'm not used to seeing triacs except at low current ratings - 10, 20 amps
[00:27:25] <LawrenceG> I am just soldering together a zero crossing detector so I have an input to the pc to work with
[00:27:41] <jmkasunich> optical isolation would be a good idea there ;-)
[00:27:51] <LawrenceG> most defineately!
[00:29:00] <LawrenceG> I am going to try a capacitivly coupled bridge recifier driving an optocoupler
[00:29:38] <jmkasunich> to avoid a resistor that would get hot?
[00:30:15] <jmkasunich> actually, why the bridge rectifier?
[00:30:37] <LawrenceG> yea... the other though was to use a cheap ac wall wort as a signal source... then it could just drive a transistor into the PP
[00:30:48] <jmkasunich> opto with a diode connected the opposite way across the LED (to avoid high reverse voltage, LEDs don't like that)
[00:31:04] <LawrenceG> I want an input at each crossing 120hz
[00:31:09] <jmkasunich> why?
[00:31:23] <jmkasunich> go for a 50% duty cycle square wave at 60Hz
[00:31:47] <jmkasunich> and use both edges as your timing reference
[00:32:22] <jmkasunich> for a triac it may not matter which edge you use (or you might want both) but for the general case where you have SCRs, you want to know which half-cycle you are on
[00:34:48] <LawrenceG> I was thinking a short pulse at each zero crossing, but a square wave could still provide timing....
[00:35:08] <jmkasunich> thats the way most DC drives do it
[00:35:34] <LawrenceG> there might be significant timing variation when relying on risingand falling edges
[00:35:57] <LawrenceG> need to build some samples and look at them with the scope
[00:36:29] <jmkasunich> to be honest, most drives use two stages - first stage locks a PLL to the timing reference signal, which might be a single edge, or both edges
[00:36:39] <jmkasunich> 2nd stage uses the PLL output to generate the gate pulses
[00:36:59] <jmkasunich> if you get some noise or such on the reference, the PLL filters it
[00:37:27] <jmkasunich> without the PLL you risk strange behavior from line notching and other interference
[00:38:00] <LawrenceG> not too hard to filter the sync input in software
[00:38:09] <jmkasunich> a very crude non-PLL form of filtering would be to ignore any edge that isn't 360 +/-10 degrees from the last one
[00:39:22] <LawrenceG> with the bridge and opto, there is some glitch filtering in hardware for short pulse
[00:40:20] <jmkasunich> this is an interesting project - I think as soon as I finish up the stepgen work I'm doing at the moment I'll start the phase control component
[00:41:17] <tfmacz> LawrenceG: Hi there
[00:48:51] <LawrenceG> tfmacz: Hi Ted... jmkasunich is the hal guru... been takijng over ideas for spindle controller
[00:50:02] <tfmacz> I have been looking back at the conversation, interesting...
[00:50:31] <LawrenceG> jmkasunich: cool.... I will continue on hardware ideas and we can try them out as the software developes
[00:50:49] <jmkasunich> ok
[00:51:12] <jmkasunich> I think I just finished the stepgen code changes - need to test, and write documentation
[00:52:36] <jmkasunich> thats scary - compiled with no errors or warnings
[00:52:37] <tfmacz> LawrenceG: did you figure out how to create the .pyc for the changes chris made last night?
[00:53:11] <tfmacz> lsor do I have to wait for it to hit a release???
[00:53:42] <tfmacz> LawrenceG: or do I have to wait for it to hit a release???
[00:54:17] <jepler> tfmacz: you can remove the .pyc and put the updated .py in its place
[00:54:28] <jepler> I hope the next 2.1 release will be soon though
[00:54:35] <jepler> so you guys have actually used image-to-gcode?
[00:54:36] <LawrenceG> my suggestion would be to checkout a cvs download... build for run in place and then move the 2 new files into your existing installed system
[00:55:03] <jepler> if so you're the first in the world for all I know -- I wrote it and I've still never milled anything with it :-P
[00:55:19] <LawrenceG> cool....
[00:56:10] <tfmacz> jepler: put the image-to-gcode.py file where and the author.py in the RS274 directory???
[00:57:11] <jepler> tfmacz: the normal installation process puts image-to-gcode.py in /usr/bin/image-to-gcode (no extension) and makes it executable (chmod +x filename)
[00:57:20] <jepler> author.py goes in /usr/lib/python2.4/site-packages/rs274/ or something like that
[00:58:10] <jepler> remove author.pyc
[00:58:31] <jepler> hmmmm - that risks messing things up when you upgrade to 2.1.3
[00:58:43] <jepler> this really is not a good idea
[00:58:46] <tfmacz> jepler: OK, I was not sure how that would work...
[01:00:28] <tfmacz> jepler: the upgrade would over-write the updated .py file???
[01:00:55] <tfmacz> jepler: just have to make notes and do it again then...
[01:01:02] <jepler> tfmacz: no, it would leave the .py file there
[01:01:15] <jepler> tfmacz: I think that when Python finds both a .py and a .pyc file, and they don't match, it takes the .py file
[01:01:49] <jepler> tfmacz: so when you upgrade to later versions you'll still get that version of 'author' that you copied yourself, not an updated version with any bugfixes..
[01:02:44] <tfmacz> jepler: ok so need to remove the .py file after the upgrade?
[01:03:14] <jepler> tfmacz: yes if you remember to remove the .py all should be OK after the upgrade
[01:03:24] <jepler> I still recommend not doing it in the first place though
[01:03:48] <tfmacz> jepler: the new code will be in which release???
[01:04:10] <tfmacz> jepler: OK, I can live with that...
[01:04:58] <jepler> tfmacz: it will be in 2.1.3 which I hope will be released soon
[01:05:07] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/emc/emc2_2.1.3~alpha0_i386.deb http://emergent.unpy.net/index.cgi-files/sandbox/emc/emc2_2.1.3~alpha0.tar.gz
[01:05:11] <cradek> probably late tonight or tomorrow
[01:05:20] <jepler> actually I've just prepared a package that you could download and install if you really must try it now :)
[01:05:34] <jepler> (it's a slow download though since it's just on my dsl)
[01:06:05] <tfmacz> jepler: I can live with slow...
[01:06:25] <jepler> if you install this package, everything will go OK when you upgrade to the official, final 2.1.3 later
[01:06:34] <tfmacz> or just wait for Chris..
[01:06:41] <alex_joni> * alex_joni remembers that he needs sleep
[01:06:41] <jepler> true
[01:06:46] <jepler> alex_joni: sleep!
[01:06:49] <alex_joni> good night all
[01:06:54] <cradek> goodnight alex
[01:06:55] <jmkasunich> goodnight alex
[01:06:55] <LawrenceG> did the tool profile updates get back ported into the 2.1.x for image-to-gcode?
[01:07:02] <jepler> LawrenceG: yes that is in there too
[01:07:11] <LawrenceG> excellent
[01:07:20] <jepler> changes listed here:
http://emergent.unpy.net/index.cgi-files/sandbox/emc/emc2_2.1.3~alpha0_i386.changes
[01:07:56] <alex_joni> I don's see the 'nice' change in there..
[01:08:21] <jepler> alex_joni: cradek didn't list all his changes in debian/changelog either
[01:08:21] <jepler> tsk tsk
[01:08:33] <LawrenceG> tfmacz: are you home for the night?
[01:08:49] <jmkasunich> I bet the stepgen changes aren't listed either
[01:08:57] <tfmacz> LawrenceG: No, Heading to the firehall for our banquet
[01:09:28] <tfmacz> LawrenceG: in fact I am getting the evil eye so better go get ready..
[01:09:39] <LawrenceG> tfmacz: have fun
[01:09:50] <jepler> jmkasunich: in the backport, the meaning of the steplen and stepspace pins -- is it the same?
[01:09:55] <jepler> the same as before, I mean
[01:09:58] <jmkasunich> yes
[01:10:09] <jmkasunich> I'm gonna update the changelog
[01:10:25] <jmkasunich> as soon as I check cvs and make sure I know what was actually backported
[01:13:48] <jepler> it's a pity that the branch name doesn't show in the emc-commit subject line
[01:19:47] <jmkasunich> oops - just found a bug in stepgen, branch and head
[01:22:15] <jepler> doh!
[01:22:31] <jmkasunich> fix coming soon
[01:23:18] <jmkasunich> was that a "I see your bug too" doh?
[01:23:26] <jepler> no I haven't looked at it
[01:23:32] <jmkasunich> ok
[01:23:34] <jepler> I wish I could get 'cvs log' to do what I want
[01:23:44] <jmkasunich> it is a "doh" kind of bug.....
[01:24:06] <jepler> why does 'cvs log -rRELEASE_2_1_2::' show information about revisions from the trunk?
[01:30:16] <jmkasunich> hmm, cvs server is slow again
[01:41:13] <jmkasunich> jepler: are you doing anything that might be loading up the CVS server?
[01:43:25] <jepler> jmkasunich: no
[01:43:57] <jmkasunich> odd
[01:44:16] <cradek> it works fine from here
[01:44:34] <jmkasunich> for about 20 minutes, it was slow enough that the compile farm checkouts were timing out (2 minute timeout)
[01:44:48] <cradek> 15s for a full cvs up
[01:45:40] <jmkasunich> I guess if all four slots were trying to do it at the same time my DSL might have been a bottleneck
[01:48:24] <jmkasunich> jepler: thanks! I was thinking "boy it would be nice if the compiler could detect that error like it does for printf"
[01:48:33] <jmkasunich> but had no clue how to make it happen
[01:48:52] <jepler> jmkasunich: you're welcome
[01:49:06] <jepler> you can blame me for adding _newf in the first place, without adding the __attribute__ turd to get the warning
[01:51:15] <jmkasunich> I wish there was a "rmmod -f --I-really-mean-it-remove-the-damn-thing"
[01:51:55] <jepler> hah
[01:52:18] <jepler> that's one thing that's nice about the simulator -- a little "kill -9" and "ipcrm" and all is well in the world again
[01:55:12] <jmkasunich> I may have to reboot to get rid of it....
[01:55:15] <jmkasunich> annoying
[02:39:28] <jmkasunich> note to self - don't write a value to a hal pin unless you have exported the pin ;-)
[02:42:29] <jepler> hi again jmk
[02:42:36] <jmkasunich> hi
[02:43:00] <jmkasunich> I figured out the problem the 2nd time I loaded the module and it crashed
[02:43:02] <jmkasunich> so I got to reboot twice
[02:43:04] <jmkasunich> annoying
[02:43:52] <cradek> [ 1206.742421] 391114, 394388, 392864, 391890, and 393924
[02:43:52] <cradek> [ 1206.742442] elapseThis time, there were 80022086 which is so anomalously
[02:43:57] <cradek> ouch
[02:44:11] <jmkasunich> 80 milliseconds?
[02:44:16] <cradek> yep
[02:44:24] <cradek> (aside from the message being all screwed up)
[02:44:36] <jmkasunich> what system is that on?
[02:45:00] <cradek> my new PII
[02:45:13] <cradek> that I've cut many parts with reliably...
[02:45:18] <cradek> wonder what happened.
[02:45:24] <jmkasunich> did you do anything?
[02:45:28] <jmkasunich> plugging USB or such?
[02:45:31] <cradek> I added ram earlier
[02:45:36] <cradek> nope nothing like that
[02:46:20] <cradek> (no usb)
[02:46:32] <jepler> if it's a 400MHz machine, that's more like 200ms
[02:46:34] <jepler> ouch
[02:46:49] <cradek> yeah, it was real too - I heard it
[02:47:12] <jmkasunich> where did the new memory come from?
[02:47:22] <cradek> junkbox
[02:47:24] <jmkasunich> * jmkasunich speculates wildly
[02:47:52] <jmkasunich> ecc recovery times are probably nanoseconds, not milliseconds
[02:50:12] <cradek> find /, glxgears, etc don't mess it up
[02:58:10] <cradek> jepler: can you try to fix that realtime delay message?
[02:58:59] <jepler> cradek: I'll see what I can do
[02:59:14] <jepler> * jepler boots ubuntu in a vm
[02:59:18] <cradek> thanks
[02:59:24] <jepler> I thought I had it right :(
[02:59:30] <cradek> me too
[03:10:58] <jepler> looks like it missed being backported
[03:11:04] <jepler> haven't actually built it yet though
[03:11:06] <cradek> strange - I got only the 2.1 message
[03:11:26] <cradek> oh I get it
[03:11:38] <cradek> thank you
[03:11:50] <jepler> what, for forgetting to backport it months ago?
[03:12:15] <cradek> no, for fixing it
[03:12:26] <cradek> I'll try to test it (somehow)
[03:12:47] <jepler> I think the same problem would show up with the step rate message
[03:12:58] <cradek> ok that's easy to try
[03:17:15] <jepler> argh I built without --enable-run-in-place
[03:20:56] <jepler> looks good to me -- I'm heading to bed
[03:20:59] <jepler> goodnight
[03:21:10] <jmkasunich> goodnight
[03:21:48] <jmkasunich> cradek: busy?
[03:22:03] <jmkasunich> (I imagine so - pulling out hair trying to figure out latency)
[03:22:03] <cradek> yes and no, what's up?
[03:22:23] <jmkasunich> I've almost done with the changes that let stepgen replace freqgen
[03:22:31] <cradek> on that I'm just running memtest for a while
[03:22:42] <jmkasunich> I'm 99.9999% sure they don't break normal stepgen operation (all I did was put some code in an if)
[03:22:54] <jmkasunich> was wondering if once I commit you can run it on max
[03:23:02] <cradek> sure, check 'er in, I'll try it
[03:23:06] <jmkasunich> I don't have steppers set up, I have to test using scope, etc
[03:23:23] <jmkasunich> I want to test the freqgen mode first, but I'll commit in an hour or so
[03:23:31] <jmkasunich> feel free to defer the testing till tomorrow
[03:24:25] <cradek> ok
[03:54:28] <cradek> [ 734.434514] Uhhuh. NMI received. Dazed and confused, but trying to continue
[03:54:32] <cradek> [ 734.446802] You probably have a hardware problem with your RAM chips
[03:54:32] <cradek> haha
[03:55:05] <jmkasunich> nice message
[03:55:23] <jmkasunich> I can see how an NMI could cause latency problems
[04:03:37] <jmkasunich> those rams are now in the trash can?
[04:19:09] <steve_stallings> steve_stallings is now known as steves_logging
[04:19:10] <cradek> I took one of the new ones out
[04:19:23] <cradek> well I hope it was one of the new ones - I didn't keep careful track unfortunately
[04:19:37] <jmkasunich> bummer
[04:22:19] <jmkasunich> well, my kernel log is getting long
[04:22:37] <jmkasunich> code was crashing, so I put a print in the RT function
[04:22:49] <jmkasunich> then I fixed the bug, so it no longer crashes the first time it runs
[04:23:00] <jmkasunich> printing 5 lines to the log every 1mS.....
[04:23:08] <jmkasunich> for the last 10 minutes
[04:24:20] <cradek> do you need hardware output? if not, you could build for sim
[04:24:29] <cradek> so much nicer for debugging
[04:25:48] <jmkasunich> sometimes I do, sometimes I don't
[04:26:02] <jmkasunich> too much trouble to keep switching the entire tree around
[04:26:11] <jmkasunich> (you have to do a clean if you switch)
[04:32:39] <jmkasunich> damn - I keep finding bugs in the new stepgen
[04:32:55] <jmkasunich> step type 1 was busted since I committed it earlier in the week
[04:47:22] <cradek> yay, figured it out (maybe)
[04:47:36] <jmkasunich> figured out the bad memory stick?
[04:47:42] <cradek> yes
[04:47:56] <jmkasunich> good - I just committed the stepgen change - get busy testing
[04:48:06] <jmkasunich> or sleeping, your choice ;-)
[04:48:08] <cradek> ok
[04:48:21] <cradek> I'll at least run it now
[04:48:27] <jmkasunich> thanks
[04:48:46] <jmkasunich> it should work with no changes to the config, the default ctrl_type is p
[04:49:02] <cradek> ok good
[04:51:25] <cradek> runs and sounds right
[04:51:35] <jmkasunich> good
[04:52:12] <jmkasunich> tomorrow - man pages and lyx update, and a "deprecated" notice for freqgen (for 2.2, not 2.1.x)
[04:52:40] <cradek> now my monitor is going... :-/
[04:52:50] <jmkasunich> ouch
[04:53:04] <cradek> that's how it goes when you use all recycled stuff
[04:53:15] <jmkasunich> whats the monitor doing?
[04:53:19] <cradek> flowsnake ran fine...
[04:53:28] <cradek> some colors come and go (red I think?)
[04:53:40] <jmkasunich> oh - it just need some percussive maintainence
[04:53:43] <cradek> I took it apart and can't find the loose thing by poking around
[05:01:32] <cradek> jmkasunich: yep, seems fine, I ran several things
[05:01:55] <jmkasunich> cool, thanks
[05:02:06] <cradek> welcome
[05:02:42] <jmkasunich> * jmkasunich brings the farm back online
[05:03:20] <cradek> the realtime jogwheel sure works well
[05:14:19] <jmkasunich> darn you!
[05:14:26] <cradek> ?
[05:14:39] <jmkasunich> that inconsequential commit started new builds on the vms
[05:14:50] <cradek> oh heck, sorry
[05:15:06] <jmkasunich> I have two of them started (and loaded 10M of updates)
[05:15:14] <cradek> you're never safe from my inconsequential commits!
[05:15:14] <jmkasunich> getting ready to start the third one
[05:15:18] <jmkasunich> no problem ;-)
[05:15:47] <jmkasunich> I need to figure out how to make an incremental build more incremental
[05:16:06] <jmkasunich> that commit should result in "nothing to be done" and return in about 5 seconds
[05:16:29] <jmkasunich> but I run configure all the time, which in turn touches some files and results in them getting built
[05:16:39] <cradek> don't run configure - it will run when necessary
[05:16:55] <jmkasunich> just haven't gotten around to changing the scripts
[05:28:32] <jmkasunich> odd - the bdi slot (and only the bdi slot) is doing a build on the 2.0 branch
[05:28:46] <jmkasunich> there haven't been any changes there in a while I thought
[05:31:15] <jmkasunich> ok, this is weird
[05:31:43] <jmkasunich> your change to /docs/man/man9/,cvsignore appeared in the bdi's 2.0 branch checkout!
[05:32:17] <cradek> hmm that doesn't seem right
[05:33:26] <jmk-vm04> ? build_log
[05:33:27] <jmk-vm04> ? cvs_log
[05:33:27] <jmk-vm04> ? farm_build
[05:33:27] <jmk-vm04> ? history_log
[05:33:28] <jmk-vm04> ? last_complete
[05:33:28] <jmk-vm04> P docs/man/man9/.cvsignore
[05:33:29] <jmk-vm04> CVS_SUCCESS
[05:33:37] <jmkasunich> that is the output from the CVS up
[05:33:48] <jmkasunich> (ignore the last line, thats from my script)
[05:35:22] <cradek> what's the command it uses?
[05:36:19] <jmk-vm04> ? build_log
[05:36:20] <jmk-vm04> ? cvs_log
[05:36:20] <jmk-vm04> ? farm_build
[05:36:20] <jmk-vm04> ? history_log
[05:36:22] <jmk-vm04> ? last_complete
[05:36:23] <jmk-vm04> P docs/man/man9/.cvsignore
[05:36:23] <jmk-vm04> CVS_SUCCESS
[05:36:25] <jmk-vm04> fsck
[05:36:30] <jmk-vm04> cvs -z5 -q up -dP
[05:36:33] <jmk-vm04> sorry
[05:37:05] <cradek> huh
[05:37:11] <cradek> cvs stat docs/man/man9/.cvsignore
[05:37:25] <cradek> I bet it doesn't have the v2_0_branch sticky tag
[05:38:09] <jmk-vm04> nope
[05:38:54] <jmk-vm04> looks like no files in that dir have the stick tag
[05:38:58] <jmk-vm04> wtf is going on>?
[05:39:08] <cradek> I don't know
[05:39:28] <cradek> easy to fix though (cvs up -rv2_0_branch)
[05:40:19] <jmk-vm04> I wonder if the fact that docs/man has no files, only directories, has anything to do with it?
[05:40:41] <jmk-vm04> in the CVS/ dir, tags only seem to be associated with the files
[05:43:58] <jmkasunich> there were two directories that must have lost their tags somehow
[05:44:23] <jmkasunich> docs/man/man9, and src/emc/usr_intf/axls/scripts
[05:44:50] <jmk-vm04> when I did the up with -rv2_0_branch, I got lines like:
[05:44:51] <jmk-vm04> cvs update: src/emc/usr_intf/axis/scripts/.cvsignore is no longer in the repository
[05:45:08] <cradek> that's normal, if those files are not on the branch you're changing to
[05:45:13] <jmk-vm04> right
[05:45:26] <jmk-vm04> but that means they somehow got into this checkout.....
[05:46:16] <jmk-vm04> the man9 directory postdates the 2.0 branch, I wonder if the regular cvs up gets head when it finds a new directory?
[05:47:02] <cradek> I bet if you don't have a -P (even just once), you'll get those new directories
[05:47:22] <jmkasunich> src/emc/usr_intf/axis/scripts has one thing in common with docs/man/man9
[05:47:35] <jmkasunich> no files in the dir that is above it
[05:47:49] <jmkasunich> (I guess another thing in common - added after 2.0)
[05:47:57] <jmkasunich> axis wasn't part of emc for 2.0 was it?
[05:48:04] <cradek> no
[05:49:14] <jmkasunich> I did the up -rv2_0... again, this time with -dP, and the axis dir went away too
[05:49:26] <cradek> good
[05:49:53] <jmkasunich> I may have done a manual cvs up at some point, trying to fix some other problem
[05:50:05] <cradek> yeah I bet it was something like that
[05:50:07] <jmkasunich> I should probably take a look at the other branches, and the other slots
[05:51:21] <jmkasunich> yep - the 2.1 branch had a lot of m5i20 firmware files that weren't supposed to be there
[05:51:41] <jmk-vm04> checking the other slots now
[05:56:47] <jmkasunich> of the 8 branch checkouts, 3 had stuff that shouldn't have been there
[05:56:49] <jmkasunich> all fixed now
[05:58:49] <jmkasunich> I really wish my system wasn't at 25% load just sitting still
[15:14:51] <steves_logging> steves_logging is now known as steve_stallings
[17:47:41] <alex_joni> hi guys
[17:50:49] <jepler> hi alex
[17:50:58] <jmkasunich> hi
[17:51:08] <jepler> * jepler could use a nap
[17:52:50] <jmkasunich> * jmkasunich didn't wake up until 11:30 ;-)
[17:53:31] <alex_joni> jmkasunich: same here ;)
[17:53:36] <alex_joni> but that was 8 hours ago
[17:55:31] <jmkasunich> biab
[18:02:55] <cradek> I woke up early today (11)
[18:14:36] <cradek> last call for checkins before I start making packages...
[18:26:13] <cradek> alex_joni: I thought you changed the tkemc Tools menu to Utilities
[18:47:03] <cradek> I just got some advertisement that says for $10/mo extra, I can get 1Mbit upload speed...
[18:47:11] <cradek> that would be nice sometimes.
[18:50:25] <steve_stallings> steve_stallings is now known as steves_logging
[18:56:50] <cradek> jepler: I can't find your wiki page about offline updating
[18:57:23] <cradek> spoke too soon
[18:57:40] <jepler> cradek: it's just the last sentence of
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?InstallingUpdates
[18:57:54] <skunkworks> seems to be a bit one sided conversation
[18:58:05] <skunkworks> oops - spoke too soon
[19:38:09] <alex_joni> cradek: that was on TRUNK
[19:39:29] <jepler> cradek: thanks for making the release
[19:40:11] <alex_joni> cradek: I'll do SF & linuxcnc.org now
[19:40:30] <jepler> I tried to get the wiki stuff
[19:40:59] <alex_joni> jepler: cool, seems we're getting better/faster with each release
[19:41:24] <jepler> it'd still be nice if the version number was written in fewer places :-P
[19:41:54] <alex_joni> jepler: cvs seems a bit slow atm
[19:42:53] <jepler> I'm sorry to hear that
[19:43:06] <alex_joni> hmm.. seems ok now
[19:43:14] <alex_joni> just had a longer time till the download started
[19:43:22] <jepler> getting the .tar?
[19:43:28] <alex_joni> .gz .. yeah
[19:43:43] <alex_joni> the viewcvs is great for that
[19:43:56] <alex_joni> cradek: thanks again for setting that up so nicely
[19:44:59] <alex_joni> jepler: it finished, so I'd say it's OK
[19:55:01] <jepler> good
[19:56:28] <alex_joni> ok, sourceforge done, linuxcnc next
[20:00:06] <alex_joni> done
[20:03:15] <alex_joni> jepler: short question about using mdi
[20:03:39] <alex_joni> any reason for it to be slower than the mdi inside AXIS?
[20:03:51] <alex_joni> * alex_joni thinks maybe switching modes might take a while..
[20:04:09] <jepler> beats me
[20:04:20] <alex_joni> (background: a user wants to do teaching on his robot, he has some custom program, and I suggested him to use the mdi script to send commands to emc)
[20:04:19] <jepler> I never use the "mdi" script
[20:13:19] <jepler> certainly you could try modifying it so that only sets the MDI mode once, or if it detects the mode has changed
[20:33:48] <alex_joni> hi SWampy
[20:34:15] <SWPadnos> Hi Alex :)
[20:35:56] <alex_joni> how are things over there?
[20:36:03] <SWPadnos> cold
[20:36:13] <alex_joni> oh, it's quite warm here
[20:36:26] <SWPadnos> we just got home to a foot or two of snow in the driveway (since Thursday night)
[20:36:32] <SWPadnos> how was Germany?
[20:40:26] <alex_joni> it wasn't.. didn't make it, something came up
[20:40:30] <SWPadnos> bummer
[20:57:00] <alex_joni> I know I asked this before.. how do you feel about mass mails about new releases from linuxcnc.org ?
[20:57:51] <SWPadnos> I don't mind, but I'm not sure everyone would agree with me
[20:59:01] <alex_joni> I didn't get any reply that would indicate otherwise though
[21:01:12] <SWPadnos> is there a significant number of pwople signed up at linuxcnc.org (that aren't also on the user/dev lists?)
[21:01:15] <SWPadnos> people
[21:01:30] <alex_joni> about 400 people
[21:01:42] <SWPadnos> wow - didn't know it was that many.
[21:02:01] <SWPadnos> are there email settings in the personal profile setup there?
[21:02:12] <SWPadnos> if so, then there should be no problem
[21:02:19] <SWPadnos> (since people can turn it off if they like)
[21:02:23] <alex_joni> what kind of settings?
[21:02:45] <SWPadnos> lots of online forums have settings for sending emails, not sending emails
[21:02:55] <SWPadnos> that the users can set for themselves
[21:03:00] <alex_joni> I don't think so
[21:03:03] <SWPadnos> bummer
[21:03:25] <alex_joni> "PS: please let us know if you don't want to receive announcements by email.
[21:03:25] <alex_joni> "
[21:03:32] <alex_joni> that's what I wrote in the last one
[21:03:35] <alex_joni> got one single reply ..
[21:04:18] <SWPadnos> heh
[21:04:33] <SWPadnos> then I'd say it's OK :)
[21:05:45] <alex_joni> the reply said something like great to keep us posted .. or the like
[21:09:26] <alex_joni> hmm.. maybe I'll keep that only for major releases
[23:58:52] <alex_joni> jmkasunich: it seems clear to me.. the source stuff
[23:59:09] <alex_joni> but that's probably cause I wrote that :/
[23:59:11] <jmkasunich> of course, you wrote it
[23:59:15] <jmkasunich> ;-)
[23:59:14] <alex_joni> right
[23:59:43] <jmkasunich> I gotta look at an older version and see what it did in the delta=0 case