Back
[00:45:12] <fenn> i've never found myself admiring clocks before, but this page from the mcmaster catalog speaks to me:
http://www.mcmaster.com/#office-products/=ho061
[00:45:45] <fenn> well, really the whole catalog is amazing
[00:49:24] <jmkasunich> fenn - yes, it is
[00:49:42] <jmkasunich> you should keep one in the bathroom as reading material
[00:51:31] <archivist> that page fails to speak to me
[00:51:52] <jmkasunich> very mundane clocks by your standards
[00:52:11] <archivist> and the page did not render properly
[00:52:44] <archivist> http://www.archivist.info/clock/
[00:53:24] <fenn> http://fennetic.net/pub/irc/mcmaster_clocks.png
[00:53:45] <fenn> if you increase the text size the images scale up and get pixelated
[00:56:26] <jmkasunich> fenn: what browser did you take that shot from?
[00:56:30] <SWPadnos> with firefox 3 that happens, with other browsers it may not
[00:56:47] <jmkasunich> for me, the clocks (pic) appear under the gray block, and above the rest of the text
[00:56:49] <SWPadnos> it's iceweasel
[00:57:41] <archivist> what I see
http://www.collection.archivist.info/Screenshot.png
[00:57:53] <SWPadnos> it's about the same as fenn for me, using Mozilla on Windows
[00:58:03] <SWPadnos> and also with Firefox 3 on Windows
[00:58:04] <fenn> archivist: no clocks?
[00:58:25] <archivist> scrunched in the box at the bottom
[00:58:53] <archivist> scroll bar too short as well
[00:59:23] <SWPadnos> it doesn't fare well when you have insufficient vertical space
[00:59:34] <SWPadnos> same thng happens if I increase font size 5 times
[00:59:46] <fenn> right click -> open frame in new tab
[00:59:47] <archivist> firefox 3.05
[00:59:52] <fenn> or maximize your window
[01:00:10] <fenn> hmm so much for CSS
[01:00:26] <jmkasunich> http://jmkasunich.com/pics/mcmaster-clocks.png
[01:00:28] <SWPadnos> F11: toggle full screen mode
[01:00:30] <archivist> maximise makes bugger all difference
[01:02:14] <archivist> monitor is set at 1280x768
[01:02:59] <archivist> anyway we make em
[01:04:46] <fenn> hmm this isnt quite the same..
http://thepiratebay.org/torrent/4540835/McMaster-Carr_Catalog__114_in_PDF_-_3675_Pages_Total
[01:05:00] <archivist> * archivist looks at page source and is ill
[01:14:57] <fenn> so opencascade is free software after all, this is news to me
[01:14:59] <fenn> http://lists.debian.org/debian-legal/2007/12/msg00066.html
[02:29:57] <jmkasunich> you hear the strangest things on folk alley:
http://www.artistsofnote.com/michael/lyrics/zippy.shtml
[02:41:05] <jmkasunich> how goes the Atom?
[02:41:43] <SWPadnos> heh, yeah. which "it" worked? :)
[03:05:47] <JymmmEMC> Now, HERE's a clock for ya!!!
http://upload.wikimedia.org/wikipedia/commons/e/e1/Modern_water_clock.JPG
[03:07:05] <ehj> jmk: pretty well. I have it running, and get pretty good latency-test values (thanks swp), but still get unexpected realtime delay when emc starts.
[03:07:28] <jmkasunich> have you read the details about that message? (it prints info into dmesg)
[03:07:43] <ehj> Just a sec
[03:10:40] <ehj> dmesg says "In recent history there were 610728, 246756, 248196, 241980 and 244908 elapsed closks between calls to the motion controller. This time there were 307752 which is so anomalously large...
[03:10:55] <ehj> *closks
[03:11:02] <ehj> *clocks
[03:11:28] <jmkasunich> ok, there are actually two anomalies
[03:12:06] <jmkasunich> the 300,000 one is the one that tripped it, but 600,000 is even longer
[03:12:22] <jmkasunich> is this happening immediately when you start emc?
[03:12:29] <ehj> Yes
[03:12:46] <jmkasunich> I wonder if there is some kind of "startup transient" that is tripping it?
[03:12:52] <ehj> That is what I was wondering, since it always happens at startup.
[03:13:13] <jmkasunich> gotta be carefull - it might be happening many many times
[03:13:17] <cradek> you can't assume that. it only reports the error once per run.
[03:13:20] <jmkasunich> EMC only prints a message the first time it happens
[03:13:47] <jmkasunich> what is your servo period?
[03:13:51] <ehj> Yes I see that.
[03:14:18] <ehj> 325000 was what was right on the threshold on the non smp system.
[03:14:41] <jmkasunich> ehj: how did you get a typo in that dmesg report? are you copying things manually to the IRC window?
[03:15:02] <ehj> Typo, on a different computer.
[03:15:08] <jmkasunich> why?
[03:15:47] <jmkasunich> I can't imagine trying to discuss a problem on a computer other than the one that is having the problem
[03:15:53] <SWPadnos> (or, to rephrase, why not join IRC from the EMC computer?)
[03:15:55] <ehj> Haven't set anything up on the linux machine, a fresh install right before building the new kernel, etc. Not that it is hard to set up.
[03:16:03] <jmkasunich> (unless said problem is "can't connect to the computer to the net")
[03:16:23] <jmkasunich> wait - isn't the Atom running a linux kernel that you built?
[03:16:38] <SWPadnos> you could just install ssh on the EMC machine, so you could look at logs and stuff with a terminal from which you can cut and paste
[03:16:42] <ehj> Yea, I can. I have just always used the doze machine for email, chat, etc.
[03:16:50] <jmkasunich> eww
[03:17:01] <ehj> Silly me, it is already setup. :)
[03:17:10] <SWPadnos> putty to the rescue :)
[03:17:15] <jmkasunich> I just remembered that you have a bare minimum install on the Atom
[03:17:28] <jmkasunich> I have hardy on mine, so I went ahead and installed xchat, etc
[03:17:50] <jmk-robot> see?
[03:17:52] <SWPadnos> showoff
[03:18:04] <jmkasunich> pthbbt
[03:18:14] <ehj> Well not now, because it was a full install of ubuntu to get the build environment. Same processor but I stuck a 500gb drive one it and created 3 bootable partitions.
[03:18:42] <jmkasunich> ok, then the thing to do is install xchat (or your favorite IRC client)
[03:18:56] <jmkasunich> that way you can paste things (like error messages) here
[03:19:07] <ehj> yea, usually I just install the opera browser and use chat from there.
[03:19:26] <jmkasunich> if you can do that easily (and soon), please do
[03:19:41] <jmkasunich> if not, lets work on your realtime issue this way
[03:20:02] <SWPadnos> ssh to the atom box from the windows box is quite viable
[03:20:08] <ehj> Next task is to figure out how to package emc up so I can install the binaries back onto my minimum xubuntu install.
[03:20:15] <SWPadnos> there's no difference as far as the terminal session is concerned
[03:20:39] <jmkasunich> SWPadnos: halscope over ssh from windows?
[03:20:52] <SWPadnos> well, it works great if you have cygwin/X installed
[03:20:56] <jmkasunich> he has a real operating system on the Atom, why not use it?
[03:20:58] <jmkasunich> ;-)
[03:21:13] <SWPadnos> I've run AXIS, halscope/meter, and other stuff on this aging Windows machine :)
[03:21:16] <SWPadnos> heh
[03:21:24] <jmkasunich> pthbbt again
[03:21:52] <jmkasunich> ehj: binaries are a pita
[03:22:16] <fenn> JymmmEMC: they had a 3 story version of that in the museum in my home town
[03:22:19] <ehj> I also isntalled cygwin/X. Have only played with it a little.
[03:22:39] <fenn> JymmmEMC:
http://www.childrensmuseum.org/themuseum/icons/waterclock.htm
[03:22:48] <skunkworksemc> up 4 days, 2:36
http://imagebin.ca/view/tnLo77.html One can only hope for a power outage.. ;)
[03:22:54] <ehj> jmk: Yea, so I have heard.
[03:24:16] <ehj> jmk, swp: I put the latest packages on my ftp site.
[03:24:39] <jmkasunich> smp kernel packages?
[03:24:43] <ehj> yes
[03:25:04] <ehj> swp copied the prior set someplace on linuxcnc.org
[03:25:13] <jmk-robot> I suppose I should install them - been running the latency test for about 4 days now, not learning anything new from that
[03:25:42] <jmk-robot> my results aren't as good as yours - about 16000nS jitter now, and it tends to top out a bit over 20K if I run glxgears
[03:25:49] <SWPadnos> linuxcnc.org/experimental/
[03:25:50] <ehj> ftp://ftp.camalytics.com/ username: linuxcnc password: emcrocks
[03:27:04] <ehj> I did mine on xubuntu. Moving windows doesn't seem to affect it much. Running other things has more affect, at least on ubuntu. Have not gone back to xubuntu to test again.
[03:27:20] <ehj> *effect
[03:27:21] <JymmmEMC> fenn: If you know... Does it need the pump after it's started?
[03:27:37] <jmk-robot> I'm running xubuntu at the moment (I have both xubuntu and plain old hardy ubuntu installed
[03:29:34] <ehj> I also don't run anything other than emc on the atom, the UI is remote, it doesn't even have a monitor.
[03:29:44] <jmk-robot> oh, I see
[03:30:00] <jmk-robot> what are you building anyway? this seems a bit more than the average hobby project?
[03:30:29] <ehj> A 3D laser engraver.
[03:31:44] <fenn> JymmmEMC: the pump runs at the beginning of each hour
[03:32:28] <JymmmEMC> fenn: Oh, ok.... That there might have been a perpentual motion thing going on there =)
[03:33:23] <SWPadnos> ehj, what filessytem are you using?
[03:33:28] <SWPadnos> -s
[03:33:36] <JymmmEMC> FAT12
[03:33:40] <ehj> The default,ext3
[03:33:43] <SWPadnos> ok
[03:33:49] <SWPadnos> but no X installed?
[03:33:56] <JymmmEMC> Just Y & Z
[03:34:02] <SWPadnos> shut up! :)
[03:34:19] <JymmmEMC> Open Down!
[03:34:26] <ehj> X is installed, I tried to get down to a minimum system.
[03:34:43] <jmk-robot> I'm trying to make sense of the numbers in that message
[03:34:49] <ehj> I would like to get rid of it too.
[03:34:57] <jmk-robot> are you using a non-standard servo period?
[03:35:57] <ehj> I think the last time I ran it I dropped servo period to 200000 to see if it was any different from 325000.
[03:35:57] <jmk-robot> the Atom 330 has a 1.6 GHz clock, if you are using the standard 1mS servo period, the interval should be 1.6 million clocks, not a couple hundred thousand
[03:36:02] <JymmmEMC> SWPadnos: If you know... Can you have 2 totally different subnets running on the same vlan?
[03:36:29] <jmk-robot> ehj: if you have timing problems, asking for more demanding timing usually isn't a good idea
[03:36:30] <SWPadnos> I won'd know about vlans, but in general multiple subnets are acceptable on the same wire as long as they all have the same netmask
[03:36:36] <SWPadnos> s/won't/don't/
[03:36:40] <jmk-robot> do you need an extra fast servo period for your machine?
[03:36:58] <ehj> My ultimate goal was to get the servo period to 200000 because that would match the 5khz frequency of the laser.
[03:37:11] <jmk-robot> its a pulsed lazer?
[03:37:14] <jmk-robot> laser
[03:37:20] <JymmmEMC> SWPadnos: Would the gateway for both subnets have to be the same host/router?
[03:37:30] <SWPadnos> no
[03:37:44] <ehj> The reference signal is pwm, the fastest it can be changed is 5khz, but will accept 5-25Khz.
[03:37:45] <SWPadnos> they ignore each other, since the networks don't match
[03:38:13] <jmk-robot> reference is the beam strength control?
[03:38:18] <ehj> yes
[03:38:30] <ehj> Duty cycle => power level.
[03:38:43] <JymmmEMC> SWPadnos: Hmmm, I might be able to get my paws on a Cisco 3500 switch... I *think* OpenWRT might run on it =)
[03:38:47] <jmk-robot> are you using software generated PWM for that, or is there a 5i20 or something in the picture?
[03:38:52] <SWPadnos> k
[03:39:07] <JymmmEMC> SWPadnos: or IOS at least - turns a switch into a router =)
[03:39:07] <ehj> 5i20 and 7i43.
[03:39:16] <jmk-robot> and?
[03:39:26] <ehj> Meaning I have used both.
[03:39:32] <jmk-robot> crapload of I/O on the laser?
[03:39:43] <SWPadnos> at different times, methinks
[03:39:47] <jmk-robot> oh
[03:39:57] <ehj> Depends on which one, but this one no.
[03:40:02] <jmk-robot> I'm asking what he is designing into this system
[03:41:01] <jmk-robot> anyway, back to the problem
[03:41:18] <ehj> k
[03:41:33] <jmk-robot> when you run the latency test, you never get anything even remotely like 200,000nS, right?
[03:41:39] <jmk-robot> (for jitter)
[03:41:46] <ehj> no
[03:41:54] <jmk-robot> have you tried the rtai latency test?
[03:42:08] <ehj> Worst I got was 15000 or so
[03:42:29] <ehj> Not yet, been away most of the day.
[03:43:05] <jmk-robot> is this a work project? (I'm away most of every day, as far as CNC is concerned)
[03:43:27] <ehj> Well yes, a personal work project.
[03:43:53] <jmk-robot> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TroubleShooting
[03:43:58] <jmk-robot> RTAI latency test ^^^^
[03:44:38] <SWPadnos> ehj, do you expect this unit to run headless?
[03:44:47] <ehj> Yea I see. I think swp pointed me to that in his post.
[03:44:49] <ehj> Yes
[03:44:50] <JymmmEMC> Is anyone ever gonna write a simple shell script and include that in the build???
[03:45:00] <jmk-robot> shell script to do what?
[03:45:03] <SWPadnos> latency-test is the HAL tester
[03:45:06] <JymmmEMC> rtai
[03:45:15] <jmk-robot> its one line
[03:45:34] <jmk-robot> (on some systems you might have to mkdir/mknod a couple things, I didn't have to do that here
[03:45:38] <SWPadnos> the troubleshooting page has some other information on how to interpret the information
[03:46:10] <SWPadnos> and also several steps to go through, but they're not A B C D, they're "if you think A sucked, you may want to try C"
[03:46:21] <SWPadnos> so I don't know how applicable a script is
[03:46:34] <jmk-robot> IOW, some modest thinking and reading comprehension is required
[03:46:39] <SWPadnos> (you could write one though, patches gratefully accepted :) )
[03:46:52] <jmk-robot> * jmk-robot grumbles
[03:46:55] <SWPadnos> heh
[03:47:13] <SWPadnos> damn. forgot to buy yogurt
[03:48:53] <jmk-robot> the nice thing about the RTAI latency test is that it prints a line of output every second
[03:49:08] <jmk-robot> with the highest latency that second, as well as the highest since the start of the test
[03:49:25] <jmk-robot> so you can see if something is messing it up at intervals, etc
[03:50:18] <jmk-robot> for example, when running glxgears, my typical "1 second max" is about 9000nS (the overall max is 14,000)
[03:50:34] <jmk-robot> when I stop glxgears, the 1-second max drops to 5000 or so
[03:52:13] <ehj> k, just got the rtai latency test running.
[03:52:22] <SWPadnos> if you clean up your initscripts, don't use X, and switch to ext2, you may get down into the 1000 range or lower
[03:53:01] <SWPadnos> the dual-core machine I set up around a year ago used the same chipset as these atom boards (the ICH7 part anyway)
[03:53:23] <jmk-robot> I'm trying to figure out how to install the smp debs I just downloaded
[03:53:30] <ehj> k, that sounds promising.
[03:53:50] <SWPadnos> dpkg -i <the.deb> I think
[03:54:01] <ehj> jmk: What am I looking for on the latency test?
[03:54:02] <jmk-robot> don't have to stick it in any particular place?
[03:54:03] <SWPadnos> or in the GUI, right-click and open with gdebi
[03:54:06] <SWPadnos> no
[03:54:22] <jmk-robot> ehj: anything funky
[03:54:54] <ehj> Like big differences between any of the numbers? So far very stable.
[03:54:55] <jmk-robot> you had 600K, 200K, 200K, 200K, 300K clocks for five successive runs of the servo thread
[03:55:15] <jmk-robot> the lat max and ovl max columns are the ones you care about
[03:55:23] <ehj> k
[03:55:37] <jmk-robot> I just had a thought that might explain the 600K
[03:55:47] <jmk-robot> you might simply be asking for too much
[03:56:07] <ehj> Too much what?
[03:56:14] <jmk-robot> the realtime code might (on rare occaisions, like if something flushes it out of cache) take longer than the period
[03:56:28] <jmk-robot> if you do that frequently, you lock up the machine
[03:56:42] <jmk-robot> but if its just once in a while, it might not be very obvious
[03:56:44] <jmk-robot> here is a test
[03:56:48] <jmk-robot> stop the rtai latency test
[03:56:50] <jmk-robot> start emc
[03:56:54] <jmk-robot> open a shell
[03:56:58] <jmk-robot> start halcmd
[03:57:05] <jmk-robot> and look at the thread times
[03:57:30] <ehj> I have had no problems while EMC is running with lockups, except after realtime shuts down. Occasionally the computer will lock up hard then (kernel panic?).
[03:57:36] <ehj> k
[03:58:06] <jmk-robot> sounds like the RT kernel isn't very stable
[03:59:15] <jmk-robot> halcmd: show thread
[03:59:15] <jmk-robot> Realtime Threads:
[03:59:15] <jmk-robot> Period FP Name ( Time, Max-Time )
[03:59:15] <jmk-robot> 988960 YES servo-thread ( 22116, 40800 )
[03:59:16] <jmk-robot> 1 stepgen.capture-position
[03:59:18] <jmk-robot> 2 motion-command-handler
[03:59:20] <jmk-robot> 3 motion-controller
[03:59:22] <jmk-robot> 4 stepgen.update-freq
[03:59:24] <jmk-robot> 49448 NO base-thread ( 8292, 18696 )
[03:59:26] <jmk-robot> 1 parport.0.read
[03:59:28] <jmk-robot> 2 stepgen.make-pulses
[03:59:30] <jmk-robot> 3 parport.0.write
[03:59:32] <jmk-robot> thats while running the stepper-inch sample config
[03:59:57] <jmk-robot> 40800 clocks to run the servo thread is a tiny tiny fraction of the 1.6 million clocks I have every millisecond
[04:00:14] <jmk-robot> even tho you have the thread 5x faster, it should be fine
[04:00:22] <jmk-robot> unless your servo thread is doing more than this config does
[04:00:43] <jmk-robot> also note that I haven't brought it out of estop or jogged or anything, I bet that number will go up
[04:01:01] <ehj> Show thread numbers 250068, 588588
[04:01:09] <jmk-robot> ouch
[04:01:21] <jmk-robot> ok, we're getting somewhere
[04:01:23] <SWPadnos> the ICH7 sucked for PCI access time. 200 uS is enough time for several hundred accesses, but that may not be enough
[04:01:36] <SWPadnos> show param *tmax
[04:01:41] <SWPadnos> ^^ ehj
[04:01:53] <jmk-robot> first, which threads are those times for?
[04:02:00] <jmk-robot> (see why I want you to be able to paste?)
[04:02:20] <ehj> yea
[04:02:32] <jmk-robot> halcmd: show param *tmax
[04:02:32] <jmk-robot> Parameters:
[04:02:32] <jmk-robot> Owner Type Dir Value Name
[04:02:32] <jmk-robot> 5 s32 RW 12300 motion-command-handler.tmax
[04:02:32] <jmk-robot> 5 s32 RW 43548 motion-controller.tmax
[04:02:33] <jmk-robot> 7 s32 RW 21132 parport.0.read.tmax
[04:02:35] <jmk-robot> 7 s32 RW 0 parport.0.reset.tmax
[04:02:37] <jmk-robot> 7 s32 RW 15708 parport.0.write.tmax
[04:02:39] <jmk-robot> 7 s32 RW 0 parport.read-all.tmax
[04:02:41] <jmk-robot> 7 s32 RW 0 parport.write-all.tmax
[04:02:43] <jmk-robot> 6 s32 RW 11076 stepgen.capture-position.tmax
[04:02:47] <jmk-robot> 6 s32 RW 11184 stepgen.make-pulses.tmax
[04:02:49] <jmk-robot> 6 s32 RW 13200 stepgen.update-freq.tmax
[04:02:51] <jmk-robot> this tells me how much time (worst case) each function is using
[04:02:58] <jmk-robot> you'll probably have one function that sticks out like a sore thumb
[04:03:25] <ehj> motion-command-handler.tmax 2952 motion-controller.tmax 35808
[04:03:46] <jmk-robot> are any of them 100K or more?
[04:04:05] <ehj> Yes, the hm2_ tasks
[04:04:14] <jmk-robot> ah - SWP called it I bet
[04:04:14] <ehj> hm2_7i43
[04:04:17] <jmk-robot> PCI bus access time
[04:04:20] <jmk-robot> oh, worse
[04:04:23] <jmk-robot> EPP access time
[04:04:41] <jmk-robot> there's simply NFW you are gonna get those kind of thread periods using EPP interfaces
[04:04:59] <jmk-robot> the parport is incredibly slow - about 1 byte per microsecond
[04:05:06] <ehj> That was one thing I wanted to ask Sebastian. I looked like the 7i43 times were much slower than 5i20, but did not do a fair apples to apples test.
[04:05:18] <SWPadnos> they will be slower
[04:05:19] <jmk-robot> they are - at _LEAST_ 4x slower
[04:05:21] <ehj> *It
[04:05:31] <jmk-robot> the parport is one byte at at time, the PCI bus is 4 bytes at a time
[04:05:32] <SWPadnos> the EPP can only do 1 byte at a time, and it's once per microsecond or so
[04:05:49] <SWPadnos> PCI (with the ICH7) does 32 bit transfers, about 1 or so per microsecond
[04:06:00] <SWPadnos> or 12 bytes/microsecond instead of 1-1.2
[04:06:12] <ehj> One the base system I could get down to about 240000 for servo thread on 5i20, but 325000 for 7i43.
[04:06:14] <SWPadnos> err, about 3 or so per microsecond for PCI
[04:06:37] <jmk-robot> when you say "could get down to", do you mean the tmax readings?
[04:06:41] <SWPadnos> with a better chipset, the 5i20 would be a lot faster
[04:06:43] <jmk-robot> or were you doing trial and error?
[04:07:02] <ehj> Not getting unexpected real time delay messages.
[04:07:12] <jmk-robot> * jmk-robot cries quietly
[04:07:16] <SWPadnos> heh
[04:07:25] <jmk-robot> hal was designed to let you see these things
[04:07:42] <jmk-robot> but nobody ever looks
[04:07:59] <SWPadnos> the ]Homer Simpson method is so much more popular
[04:08:03] <SWPadnos> -]
[04:08:46] <jmk-robot> if you want fast servo periods, you want a 5i20, not a 7i43
[04:09:04] <jmk-robot> simple as that
[04:09:23] <ehj> Yea, I have both. I was hoping to use the 7i43 mainly because it makes wiring easier.
[04:09:52] <jmk-robot> make your servo period about twice the tmax time of the 7i43 driver function, and you can use it
[04:10:24] <ehj> That would be about 800000
[04:10:36] <jmk-robot> do you have a base thread at all?
[04:10:47] <jmk-robot> (not needed if you aren't doing software stepping or pwm or encoder counting)
[04:10:48] <ehj> yes
[04:11:05] <jmk-robot> are you running anything in that thread?
[04:11:15] <jmk-robot> "halcmd show thread" will tell you
[04:11:18] <ehj> No, just left it around just in case.
[04:11:51] <jmk-robot> it's period should be the same as the servo period then - no reason to add more load to the CPU
[04:12:30] <jmk-robot> what I'd do is set the servo period to 1mS, then abuse the system to get worst case times
[04:12:43] <ehj> k, I played with it too, did not make much difference regardless of value (reasonable anyway).
[04:13:00] <ehj> k
[04:13:22] <jmk-robot> define "make much difference" ? it doesn't sound like you were actually measuring anything
[04:13:34] <jmk-robot> (presence or absence of realtime overrun messages doesn't count)
[04:14:06] <jmk-robot> sorry, I'm being a curmugeon
[04:14:19] <jmk-robot> basically, that message is a "check engine" light
[04:14:37] <jmk-robot> show threads time numbers and tmax parameters are oil pressure, etc gages
[04:14:41] <ehj> No only meaning whether I got the unexpected real time delay message.
[04:15:12] <ehj> yea, I get it.
[04:26:53] <jmk-robot> hyperthreading must be enabled - I have 4 cpus
[04:27:05] <jmk-robot> Linux robot 2.6.24-16-rtaismp #1 SMP PREEMPT Fri Feb 6 08:51:25 EST 2009 i686 GNU/Linux
[04:27:10] <ehj> Yes, turn it off in the bios
[04:27:19] <jmk-robot> oh, its not a kernel thing
[04:27:27] <ehj> no
[04:28:12] <SWPadnos> test with both though, I'm assuming that HT isn't helpful, but you should look
[04:28:23] <cradek> jmk-robot: did you build a new smp kernel?
[04:28:26] <SWPadnos> try isolcpus=2,3 if you use HT
[04:28:47] <jmk-robot> no, I just installed the debs that Eric built
[04:28:53] <cradek> neat
[04:29:00] <jmk-robot> I'm a little surprised to see PREEMPT there
[04:31:43] <jmk-robot> do-nothing loop helps - not as dramatic as on the core2 IIRC, but noticable
[04:31:56] <jmk-robot> 1 second averages go from about 5-6K to about 2K
[04:32:03] <jmk-robot> 1-second maxes that is
[04:33:01] <jmk-robot> ovl max still made it up to 15K when I started glxgears
[04:36:11] <SWPadnos> 1-second averages or 1-second max?
[04:39:16] <jmkasunich> 1 sec max
[04:39:27] <jmkasunich> this is interesting in an annoying way
[04:39:34] <SWPadnos> heh
[04:39:35] <jmkasunich> the new kernel did fine with the network the first time
[04:39:48] <jmkasunich> but when I turned off HT in the bios, it couldn't connect to the net
[04:40:00] <SWPadnos> odd
[04:40:07] <jmkasunich> why (or even if) they are connected I have no clue
[04:40:09] <ehj> I had that happen once or twice too.
[04:40:50] <SWPadnos> I sometimes do a full (real) power cycle if BIOS changes give strange behavior
[04:40:55] <SWPadnos> the chipset never really powers down
[04:41:01] <SWPadnos> (unless you pull the plug)
[04:41:32] <SWPadnos> and I usually pull the plug while it's doing the memory test or something, to make sure it drains various caps
[04:45:01] <ehj666-2> ehj666-2 is now known as ehj-2
[04:45:09] <SWPadnos> yay
[04:45:17] <jmkasunich> atomic eric?
[04:45:28] <ehj> yes
[04:45:31] <SWPadnos> bzzt bzzt
[04:45:53] <jmkasunich> hmm, must have been a coincidence, now it isn't working with HT on either
[04:46:04] <SWPadnos> yay!
[04:46:06] <SWPadnos> uh
[04:46:09] <SWPadnos> well, you know
[04:47:23] <jmkasunich> I really wish they'd stop making things pretty
[04:47:58] <jmkasunich> there is a stupid spinning logo in the taskbar that says "requesting a network address from the wired network"
[04:48:04] <jmkasunich> IOW, its trying to do DHCP
[04:48:24] <ehj-2> Yea, that is what I got too.
[04:48:24] <jmkasunich> but the icon doesn't stop if I do sudo /etc/init.d/networking stop, etc
[04:48:29] <SWPadnos> well, it could be "connecting to wireless netowkr xxx"
[04:48:46] <jmkasunich> I dunno if they've broken the "old ways", or if the icon is just without clue
[04:48:56] <JymmmEMC> jmkasunich: dhclient
[04:49:26] <SWPadnos> the icon is without clue
[04:49:27] <jmkasunich> in init.d?
[04:49:45] <SWPadnos> I don't know if a DBUS signal is emitted when you use ifconfig
[04:49:55] <JymmmEMC> no, I think the icon is assoc with dhclient somehow
[04:50:00] <jmkasunich> ifconfig does nothing
[04:50:01] <SWPadnos> I think the icon uses DBUS
[04:50:22] <JymmmEMC> all I know it' sfscking slower than hell making a connection
[04:50:25] <SWPadnos> JymmmEMC, it is in some way, but it's more than just DHCP
[04:50:35] <jmkasunich> /etc/init.d/networking start says "Ignoring unknown interface eth0=eth0."
[04:51:06] <SWPadnos> don't go looking for the empty config files, you'll blow a gasket ;)
[04:51:16] <JymmmEMC> SWPadnos: Guess I'm getting spoiled on OSX... you switch from wired to wireless it's almost instantaious
[04:51:39] <SWPadnos> that assumes that the underlying connections are also instantaneous
[04:52:06] <JymmmEMC> SWPadnos: No, not really. I can switch from wired to wlan without issues too
[04:52:16] <JymmmEMC> err wwan I mean
[04:52:44] <SWPadnos> no, what I mean is that if the machine is waiting for a DHCP address, it shouldn't be instantaneous on the mac either
[04:53:06] <SWPadnos> I know that the Ubuntu notifier is a bit slow, but it's not all the fault of network-manager
[04:53:46] <JymmmEMC> SWPadnos: It shouldn't but it pretty much is. I've done it a coupel of times and not even lost connect to the server, or if I did, it reconnected without being noticed.
[04:54:10] <SWPadnos> the mac may be maintaining multiple connections
[04:54:22] <SWPadnos> which is something that network manager can't do in 8.04
[04:54:32] <SWPadnos> (or 8.10 AFAIK, I think that's going into 9.04)
[04:54:33] <JymmmEMC> SWPadnos: Can't be... I physically plugin the WWAN card =)
[04:54:38] <SWPadnos> ah :)
[04:59:25] <jmk-robot> # The primary network interface
[04:59:25] <jmk-robot> auto eth0
[04:59:25] <jmk-robot> iface eth0 inet dhcp
[04:59:48] <jmk-robot> "something" commented out the last line, when I uncommented it it started working again
[05:00:25] <SWPadnos> strange
[05:00:36] <SWPadnos> doubly strange - there's actual text in the config file :)
[05:00:42] <jmk-robot> hmm, still four cores
[05:00:50] <jmk-robot> I thought I turned HT back off
[05:00:58] <jmk-robot> booting again
[05:01:18] <jmkasunich> rebooting is very annoying
[05:02:25] <ehj> jmk: I am rebuilding the kernel. I just remembered I had made a change, compiled but never installed it. I just put it back to what I have installed.
[05:02:37] <jmkasunich> I don't think I've rebooted this many times in the last 6 months
[05:04:26] <jmk-robot> two cpus now
[05:04:46] <ehj> good
[05:04:48] <ds3> a
[05:09:11] <jmk-robot> ehj: what is the thing that you changed?
[05:09:30] <ehj> Just a sec.
[05:11:16] <ehj-2> I uncommented CONFIG_SCHED_SMT=y, then found out I did not need it, but had already compiled. I never installed, but it was the last package built.
[05:21:56] <jmk-robot> thats odd:
[05:21:59] <jmk-robot> real3m56.821s
[05:21:59] <jmk-robot> user0m0.000s
[05:21:59] <jmk-robot> sys6m45.189s
[05:22:04] <jmk-robot> compiling EMC2
[05:22:12] <jmk-robot> I've never seen "user" zero before
[05:23:15] <SWPadnos> was that with -jn?
[05:23:21] <jmkasunich> j3
[05:23:31] <SWPadnos> user==0 is strange
[05:23:42] <SWPadnos> the total time seems a bit long too, but I don't know
[05:23:54] <jmkasunich> I'm doing it again
[05:23:55] <SWPadnos> (I usually compile non-RT ...)
[05:24:19] <jmkasunich> updatedb was running before I started - I waited till it was done, but it might have filled disk caches up, etc
[05:24:56] <SWPadnos> that might explain larger than normal sys times
[05:25:07] <SWPadnos> but not zero user
[05:25:29] <jmk-robot> I've also been running the RTAI latency test ever since I restarted...
[05:25:45] <SWPadnos> ah
[05:26:16] <jmk-robot> real3m47.695s
[05:26:16] <jmk-robot> user0m0.000s
[05:26:16] <jmk-robot> sys6m42.697s
[05:26:30] <SWPadnos> there may be some accounting thing that's turned off in the kernel
[05:26:44] <jmk-robot> I just stopped the latency test and started the make again
[05:30:14] <jmk-robot> real3m33.519s
[05:30:14] <jmk-robot> user5m53.698s
[05:30:14] <jmk-robot> sys0m35.098s
[05:30:24] <jmk-robot> apparently when RTAI is loaded, everything is "system"
[05:30:34] <SWPadnos> interesting
[05:31:48] <SWPadnos> which kind of linear bearing track were you looking for?
[05:31:57] <jmk-robot> me? SR-20
[05:32:02] <SWPadnos> ah, ok
[05:32:12] <jmk-robot> I have 8 cars, no track
[05:32:24] <SWPadnos> someone on CCED mentioned selling a lot of them, but they're HSR35, HSR45 ...
[05:32:31] <jmk-robot> someday I'll learn that cars without track aren't that usefull
[05:32:55] <jmk-robot> I picked up two 37" pieces of SR25 track with 4 cars at HGR last weekend
[05:33:03] <SWPadnos> oh, cool
[05:33:05] <jmk-robot> those will be X on my someday gantry mill
[05:40:07] <jmk-robot> running stepper-inch, splash g-code, servo thread max 104K clocks, base thread max 14K
[05:40:45] <jmk-robot> averages seem to be about 40K and 8K
[05:41:14] <SWPadnos> cool
[05:42:43] <jmk-robot> its really amazing how fast PCs are
[05:42:59] <jmk-robot> stepgen's base thread part makes the steps for three channels in an average of 500 clocks
[05:43:50] <jmk-robot> thats 312 nanoseconds
[05:44:11] <jmk-robot> parport reads take 5x as long, parport writes 10x
[05:44:50] <jmk-robot> ehj: ehj-2: thanks for building that kernel!
[05:45:41] <ehj> np
[05:46:13] <ehj> thanks for all the help allowing me to build the kernel.
[05:46:18] <SWPadnos> kind of makes you wonder what it's doing for the 6000 clocks of a context switch
[05:46:34] <SWPadnos> (or whatever is happening during the latency)
[05:50:28] <SWPadnos> hmmm. the atom systems use DDR2-533?
[05:50:33] <jmk-robot> yes
[05:50:56] <jmk-robot> interesting - when I started glxgears, latency jumped up to 12uS
[05:51:14] <SWPadnos> once or somewhat repeatably?
[05:51:27] <jmk-robot> but if I reset the counters (using halcmd), the max remains down around 4us
[05:51:35] <jmk-robot> seems like the real hit is at startup
[05:51:55] <SWPadnos> what happens if you start another one going?
[05:52:20] <SWPadnos> and/or stop it (them), then start one again
[05:52:26] <jmk-robot> no hit right away, but a few seconds later it went to 14uS
[05:52:46] <SWPadnos> just "later" or when the screen appeared or something?
[05:53:08] <jmk-robot> I wasn't being very observent
[05:53:18] <jmk-robot> the 2nd window opened directly on top of the first
[05:53:22] <SWPadnos> ok
[05:53:25] <jmk-robot> I think the hit happened when I dragged it away
[05:53:37] <SWPadnos> ah, ok
[05:53:48] <SWPadnos> using the vesa driver?
[05:53:55] <jmk-robot> who the heck knows
[05:54:10] <SWPadnos> /var/log/Xorg.0.log knows
[05:54:13] <jmk-robot> probalby not - I didn't mess with config
[05:54:15] <jmk-robot> yeah, checking
[05:55:09] <jmk-robot> (II) Matched intel from file name intel.ids in autoconfig
[05:55:09] <jmk-robot> (==) Matched intel for the autoconfigured driver
[05:55:09] <jmk-robot> (==) Assigned the driver to the xf86ConfigLayout
[05:55:09] <jmk-robot> (II) LoadModule: "intel"
[05:55:09] <jmk-robot> (II) Loading /usr/lib/xorg/modules/drivers//intel_drv.so
[05:55:10] <jmk-robot> (II) Module intel: vendor="X.Org Foundation"
[05:55:36] <SWPadnos> ok, so it's using the intel driver, which is actually a real openGL driver
[05:55:58] <jmk-robot> getting very nice framerates - 300ish
[05:56:00] <SWPadnos> so it's possible that transferring the display list for the gears is what caused the first bump
[05:56:09] <SWPadnos> heh
[05:56:20] <SWPadnos> on both or just one?
[05:56:34] <jmk-robot> actually, right now both are doing 500
[05:56:43] <SWPadnos> both fully visible?
[05:56:54] <jmk-robot> no, lemme unbury
[05:57:06] <jmk-robot> ah, that dropped it, now 300 again
[05:57:08] <SWPadnos> yeah, drawing is a lot faster when there's nothing to draw :)
[05:58:11] <SWPadnos> man. it would be really nice if ATI/Nvidia would release source code
[05:58:28] <jmk-robot> I get a latency hit when I click on the glx window
[05:58:38] <jmk-robot> but not when I simply uncover it by moving another window
[05:58:42] <SWPadnos> the 2 generation old cards I have can do ~12-15000 frames/sec
[05:58:55] <jmk-robot> thats kind of silly
[05:59:09] <SWPadnos> that's a $50 card nowadays
[05:59:39] <jmk-robot> well, it is bedtime here
[05:59:54] <SWPadnos> oh. good point
[06:00:16] <fenn> ati/nvidia will never release source until they are dead; obviously they both violate various patents
[06:00:48] <SWPadnos> driver source would be unlikely to reveal that (unless you're talking about software patents)
[06:00:55] <fenn> software patents
[06:01:02] <fenn> isnt it all software in the end?
[06:01:16] <SWPadnos> actually, ATI has released a lot of their code already, and is supposed to release enough to do a complete driver in the next couple of months
[06:01:44] <fenn> there really needs to be some law that you can't patent an interface
[06:02:15] <SWPadnos> there should be some law that says you can't patent anything that's obvious
[06:02:18] <SWPadnos> oh wait, there is
[06:02:42] <fenn> nurse, hand me the poo flinger
[06:03:05] <SWPadnos> sorry, only the monkeys get poo flingers
[06:03:26] <SWPadnos> on that note, I think I will go to bed
[06:03:27] <SWPadnos> good night
[06:03:36] <fenn> me too.
[10:49:13] <archivist> this was just posted on a mailing list,
http://www.youtube.com/watch?v=VWn8gQ9Ykpk not cnc but good model engineering
[10:59:18] <pjm_> morn
[11:01:16] <pjm_> that is a good vid, i wonder how long that took to build
[11:02:22] <pjm_> over 3000 hours!!
[11:03:09] <archivist> the only faults I spotted was the counter looked fake and the cranks were hand filed you could tell when turning
[11:03:35] <archivist> the man needs cnc to help :)
[11:04:39] <pjm_> ah the ends of the cranks, yes u could see they were not flat
[11:04:50] <pjm_> but still a damn nice piece of engineering
[11:06:24] <archivist> yup that crank shape would be a bugger to make even cnc
[11:12:42] <motioncontrol> good morning i have on my machine two gear change on the spindle.i have scaled the value the pwmgen and the scale gain for first scale and the spindle fuction ok for the first scale.for the second scale i want change the scale value the pwmgen and scalegain , but in classicladder, because the command valve for change gear is in classicladder. is possible it?
[14:07:22] <jepler> motioncontrol: in the mazak, I believe that classicladder produces a "gear select" signal; one effect of this signal is to choose one of several scale values through a 'mux4' component (there is also a 'mesh-rpm-cmd' which is the speed commanded during a gearchange).
[14:07:59] <jepler> http://pastebin.ca/1329901
[17:25:01] <motioncontrol> good evening . i have only 2 point open for finish the retrofit on my machine.The first : spindle gear , the second tool change.OK i want resolve first the spindle gear.my machine have two gear change velocity spindle, and in my hal file i have scaled pwgen and scale gain for control first gear.For the second gear i have necessyti of change the setp hm2_5i20.0.pwmgen.03.scale 3000.0 and setp scale.0.gain 0.00445 in class
[17:25:01] <motioncontrol> ic ladder . some idea. please ?
[17:29:29] <SWPadnos> motioncontrol, look at the mux2 component
[17:29:39] <alex_joni> and wcomp
[17:29:51] <SWPadnos> you can use ladder logic to switch which mux output is used
[17:30:43] <motioncontrol> i thing use ladder logic because the command idraulic valve logic i thing is possible only use one plc
[17:35:10] <jensor> Is there a signal available that indicates that an axis is being commanded to move?
[17:36:29] <jensor> I would use this as an enable signal and reduce stepper current to only what is required to hold its position.
[17:36:42] <jensor> While an axis is not moving
[17:37:52] <SWPadnos> there are axis.#.in-position pins
[17:38:12] <jepler> I don't think that current reduction is worth the trouble.
[17:38:27] <SWPadnos> and motion.in-position, which tells you that all the joints (axes) are in position
[17:38:27] <archivist> * archivist does not reduce current
[17:38:39] <jensor> It is already implemented on the drivers that I am using
[17:38:47] <SWPadnos> current reduction may not be a good idea while machining
[17:38:55] <jensor> why
[17:38:57] <SWPadnos> it reduces the position holding force
[17:39:19] <SWPadnos> so when you're holding X in position while moving Y, you still want X to be held as hard as possible
[17:39:31] <jensor> true
[17:39:33] <archivist> I also remember issues being discussed with one of the driver boards in that respect
[17:39:41] <jepler> axis.#.in-position doesn't do what you ask for, because it is only set by the free planner; it's not set by the coordinated planner, which is what controls motor positions while running a part program. Also, in 2.2.8 it's a parameter and not a pin.
[17:40:00] <alex_joni> you would need to set the high current a couple milliseconds before you start to move
[17:40:13] <alex_joni> not at the same time as the first step pulse
[17:40:24] <jensor> Thats what i was thinking too
[17:40:31] <alex_joni> that's not supported atm
[17:40:54] <alex_joni> I mean.. you could probably hack it somehow
[17:41:01] <alex_joni> but it's so ugly I'm not going to say how ;D
[17:41:15] <archivist> in this weather you need to keep worm, dont reduce current
[17:41:21] <archivist> warm
[17:41:22] <jensor> But if the machine is just sitting there and not being used it seems like it might be a good idea to reduce poer]
[17:41:23] <alex_joni> archivist: right
[17:41:24] <SWPadnos> oh hey - shows what I get for looking at a TRUNK pin list
[17:41:27] <jensor> ]power
[17:41:32] <alex_joni> jensor: if machine is sitting there, hit F2
[17:42:09] <SWPadnos> that means "machine off", which will also turn off the amp-enable outputs
[17:42:24] <alex_joni> bbl
[17:42:26] <SWPadnos> if you're machining, then no joint is "just sitting there"
[17:42:31] <jensor> That requires my effort - Iwas thinking it could be automated
[17:42:48] <jepler> if you're obeying manufacturer current ratings then don't reduce current for the sake of the motors. It's not likely to make a difference in your electric bill either.
[17:42:58] <alex_joni> you still need to get out of bed daily, no matter how much you automate
[17:43:00] <jepler> so I don't see the benefit; and others have identified potential problems
[17:43:58] <alex_joni> (that's probably not true.. but I hope you get the point ;)
[17:44:13] <alex_joni> you could automatically cause your machine to go into machine off if idle more than 5 minutes or so
[17:44:16] <jensor> I do
[17:44:57] <jensor> Auto machine off - that might be the way to go
[17:44:59] <archivist> jensor, there is a risk of movement during the power down and up cycle, that would mean loss of accuracy
[17:45:00] <SWPadnos> heh
[17:45:06] <SWPadnos> classicladder + halui :)
[17:45:41] <jepler> yes, when you turn off the amplifiers altogether on a stepper you may lose position if the machine can pull things so far that the stepper goes into a position a full 4 steps away from where you powered off the amps
[17:45:45] <archivist> * archivist needs warm in here 55f
[17:46:45] <jensor> No not machine off just reduced power
[17:47:50] <SWPadnos> do you have any feedback (from spindle or whatever)?
[17:48:17] <archivist> I still expect movement with power reduction in steppers
[17:48:24] <jepler> to answer the original question without all the criticism, here's a component which outputs TRUE when its input changed in the last period, and FALSE otherwise:
http://emergent.unpy.net/index.cgi-files/sandbox/changing.comp
[17:48:38] <jensor> My salvaged driver boards already have the function implemented on them - just need to generate a signal for it
[17:49:06] <jensor> I'll check out that comoponent
[17:49:19] <SWPadnos> thinking through the problem, you could use something like the component jepler just wrote, but deciding when to reduce current is another matter
[17:49:30] <jepler> I linked it to siggen.0.sine and manually toggled siggen.0.frequency between 0 and 1:
http://emergent.unpy.net/index.cgi-files/sandbox/changing.png
[17:50:13] <SWPadnos> for example, there may intentionally be no motion for several milliseconds, but you probably wouldn't want to reduce power at that point
[17:50:43] <SWPadnos> and as archivist said, you may need to go out of reduced-power state before the first step pulse gets output
[17:51:16] <SWPadnos> which can't be done unless you delay the position commands by a little (since motion detection happens after the fact)
[17:59:01] <jepler> it's true; there's no guarantee of how long (if at all) this signal will be TRUE before a corresponding step pin is TRUE
[17:59:27] <jepler> and it might also go FALSE before the step generator actually emits the final step
[18:00:06] <SWPadnos> a one-shot would fix that, but it's still difficult to get around the causality problem when resuming full power
[18:02:13] <jensor> Casulty problem?
[18:02:24] <SWPadnos> causality
[18:02:44] <SWPadnos> the "changing" component tells you when something has or hasn't changed since "the last time it checked"
[18:03:11] <jensor> ok
[18:03:17] <SWPadnos> which means that there is at least one servo period that steps are being output before the changing component will notice
[18:03:26] <SWPadnos> since it looks at what already happened
[18:04:00] <SWPadnos> in fact, you want to know a servo period or two before any step will be output, so you can return the drive to full power mode before any steps are output to it
[18:04:12] <SWPadnos> unless it's smart enough to go to full power when a step arrives
[18:05:01] <jensor> But you probably should have a ms or so lead time
[18:05:21] <SWPadnos> which you can't get, unless you mess with the internals of the motion controller
[18:05:48] <SWPadnos> or you delay the output from the motion controller to the step generators (so you can peek at things before they get to the stepgens)
[18:07:55] <jensor> I've never noticed any machine movement on cycling the "Machine" toggle the motors are locked in place and don 't move
[18:08:35] <SWPadnos> if you have microstepping drivers, then they are likely to lose their position, but probably only to the nearest full step
[18:08:54] <SWPadnos> it depends on the driver as well, and whether you disable it vs. powering it down
[18:09:15] <jensor> Not using micro - I am using quadrature My drivers stay on
[18:09:41] <SWPadnos> oh quadrature, interesting
[18:31:08] <alex_joni> SWPadnos: how about creating a delay component?
[18:31:16] <alex_joni> put it between stepgens and parport
[18:31:37] <alex_joni> take the data before the delay to figure out power low/full
[18:32:07] <alex_joni> although that might cause all kinds of different problems
[18:32:12] <alex_joni> like homing timings, and so on
[18:33:06] <cradek> stepgen already knows to delay step pulses for certain timing constraints. I don't see why it couldn't also do it for this. seems like a SMOP to me.
[18:34:30] <archivist> part of the acceleration curve if low power wait till power high for n millisecs
[18:35:10] <SWPadnos> that's great for individual axes, but not for coordinated motion
[18:35:43] <SWPadnos> slow arcs could be a problem, unless stepgen starts hitting feedhold while waiting for full power
[18:36:20] <archivist> * archivist still doesnt think power down is really worth it
[18:36:23] <SWPadnos> (I'm thinking about this on a machine running G-code, which I think is a bad idea, but I think it's the intent)
[18:36:58] <cradek> does anyone know for a fact how much time is needed between full power resume and step?
[18:37:06] <SWPadnos> I bet it varies
[18:37:25] <archivist> I would assume a step time
[18:37:26] <cradek> sure, but I mean does anyone have some real data from some real driver
[18:37:31] <SWPadnos> I believe it's near zero or zero for a gecko
[18:38:18] <SWPadnos> but I don't know for sure
[18:38:33] <alex_joni> gecko doesn't have power down, does it?
[18:38:36] <dmess> hia ll
[18:38:44] <SWPadnos> hi
[18:38:52] <SWPadnos> bbl
[18:39:15] <dmess> I survived another ski trip.. yaaaa
[19:00:24] <alex_joni> nice, but waaaaaaay too pricey
http://www.reghardware.co.uk/2009/02/07/video_sony_xel_1_oled_tv/
[19:01:24] <jepler> argh, I was first excited when I read "# Open Source - The schematic, parts list, and software are all freely downloadable! " but then read in the source code "This software can be used and modified for personal or non-commercial use only"
[19:09:49] <alex_joni> hi pcw
[19:10:02] <pcw> On step driver power down: as long as your (global) power-up oneshot was triggered by any axis motion
[19:10:04] <pcw> there would be no problem with any axis losing torque during coordinated motion
[19:10:05] <pcw> Hi Alex
[19:10:38] <alex_joni> sure, that's ok.. it has to be global or none at all
[19:10:57] <alex_joni> can't lower power if another axis is moving
[19:11:06] <pcw> right
[19:11:28] <alex_joni> but the whole thing very much depends on the stepper driver
[19:12:27] <pcw> Yes, in a decent driver, it should only lower the setpoint current
[19:12:29] <pcw> so recovery should be almost instantanious
[19:12:48] <alex_joni> if it is, then it should be pretty easy to do something in HAL
[19:20:08] <pcw> (instantaneous meaning DeltaI*L/V for close to a full steps worth of current change)
[19:20:10] <pcw> probably much less than 1 ms
[19:20:50] <alex_joni> probably a couple usec's
[19:21:16] <alex_joni> if it's a microstepping driver it might not be that important
[19:21:31] <alex_joni> as the next couple of steps are still reachable directly
[19:22:13] <alex_joni> (assuming on the first 2-3 steps the driver outputs too little current to make the motor move, the 3rd, 4th microstep at full power will still make the motor move to the proper position)
[19:22:36] <pcw> Right, plus acceleration constraints..
[19:23:38] <alex_joni> there was a guy from germany that asked me for a boost signal
[19:24:00] <alex_joni> I got it from hypot'ing the ddt's (current vel's on all axes), then a ddt on that
[19:24:16] <alex_joni> and if accel is > a certain value it would turn on boost
[19:25:09] <pcw> Slowly making a servo system from steppers....
[19:25:56] <alex_joni> heh
[19:26:01] <alex_joni> yeah, encoders on them
[19:26:10] <alex_joni> boost at start, powerdown when not used
[19:28:25] <pcw> encoders just for fault detection?
[19:28:33] <archivist> apart from the risk of of demagnetising I see few problems abusing steppers as servos
[19:28:39] <alex_joni> some want to slow down when it starts failing
[19:28:55] <alex_joni> emc2 could theoretically do that (using adaptive feed rate override)
[19:29:09] <alex_joni> but you would need a very high resolution encoder on the back of the motor
[19:30:37] <pcw> right, and a fats enough servo period so you can catch is before to many electrical degrees
[19:30:38] <pcw> of lag
[19:30:43] <pcw> (fast)
[19:31:05] <alex_joni> might probably work with an 5i20 and a really fast servo period
[19:31:55] <pcw> We've driven step motors in full servo mode with 5I20 but 30 KHz sample rate
[19:32:06] <alex_joni> servo rate?
[19:32:25] <pcw> our PID sample rate
[19:32:29] <alex_joni> ah, ok
[19:32:41] <alex_joni> what do you mean by full servo mode?
[19:32:46] <alex_joni> proper PID like a servo?
[19:33:07] <pcw> Drive as a 2 phase brushless servo
[19:33:09] <alex_joni> I wonder how that works.. if you push the stepper too hard, and it starts stalling..
[19:33:20] <alex_joni> a regular PID would push it even harder to make it catch up
[19:33:52] <pcw> well the drive is alway in phase with the rotor so it just stalls like a DC motor
[19:34:23] <pcw> No different than a AC 3 phase brushless
[19:34:43] <alex_joni> ah, so special drives then
[19:34:47] <pcw> gawd my typing is awful
[19:35:06] <pcw> No but high res encoders
[19:35:14] <alex_joni> ah, ok
[19:37:15] <pcw> Don't know if EMC could do it without using DMA or something to speed up I/O
[19:37:16] <pcw> I guess 20 KHz servo loop times might be possible with a low latency system
[19:37:18] <pcw> and low I/O overhead
[19:37:40] <alex_joni> well.. there are PCs out there that get about 5-6 usec latency
[19:37:52] <pcw> That would do it
[19:38:13] <alex_joni> 05:22 < skunkworksemc> up 4 days, 2:36
http://imagebin.ca/view/tnLo77.html
[19:39:13] <alex_joni> maybe tailoring such a system to not run X, and some other services might even push things a bit further
[19:40:05] <alex_joni> skunkworksemc: you didn't say if it's i386 or x86_64
[19:41:07] <pcw> On the other hand all you really gain with servoed step motors
[19:41:09] <pcw> is a 50 pole motor so you have low speed/ high torque but poor efficiency
[19:41:10] <pcw> probably better off with a 4 or 8 pole 3 phase AC servo
[19:41:12] <pcw> ( that goal3 motherboard is impressive latency wise)
[19:43:06] <alex_joni> I think AMD's usually have very good latency results
[19:43:32] <pcw> Not mine :-(
[19:43:35] <alex_joni> my best machine (latency-wise) is a really old AMD machine (Athlon XP 1600+)
[19:43:49] <alex_joni> I ran emc2 on it with 6500 BASE_PERIOD
[19:43:59] <pcw> Wow!
[19:44:05] <alex_joni> didn't check actual parport output, but it didn't hang :D
[19:44:23] <alex_joni> I think latency results were a bit larger than that
[19:45:00] <alex_joni> at 6000 it would lockup instantly
[19:45:33] <pcw> (out of time I guess)
[19:45:34] <pcw> That reminds me, whats the highest frequency that the average EMC setup could read?
[19:45:51] <alex_joni> you mean from a parport?
[19:46:00] <pcw> Yes
[19:46:16] <alex_joni> depends what signal you're watching
[19:46:58] <pcw> Is there a frequency counter component or just the encoder counter?
[19:47:21] <alex_joni> you can use the encoder component in counter mode
[19:47:59] <alex_joni> there is a counter component
[19:48:33] <alex_joni> but you're still limited to BASE_PERIOD.. so you only sample once per BASE_PERIOD
[19:49:06] <alex_joni> at 50kHz base_period, I wouldn't trust counting for more than 30kHz or so
[19:49:23] <alex_joni> and 50kHz for base_period is kinda pushing it
[19:49:58] <pcw> OK so max freq would be base/2?
[19:50:00] <pcw> What I'm trying to decide is how far to scale down the output frequency
[19:50:02] <pcw> of this THC A-D I'm making so that if you dont have a FPGA card
[19:50:03] <pcw> it can still be used with software frequency counting
[19:50:05] <pcw> current options are 1MHz, 31 KHz, 15 KHz and 7.8 KHz
[19:50:18] <alex_joni> 15kHz sounds like a good fit
[19:50:33] <alex_joni> 31kHz for faster PC's latency wise
[19:51:06] <pcw> (I have the four option just wondered if 7.8 was to fast for a lousy MB)
[19:51:20] <alex_joni> here's a comment from counter.c:
[19:51:29] <alex_joni> The maximum count rate will depend on the speed of the PC, but is
[19:51:29] <alex_joni> expected to exceed 2kHz for even the slowest computers, and may
[19:51:29] <alex_joni> well be over 25kHz on fast ones. It is a realtime component.
[19:52:44] <alex_joni> I think 2kHz is too conservative
[19:53:13] <pcw> OK, maybe I should make the 7,8 be ~4 KHz
[19:53:27] <alex_joni> if you have 7.8kHz, and assume a base_thread of 16kHz .. that might be a bit slow for steppers
[19:53:38] <alex_joni> I don't think 8kHz is too fast
[19:54:10] <alex_joni> I mean a PC that can read 8kHz can probably step at about 8-16kHz
[19:54:19] <alex_joni> which is pretty slow for a stepper system
[19:55:06] <pcw> The faster the better in terms A-D bandwidth+resolution
[19:55:07] <pcw> (A-D is just a V-F converter) 7.8 KHz it is
[20:00:34] <pcw> Thanks Alex!
[20:00:36] <pcw> 7.8 KHz would still give ~ 7 bit resolution at 60Hz update rate
[20:00:38] <pcw> should be good enough for a THC
[20:00:39] <pcw> bbl
[20:44:49] <skunkworksemc> so - going to vegas - what are must sees?
[20:44:53] <skunkworksemc> :)
[20:49:47] <alex_joni> skunkworksemc:
http://www.visitlasvegas.com/vegas/play/attractions/index.jsp
[20:50:54] <alex_joni> or this:
http://www.buzzle.com/articles/top-10-most-bizarre-las-vegas-attractions.html
[20:52:10] <skunkworksemc> heh - thanks alex - that is funny as you being in RO :)
[20:52:17] <skunkworksemc> how are things today?
[20:52:35] <alex_joni> pretty good
[20:52:45] <skunkworksemc> latency of 6505 still
[20:52:52] <alex_joni> did you see my question earlier regarding your PC?
[20:52:53] <skunkworksemc> it is pretty warm here.
[20:53:01] <alex_joni> is it regular i386 or 64bit?
[20:53:09] <skunkworksemc> it is the livecd.
[20:53:27] <alex_joni> booted from CD?
[20:53:31] <skunkworksemc> installed
[20:53:34] <alex_joni> ah, ok
[20:53:45] <alex_joni> I would have been _really_ amazed then
[20:53:50] <skunkworksemc> heh
[20:53:59] <alex_joni> very nice like this too
[20:54:22] <alex_joni> how long do you plan on letting it run?
[20:54:41] <alex_joni> too bad the LiveCD doesn't boot on the server I have at work
[20:54:47] <skunkworksemc> heh - until I acutally need to move or reboot this thing.. No scheduel
[20:54:50] <skunkworksemc> schedule
[20:54:53] <alex_joni> at least the official Hardy doesn't
[20:55:05] <alex_joni> didn't try our LiveCD yet
[20:55:12] <alex_joni> installed 8.10 server on it though
[20:55:15] <skunkworksemc> fixable?
[20:55:28] <alex_joni> I think the desktop doesn't have proper drivers on it
[20:55:35] <alex_joni> but it fails pretty hard/early
[20:55:48] <alex_joni> I'll try to install 8.04 server then update via apt
[20:55:58] <alex_joni> wonder if the latency is any good
[20:56:09] <alex_joni> otoh, it roughly 8x larger than my CNC machine
[20:56:29] <skunkworksemc> that isn't the point..
[20:56:31] <skunkworksemc> ;)
[20:56:32] <alex_joni> when it's sitting on my table
[20:56:41] <alex_joni> if it goes into it's rack, it's about 20x bigger :D
[20:57:09] <alex_joni> I'm amazed how good this machine is.. it's about 7 years old, but still really well spec'd
[20:57:39] <alex_joni> 4 x 2.8GHz Xeon, 8G ram, 10x36G U320 HDD's
[20:58:05] <alex_joni> 1 GigE eth (on 64bit 100MHz pci)
[20:58:25] <skunkworksemc> I have some thin 1u ibm and dell servers that I need to play with.. they are in the 1.something ghz class iirc
[20:58:41] <alex_joni> this is 8U
[20:58:51] <alex_joni> and damn long
[20:59:10] <skunkworksemc> heh
[20:59:28] <alex_joni> http://eneas.juve.ro/~juve/servere/IMG_0186.JPG
[21:00:07] <archivist> sucks amps
[21:00:15] <skunkworksemc> wow
[21:00:18] <skunkworksemc> that is big
[21:00:23] <alex_joni> http://eneas.juve.ro/~juve/servere/IMG_0192.JPG
[21:01:57] <archivist> geek porn
[21:02:01] <alex_joni> http://eneas.juve.ro/~juve/servere/IMG_0202.JPG
[21:02:16] <alex_joni> 3 x 500W continuos power PSU's
[21:03:23] <archivist> I have an old Compaq here built like a battle ship but its not as good as that
[21:04:14] <alex_joni> I got two racks. one empty, the other one had 3 servers in it
[21:19:22] <skunkworksemc> heh
[21:19:39] <skunkworksemc> I think this is the first time I setup a printer on linux
[21:20:49] <archivist> * archivist wonders if printing has improved
[21:21:07] <skunkworksemc> I would have been lost without the internet.
[21:21:20] <skunkworksemc> it did bump up the latency on this thing :)
[21:25:12] <skunkworksemc> http://imagebin.ca/view/WoYdVz4.html
[21:25:58] <archivist> * archivist checks the chat window
[21:28:17] <skunkworksemc> something odd?
[21:31:05] <archivist> making sure is not the same picture :)
[21:44:20] <skunkworksemc> heh
[21:44:46] <skunkworksemc> it is actually photoshopped
[21:45:09] <archivist> cheat!!!!
[21:46:54] <skunkworksemc> the ubuntu test page is much cooler than the microsoft one..
[21:47:03] <skunkworksemc> * printer test page
[21:47:50] <skunkworksemc> * skunkworksemc is convection roasting a small turkey again.. See if it comes out as good as last time
[21:48:15] <archivist> Im hungry
[21:50:39] <skunkworksemc> so am I.. still going to bee a good 2 hours..
[21:50:47] <skunkworksemc> be
[21:51:16] <alex_joni> plasma ftw
[21:52:40] <skunkworksemc> heh
[21:52:59] <alex_joni> well.. enjoy
[21:53:04] <alex_joni> * alex_joni goes watch some telly
[21:53:25] <skunkworksemc> crispy on the outside - undone on the inside.
[21:54:06] <skunkworksemc> ok - stopping the latency test.. Yah I know.
[21:59:51] <skunkworksemc> * skunkworksemc wants to play with emc on this machine.
[22:04:46] <skunkworksemc> http://imagebin.ca/view/f0Gww77W.html
[22:04:49] <skunkworksemc> just cool
[22:15:32] <jmkasunich> I saw a car with a noodly appendages emblem on it today
[22:18:21] <skunkworksemc> http://en.wikipedia.org/wiki/Flying_Spaghetti_Monster
[22:18:23] <skunkworksemc> ?
[22:18:28] <jmkasunich> yep
[22:18:30] <skunkworksemc> heh
[22:19:16] <jmkasunich> like so:
http://en.wikipedia.org/wiki/File:FSM_Logo_on_bumper.JPG
[22:20:24] <skunkworksemc> not seen one around here yet..
[22:22:10] <skunkworksemc> how is the maze runner coming?
[22:24:56] <jmkasunich> I finally got done with chores and errands, gonna start coding again soon
[22:41:37] <JymmmEMC> LMAO
http://forums.qj.net/showthread.php?t=72284
[22:45:24] <skunkworksemc> JymmmEMC: my latency went up after ip printing.. 7833.. ;)
[22:49:21] <JymmmEMC> skunkworksemc: ouch
[22:49:26] <JymmmEMC> skunkworksemc: how bad?
[22:50:13] <jmkasunich> I think he meant it went up to 7833
[22:50:20] <jmkasunich> which is still pretty darned good
[22:50:39] <JymmmEMC> jmkasunich: If that's true...
[22:50:57] <JymmmEMC> skunkworksemc: lat < 10K.... A55hole!
[22:51:04] <jmkasunich> "up after printing.. 7833.. ;-) "
[22:52:01] <JymmmEMC> That's worse that me teasing SWPadnos regardign bandwidth
[22:59:27] <JymmmEMC> My gf got me this hand-held laser lightshow thingy. It has a laser pointer directed at two mirrors that are atteched to motors that spin. The mirrors are ever so slightly angled (maybe 83 degrees) from the shaft of the motors. But the whole thing still puts out various patterns... like spiralgraph if you rememebr that and combinations of ovals and triangles.
[23:20:37] <skunkworksemc> my internet is flakey
[23:20:37] <skunkworksemc> logger_emc: bookmark
[23:20:37] <skunkworksemc> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2009-02-07.txt
[23:21:05] <alex_joni> well.. at least the latency is ok, can't have it all
[23:22:05] <skunkworksemc> I am not blaming my internet connectivity on this motherboard... ;)
[23:24:01] <alex_joni> PEBCAK then?
[23:24:50] <skunkworksemc> I went outside and tried to hook into a few of the neighborhood
[23:26:01] <skunkworksemc> wireless networks and same thing.. wasn't just me
