#emc | Logs for 2009-04-24

[03:23:07] <tomp> tomp is now known as tomp3
[03:26:15] <tomp3> if emc can be pushed to update the servos at 5khz... well, a few of the 'high speed/hard milling' controls are claiming 0.5mS servo update periods!
[03:26:16] <tomp3> thats pretty cool for emc, even at the 'nominal' 1khz, thats 1mS emc vs 0.5mS big time control.
[03:26:54] <cradek> I bet 5kHz is easy with the pci cards
[03:29:20] <Valen> dunno if you can do it easily and still have linux running though
[03:29:29] <eric_unterhausen> I'm pretty sure I was doing 1khz with an ISA card
[03:30:40] <Valen> its not so much the card update that concerns me, its running a task on the host at that rate and still having it actually happen somewhere near the time its sposed to rather than going in fits and starts
[03:31:04] <Valen> 1Khz is already pretty fast for an interrupt type thing in an X86 type machine
[03:31:18] <cradek> Valen: guess you haven't tried it then? it works great.
[03:31:29] <Valen> you tried it at 5Khz?
[03:31:53] <Valen> If they did the thing I said and put the servo loop in the FPGA you could have 20Khz without a problem ;->
[03:31:57] <cradek> many emc2 users generate step pulses at 50-75kHz interrupt period
[03:32:04] <cradek> by many, I mean almost all
[03:32:11] <cradek> 5kHz is nothing at all
[03:32:26] <Valen> funky
[03:32:42] <Valen> are those steps generated by the PC or is it hardware though?
[03:32:46] <cradek> pc
[03:32:55] <Valen> so the CPU is flipping bits?
[03:33:00] <cradek> yes
[03:33:13] <Valen> nifty
[03:33:15] <cradek> turn step line on, turn step line off => one step
[03:33:30] <eric_unterhausen> doing the servo loop is a little prettier
[03:33:35] <Valen> I am downloading emc at the moment
[03:33:46] <Valen> ETA 53 minutes
[03:33:52] <Valen> 45% complete
[03:34:14] <Valen> and I am getting some linear scales here in an hour or 2
[03:34:16] <eric_unterhausen> the big cnc guys have been using proprietary hardware so it's not very fast
[03:34:42] <Valen> You don't need to be paticularly fast doing it in hardware
[03:34:55] <cradek> eric_unterhausen: it's true that EMC was doing 1kHz servo updates on ISA hardware 10 years ago
[03:35:14] <eric_unterhausen> pretty sure they aren't using hardware
[03:35:31] <Valen> In hardware you could have it run at the encoder rate
[03:35:37] <Valen> really easily
[03:36:03] <cradek> yes but that's not necessarily a win
[03:36:11] <cradek> the closer you get to the encoder rate, the more quantization you get
[03:36:15] <eric_unterhausen> cheaper to use a pc
[03:36:57] <cradek> "did not get an encoder count this time" => "so how fast are we going then?" => "zero, I guess"
[03:38:42] <eric_unterhausen> encoders are asynchronous, probably want to run at 5khz or something like that
[03:39:13] <Valen> I was thinking run it in reverse
[03:39:24] <Valen> "oh we just got an encoder pulse"
[03:39:27] <cradek> I'm sure the ideal servo cycle rate is "it depends" but clearly faster is not always better
[03:39:32] <Valen> how long was it since we got the last one?
[03:39:44] <eric_unterhausen> I was thinking that control theory suggests a constant sample rate :)
[03:39:47] <Valen> ahh that means our velocity is X and our position is U
[03:40:14] <Valen> our target X and Y are A and B, so adjust something
[03:40:24] <cradek> eric_unterhausen: that's sure the normal way, but maybe you could do it Valen's way too
[03:40:34] <cradek> pid is more complex (well, everything is more complex)
[03:40:58] <Valen> you still run a PID loop, you just base it on a different input
[03:41:00] <cradek> there's have to be a benefit to offset the new complexity - not sure what it would be
[03:41:11] <Valen> faster loop control i spose
[03:41:18] <eric_unterhausen> yeah, researchers went nuts with that sort of control in the past
[03:41:43] <Valen> Its actually not any more complex, in terms of hardware implementation its actually easier in many respects
[03:42:01] <eric_unterhausen> you would then have to sample a clock
[03:42:23] <Valen> measuring and resetting a counter is really easy
[03:43:12] <Valen> much easier than meshing synchronous and non synchronous events in a standard setup
[03:43:13] <eric_unterhausen> pid doesn't work anymore
[03:43:24] <Valen> it does
[03:43:49] <Valen> you just need to keep a history of past "events"
[03:44:08] <Valen> you still have a constant axis, its just position rather than time
[03:44:47] <eric_unterhausen> f=ma doesn't work anymore :)
[03:45:11] <Valen> it does, you just need to thin a little more to work out what a is
[03:45:15] <Valen> think
[03:45:28] <Valen> t is a variable rather than a constant
[03:45:32] <eric_unterhausen> I did, you are solving a problem that is uninteresting
[03:45:51] <Valen> i mean the controller needs to do more work
[03:46:10] <cradek> well I think it's interesting to think about, but it is definitely a solution looking for a problem
[03:46:17] <Valen> If your software is properly written for PC you need to account for the fact that your time samples arent perfect anyway
[03:46:31] <eric_unterhausen> they are close enough
[03:46:55] <Valen> the latency and jitter in latency means that your 1Khz isnt actually 1ms from pulse to pulse
[03:47:06] <eric_unterhausen> I control a fatigue machine with a pc, it's open loop unstable
[03:47:17] <cradek> but it's self correcting
[03:47:21] <Valen> if its close enough then whats the benifit to running at 5khz?
[03:47:33] <eric_unterhausen> cradek, in the sense that you crush the specimen?
[03:47:43] <cradek> what
[03:47:46] <cradek> I'm lost
[03:47:51] <Valen> he means the 1ms is correcting
[03:47:58] <Valen> its always going to be around 1ms
[03:48:06] <eric_unterhausen> sry
[03:48:07] <cradek> a pid loop with imperfect but close time slices is self-correcting
[03:48:16] <Valen> (on average though its going to be 1.00 something ms)
[03:48:46] <Valen> the "best" way would be to integrate a variable time into the PID variables
[03:48:52] <eric_unterhausen> the pc makers seem to finally have gotten their act together, this pc has 6 microseconds latency
[03:49:00] <Valen> what is it?
[03:49:06] <eric_unterhausen> I forget :)
[03:49:10] <cradek> ha
[03:49:12] <Valen> bastard!
[03:49:30] <eric_unterhausen> dual core amd something something
[03:49:30] <Valen> i want some nice machines for my mill and lathe conversion
[03:49:32] <cradek> the P3s I use almost always have < 10us
[03:50:18] <Valen> I'm going to try some via min-itx boards i have laying about
[03:50:30] <cradek> Valen: yeah just try various machines from your junk pile, some will work well, others not so well
[03:50:34] <Valen> or should i use the old dual Xeon i have sitting around ;->
[03:50:42] <eric_unterhausen> I haven't tested all my p3s, but the one I have attached to my mill has almost 40microseconds
[03:50:44] <cradek> why not try it.
[03:50:58] <Valen> is there a SMP kernel for EMC2 floating about?
[03:51:04] <eric_unterhausen> an early P4 is going to suck, intel never should have released that dog
[03:51:37] <Valen> only down side to the xeon is it needs a really good 600W supply to run it (and it sounds like a jumbo jet)
[03:51:48] <Valen> it pops cheap 400W supplies after about a week
[03:51:49] <cradek> Valen: you can build one. several people have but they're less likely to run on any old machine. they're more custom than the uniprocessor one we use.
[03:52:09] <eric_unterhausen> I wish someone would make me feel better about the atom
[03:52:16] <eric_unterhausen> I could use the space
[03:52:18] <Valen> whats bad about it?
[03:52:28] <eric_unterhausen> I don't trust it
[03:52:37] <Valen> I am going to be sticking the liveCD into an atom board today as well
[03:52:39] <eric_unterhausen> seems like it should stink at real-time
[03:53:01] <cradek> goodnight
[03:53:05] <eric_unterhausen> cheap, integrated video
[03:53:11] <geo01005> There is a SMP build as of the last couple of days, for the atom.
[03:53:12] <Valen> catchya cradek
[03:53:24] <Valen> oh hey know any sources for old DC servo motors?
[03:53:31] <eric_unterhausen> ebay
[03:53:45] <Valen> they seem to all be gearmotors atm :-<
[03:54:00] <eric_unterhausen> can't unbolt the gearbox?
[03:54:15] <Valen> probably not if you want some torque
[03:54:38] <Valen> wrt the atom, the onboard video is intel, so open source drivers, that is the main thing
[03:55:12] <eric_unterhausen> that is good news
[03:55:27] <Valen> should give good performance really, they are one of the best supported drivers available
[03:55:58] <geo01005> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EMC_With_Custom_Kernel
[03:58:16] <Valen> somebody else was running a SMP one and said they had "ok" if not awesome results on an atom
[03:58:31] <eric_unterhausen> JMK set it up
[03:58:55] <Valen> an atom board is ~$100 anyway so just try it
[03:59:00] <Martyn> He ran emc2 on an atom? 270? 280? or one of the new 5xx series?
[03:59:14] <Valen> worst case you got a nice media player front end ;->
[03:59:15] <geo01005> I think 330.
[03:59:28] <geo01005> I have seen the 330 around for like $65
[03:59:43] <Valen> $100 Au ;->
[03:59:45] <Martyn> My son bought me nettop based on the Atom which I'm using now. I just installed Ubuntu 9.04 on it
[03:59:48] <Valen> bastards
[04:00:13] <Martyn> Well, better $100 Au than $100 Pb, or $100 Hg
[04:00:17] <Martyn> *snerk*
[04:00:25] <Martyn> Nothing wrong with gold :)
[04:00:37] <Valen> Au meaning australian ;-P
[04:00:40] <eric_unterhausen> 330 is 81$ from newegg
[04:00:47] <eric_unterhausen> that's the one JMK has
[04:00:49] <Martyn> Valen : I know. I'm teasing you.
[04:01:11] <Valen> I want to know how well it'll work on an eee 701 with the USB controller
[04:01:18] <Valen> they are ~$300 Au
[04:01:36] <eric_unterhausen> can you even get the newer atoms?
[04:01:40] <Martyn> Is there any reason why I can't use Ubuntu 9.04 with emc2, if I take pains to go through the torturous process of applying the rtai patches?
[04:01:49] <eric_unterhausen> no reason at all
[04:02:06] <eric_unterhausen> except for library issues, if any
[04:02:18] <Martyn> Look at me, two weeks ago, I didn't know a linux kernel from the end of my ass... now I've learned how to compile the kernel and apply patches. Imagine what I'll learn next week.
[04:02:28] <Valen> lol
[04:02:44] <eric_unterhausen> writing kernel modules?
[04:02:45] <Martyn> Now if I can figure out how to make my videos upload to YouTube, I'll be set!
[04:03:04] <pcw_home> the 330 ITX motherboard in in database on the wiki
[04:03:06] <pcw_home> It has good Latency numbers
[04:03:12] <Martyn> eric_unterhausen : Only if kernel modules can be written in python, basic, COBOL or forth.
[04:03:18] <eric_unterhausen> I know, but I don't believe those numbers :)
[04:03:28] <Martyn> eric_unterhausen : Or C
[04:03:33] <eric_unterhausen> C works
[04:03:53] <Martyn> And of course, they are basically C code .. but I'm 54, and frankly I have no interest in writing kernel drivers.
[04:04:06] <Martyn> I'd rather be maintaining the machines, darnit.
[04:06:02] <Martyn> How, in Linux, can I tell what processor a machine has?
[04:06:11] <eric_unterhausen> uname -a would be a good start
[04:06:13] <Martyn> Is there something in the gui like "system" in Windows?
[04:06:27] <Martyn> eric_unterhausen : I assume at the console?
[04:06:30] <eric_unterhausen> yes
[04:06:41] <Martyn> i386?
[04:06:42] <Valen> cat /proc/cpuinfo
[04:06:44] <eric_unterhausen> nvm
[04:07:05] <Valen> more than you ever wanted to know about your CPU
[04:07:07] <eric_unterhausen> Martyn, is that an emc install?
[04:07:51] <Valen> model name: Intel(R) Core(TM)2 CPU 4400 @ 2.00GHz
[04:07:51] <Valen> is what it says about my current desktop
[04:09:02] <Martyn> Ah, this machine has an atom 330 with 1M of cache
[04:09:06] <Martyn> that is a nice processor, I think.
[04:09:17] <Valen> lightweight but pretty decent
[04:09:22] <eric_unterhausen> pretty large cache
[04:09:36] <Martyn> my son installed Leopard on it, and it works well
[04:09:41] <Valen> yeah they did that to help with power consumption i believe
[04:09:49] <Martyn> it feels peppier than a Mac Mini
[04:10:09] <Valen> shouldn't do i don't think?
[04:10:09] <eric_unterhausen> how do they determine the bogomips?
[04:10:18] <Valen> unless this one is a solid state disk
[04:10:28] <Valen> BogoMips (from "bogus" and MIPS) is an unscientific measurement of CPU speed made by the Linux kernel when it boots, to calibrate an internal busy-loop.[1] An oft-quoted definition of the term is "the number of million times per second a processor can do absolutely nothing."
[04:10:43] <Valen> http://en.wikipedia.org/wiki/BogoMips#How_are_BogoMIPS_computed.3F
[04:12:35] <Martyn> The Dell that's powering the tormach is a Dell Precision T7500
[04:12:49] <Martyn> Two 2.5Ghz xeon processors, but I need to install more RAM on that machine
[04:13:08] <Martyn> I was wondering what a bogomip was...
[04:13:09] <Martyn> thanks
[04:16:03] <eric_unterhausen> we always install matlab and run bench to see which computer is faster
[04:17:31] <Valen> whats the latency like on that dell?
[04:18:37] <Martyn> Valen : Almost nonexistent
[04:18:52] <Valen> which translates to a number of?
[04:18:54] <Martyn> Valen : I got something a couple times when trying to run the latency test .. a "segmentation fault"
[04:19:00] <Valen> just so i can compate
[04:19:07] <Valen> compare
[04:19:07] <tomp3> i was talking about servo update rates of 5khs, no steps, and by servo update i mean wth am i, wth should i be, get the new Voltahe to the amp ( 5000 times a second )
[04:19:09] <Martyn> my son had to do something to slow down the computer
[04:19:17] <tomp3> and i was told emc could do it
[04:19:26] <tomp3> tho not by a dev
[04:19:28] <Valen> lol a divide by 0 might cause a seg fault
[04:20:13] <eric_unterhausen> tomp3, I don't think there is any problem
[04:20:15] <Valen> can you spec a different update rate easily?
[04:20:20] <eric_unterhausen> yes
[04:20:28] <Valen> try it and see what happens
[04:20:29] <tomp3> eric. me neither
[04:21:03] <Martyn> max jitter 9248
[04:21:30] <Valen> Hmm i know you can have issues with harmonics and normal servo systems, I wonder if my "no fixed time" system would suffer from that
[04:21:31] <Martyn> max interval 31446
[04:21:48] <Valen> i spose an encoder update rate might hit that harmonic frequency still :-<
[04:22:40] <Martyn> the other two are max interval 1.0ms 1003151
[04:22:57] <Martyn> and 1.0ms jitter 7170
[04:24:18] <Valen> that looks pretty good i thinks
[04:25:01] <Valen> compared to http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Latency-Test
[04:28:56] <Martyn> none of the processors on that page are Xeons, are they?
[04:30:24] <tomp3> can you move the hamonics on a machine? like add mass? and how to do harmonics tests? i remember some graphs and code that varied a sinus fed to drive, from slow to fast while it watched for the harmonic area.
[04:31:12] <tomp3> a freind has a mill in australia, that gets a problem mid sped range ( artifacts in mold surface being hard milled )
[04:31:26] <eric_unterhausen> sine sweep should do it
[04:31:42] <tomp3> yeh, but does 'bode plot' ring a bell?
[04:31:50] <eric_unterhausen> yes
[04:32:13] <tomp3> ding!
[04:32:44] <eric_unterhausen> there are sine sweeps that have constant amplitude, I'm forgetting the name
[04:33:32] <tomp3> and the bode plot told yo a characteristic about your machine, in general, for emd, you wanted the harmonic to be above 200hz hopefully above 400hz ( meant your machine was stiff )
[04:33:43] <tomp3> yes constant amplitude, frquency varied
[04:34:07] <eric_unterhausen> this is a system id technique
[04:34:21] <eric_unterhausen> I suppose I could go read my thesis, but what's the fun in that
[04:37:07] <tomp3> looks like this http://www.danahermotion.com/website/common/download/document/Controls_Toolkit_single_pgs.pdf
[04:38:12] <eric_unterhausen> that's an obfuscated plot if I've ever seen one
[04:39:07] <tomp3> The BodeTool is designed to help the machine builder analyze and compensate for
[04:39:09] <tomp3> machine resonances
[04:39:49] <tomp3> ok, the nyquist plot identifies it as a pole
[04:40:37] <eric_unterhausen> bode tells you if it's a pole too
[04:41:13] <eric_unterhausen> depends on what the phase is doing
[04:43:53] <tomp3> wah! freebie !http://www.ece.utah.edu/~bodson/acscr/ book on adaptive controls
[04:45:40] <Valen> can you run steppers with encoders?
[04:45:53] <eric_unterhausen> I love control theory, but it was kinda killed as a research topic
[04:46:19] <Valen> in EMC
[04:46:40] <eric_unterhausen> Valen, there is a thread about that at cnczone
[04:46:45] <eric_unterhausen> probably in the wiki
[04:49:50] <pcw_home> You can run steppers with encoders, basically with FOC
[04:49:51] <pcw_home> needs high resolution encoder and high (say 30 KHz) sample rate
[04:50:49] <pcw_home> (running them as 2 phase AC Servo)
[04:52:08] <Valen> we are putting linear scales on the axis of the mill
[04:52:23] <Valen> and using a "0" backlash setup with acme screws
[04:52:35] <Valen> steppers seem more available 2nd hand in the right sort of size
[04:52:43] <eric_unterhausen> linear scales don't match too well to the resolution of motors
[04:52:51] <Valen> so i'm wanting to drive them like you would a DC servo
[04:53:23] <tomp3> i think you need to check the logs, i seem to recall, yes you can use steppers and encoders, but also, no you cant correct , just fault
[04:53:53] <Valen> yeah thanks thats what i thaught
[04:54:26] <eric_unterhausen> did you check cnczone?
[04:54:29] <pcw_home> We've driven Steppers as full servo, its just a 2 phase AC servo
[04:55:18] <tomp3> did it cog at low speeds?
[04:55:37] <pcw_home> No, smooth as glass
[04:55:49] <tomp3> ! cool
[04:55:58] <tomp3> then it no longer steps
[04:56:28] <tomp3> ( i come from very very very low speed arena, edm, like rpm means revs prer month
[04:56:37] <pcw_home> No its Field Oriented Control
[04:56:46] <tomp3> (googling now)
[04:56:47] <pcw_home> (sine drive)
[04:57:31] <tomp3> vector
[04:58:25] <pcw_home> No real advantage over 3 phase PM AC servo
[04:58:25] <eric_unterhausen> did you steal that idea from Marriss?
[04:58:26] <pcw_home> except maybe more torque at low speeds do the the
[04:58:28] <pcw_home> large number of poles
[04:58:35] <pcw_home> No
[04:58:48] <eric_unterhausen> supposed to be a smiley, sorry
[04:58:55] <tomp3> cool http://www.maccon.de/FTPROOT/Field-Oriented-Control.pdf
[04:59:27] <pcw_home> Our SoftDMC firmware as a closed loop stepper option
[04:59:34] <pcw_home> (has)
[04:59:51] <tomp3> peter c? like microstepping is replaced by true sinus?
[05:00:16] <tomp3> hello
[05:00:38] <pcw_home> Well as good as the table/DAC resolution,,,
[05:03:07] <tomp3> i see, any dac would be steppy to some small degree, just get the bits up and you wont notice the jaggies
[05:03:17] <pcw_home> You can also run 3 phase PM motors as microstepped step motors
[05:05:23] <tomp3> never seen one, but i can understand the drive technique
[05:06:08] <tomp3> haha that last pdf originated at Copley ( motor drivers )
[05:07:30] <pcw_home> I have a german one made to run from 320V B+
[05:07:31] <pcw_home> about 5" diamter by 6" long
[05:07:33] <pcw_home> We are going to try and drive it from our 8I20
[05:09:40] <tomp3> ever run a moog/pegasus valve? got some hydraulics here , its really a 20ma device, but analog
[05:10:04] <pcw_home> Its pretty easy to generate good sine wave currents at slow speeds with step motors
[05:10:06] <pcw_home> it all goes to hell when you get faster though (Were messing with a stepmotor controller ATM)
[05:10:53] <pcw_home> Ive heard of those, is that for running a double acting cylinder?
[05:11:01] <tomp3> maybe you dont need the bt rez at higher speeds ( gear shift 'down' to less bits)
[05:11:37] <tomp3> yes it is an amplifier itself, a 'spool' valve moves and lets high presure flow into left or right side of dbl cylinder
[05:12:06] <tomp3> you get loads of torque, cheap ( usually messy )
[05:12:22] <tomp3> but its lke a voice coil
[05:13:12] <tomp3> make that gear shift up, as i imagine the lsb's are chucked
[05:13:29] <pcw_home> Just need to keep electrical current phase aligned with rotor,
[05:13:31] <pcw_home> resolution will determine how many steps of drive change you will get
[05:13:33] <pcw_home> with 1/4 step (90 electrical degrees)
[05:14:39] <pcw_home> What are frequency response does the valve have?
[05:15:28] <tomp3> cool, sorry, back to orcad, board designer screwed me again, got a db15 wired in mirror
[05:17:21] <pcw_home> Oops.. One of our first PC/104 cards we made, we reversed one of the bus connectors
[05:17:23] <pcw_home> sold some of the reversed cards to a customer tha made the same mistake on their motherboard :-)
[05:17:53] <pcw_home> bbl
[05:18:58] <LawrenceG> tomp3, hey.. moog valves... i designed a servo positioning board that used temposonic linear transducers and mooog valves for position bandmills in sawmills
[05:19:41] <LawrenceG> they were nice, but $2500 each for the valve 20 years ago
[05:20:50] <LawrenceG> we had some high speed positioners that moved slabs of wood sideways at 60ips.... very exciting
[05:23:43] <LawrenceG> hi pete!
[05:25:31] <tomp3> LawrenceG: cool, (looking up temposonic scales ) . i used moog on elox's and pegasus on euro brand edm's
[05:25:41] <tomp3> same animals
[05:26:33] <LawrenceG> the sensors mounted inside the rod of the hydraulic cylinder and used a sonar like technology to read the position of a ring magnet
[05:27:07] <tomp3> cool, looking up freq response of moogs ( less response of hyd cyl ;)
[05:27:10] <LawrenceG> opps.... not sure what dcc chat was supposed to do?
[05:27:28] <tomp3> i got booted from dcc chat by local sys
[05:27:38] <tomp3> so went back here
[05:28:25] <LawrenceG> we used a 1ms servo cycle...
[05:29:25] <tomp3> SE3 servo cartridge 170Hz http://www.moog.com/home/search/-/q_servo%20valve%20electronics/start_20/
[05:29:31] <LawrenceG> most of the systems had 1000's of pounds of mass, so valve response wasnt really an issue
[05:30:11] <tomp3> right, these were big casting too, but had to be quick, not a high top end, but quick
[05:30:30] <LawrenceG> seems to me we used a 50mhz clock on the sensor and got about 0.001" resolution in 1ms
[05:30:39] <tomp3> argh, get back to orcad! soorry bye
[05:30:48] <LawrenceG> cheers
[06:00:49] <Valen> pcw_home, you cant use softdmc with emc though can you?
[06:06:00] <Valen> DCC char is direct client to client
[06:06:08] <Valen> it bypasses the IRC network
[08:57:20] <roh> hmmmmm... i now have an dso on the Xstep and Xdir lines
[08:58:33] <roh> seems the pulses are negative logic with 3.4 usec length and with a space of 84.6 used inbetween
[09:14:44] <roh> after a direction change there are 30 usec delay before the next pulse
[09:16:07] <roh> hm.. i can get it low as 27.1usec
[09:22:37] <roh> and in this one case i could properly capture 30msec delay after a pulse to a dirchange
[09:22:55] <alex_joni> msec?
[09:45:59] <piasdom_> g'mornin all
[09:54:00] <roh> yeah.. it moves
[09:54:09] <roh> syl bf20 with emc 2.3.0
[09:54:13] <roh> syil
[09:56:37] <Valen> anybody used encoders on a parallel port?
[09:57:00] <roh> i wish.. only steppers and flying blind
[09:58:38] <Valen> just looking at a DRO type application first up
[09:59:20] <archivist> Valen, parport only has a limited speed
[09:59:32] <archivist> some are using it though
[09:59:37] <Valen> what sort of speed can it work at?
[09:59:56] <Valen> think it'd work to read the linear scale without dropping counts?
[10:00:27] <archivist> it cant handle counts to is limited to the period emc is running at
[10:18:20] <Valen> just got my linear encoders and checked them on the scope, they are quadrature encoded so thats nice
[12:21:13] <alex_joni> Valen: you can probably expect 20kHz count rate or so
[12:28:20] <Valen> just tried to boot the livecd on my atom, no joy :-<
[12:33:53] <alex_joni> Valen: what's the error?
[12:34:22] <alex_joni> if you get some error messages like these: "ata1.00: revalidation failed (errno=-5)"
[12:34:32] <alex_joni> then try adding 'irqpoll' to the boot parameters
[12:40:30] <alex_joni> hi pcw_home_
[13:07:53] <steve_stallings> steve_stallings is now known as steves_logging
[13:15:46] <pcw_home_> Hi Alex
[13:16:00] <alex_joni> pcw_home_: just chaging my status from work to home ;)
[13:16:02] <alex_joni> see you later
[13:18:16] <ehj> Joyhandle question. Is there a reason why it was not included in 2.3, or in fact does not appear to be in trunk either?
[13:18:50] <Optic> moo
[13:18:53] <Optic> moo
[13:20:25] <tomp> tomp is now known as tomp3
[13:28:51] <roh> hmm.. what kind of gcode iss ngc?
[13:32:55] <pjm__> Nist G-Code isnt it?
[13:34:34] <archivist> RS274NGC is the standard its based on
[13:35:18] <archivist> http://www.linuxcnc.org/handbook/RS274NGC_3/RS274NGC_3.html
[13:39:52] <roh> archivist are there converters which take what comes out of CAMExpert (the cam module for qcad)
[13:39:54] <roh> ?
[13:41:21] <archivist> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Cam is our main collection of routines etc
[13:42:12] <Optic> if CAMExpert is as good as qcad, it should be good
[13:42:24] <Optic> i have had nothing but success with qcad
[13:43:00] <roh> any ideas how to use step, iges, dxf or so? heekscad (3d cad) does that
[13:43:29] <Optic> i've found most of the free/oss CAM conversion stuff to be pretty bad
[13:44:08] <archivist> roh, see http://www.ribbonsoft.com/camexpert/manual_reference/chapter05.html#1 to set a suitable setting for emc
[14:31:00] <tomp3> ngc is Next Generation Controller . was this before or after the startrek series of similar name ;)
[14:31:38] <tomp3> proctor didnt act like a trekky
[14:31:45] <cradek> don't be silly, that's NCC
[14:31:45] <steves_logging> steves_logging is now known as steve_stallings
[14:33:29] <tomp3> ok, i had to look that up, apparently that was the letters in the ships name
[14:33:49] <tomp3> i meant start trek the next generation
[14:37:23] <JymmmEMC> Star Trek TNG
[14:37:49] <JymmmEMC> You guys would suck at being a Trekkie =)
[14:38:52] <tomp3> spose so
[14:39:02] <JymmmEMC> cradek: What DONT you like about the thing you use to edit/write your website?
[14:40:26] <cradek> I had to dink with it a lot to get it to display correctly on old IEs. fortunately that is in the past and now even IE does CSS.
[14:40:39] <JymmmEMC> OK, whats the name of the creature that kept multiplying so much that it basically took up ever space on the ship?
[14:40:45] <Valen> tribble
[14:40:45] <cradek> other than that disturbing memory, it's fine
[14:40:56] <JymmmEMC> Valen: +++++
[14:41:24] <JymmmEMC> cradek: Anything else? Feature?
[14:42:54] <cradek> sorry, I don't understand. are you asking if it is missing a feature I want?
[14:43:28] <JymmmEMC> cradek: Sure, or anything I wish it did/didnt do this or that
[14:43:59] <cradek> I know many people think they want to allow blog comments, and it doesn't do that as-written. I don't want that, though, so it's not a missing feature for me.
[14:44:19] <JymmmEMC> cradek: LOL, same here =)
[14:44:34] <cradek> so it's just fine... simple to use - I spend virtually zero time maintaining it.
[14:45:05] <JymmmEMC> cradek: What about lets say a thumbnail previewer for inserting pics?
[14:45:38] <cradek> yeah it does not have any kind of photo album browsing thing.
[14:46:00] <JymmmEMC> cradek: Simple wysiwyg editor?
[14:46:07] <jepler> ha ha ha
[14:46:39] <jepler> (if I may speak for cradek, that is a "do not want or need" feature)
[14:46:53] <cradek> JymmmEMC: not important to me. it uses markup which is the natural way for me to write text for a website.
[14:46:56] <archivist> for an odd web interface http://www.stevenson-engineers.co.uk/files/index.php but different
[14:47:06] <JymmmEMC> cradek: It doesn't index and provide site-navigation, does it?
[14:47:40] <cradek> no, there's no kind of index - only search
[14:48:36] <jepler> it is a very basic system
[14:48:42] <jepler> it sounds like you want something a lot less basic
[14:49:03] <JymmmEMC> cradek: ok, thanks. If you think of any basic functionality it should have, let me know.
[14:49:09] <JymmmEMC> jepler: me?
[14:49:33] <jepler> JymmmEMC: image processing, wysiwyg, and so on
[14:49:47] <cradek> are you looking for a project to improve, or trying to choose software for a new site?
[14:51:13] <JymmmEMC> jepler: No, I'm writing a straight forward intuitive one. Including the basic functiality to bring up any website online and "just add content" in a matter of minutes.
[14:51:33] <cradek> oh ok, I see what you're asking then.
[14:51:43] <JymmmEMC> Knowledge of html implied
[14:52:10] <archivist> yetanothercms.php ?
[14:52:11] <cradek> what I want probably doesn't match what most people want...
[14:52:17] <cradek> heh
[14:52:20] <JymmmEMC> I've looked at a dozen CMS'es thus far, and they all go WAY WAY overboard and you just can't get anything done.
[14:52:55] <cradek> yeah, aether isn't from that world.
[14:53:01] <cradek> (probably why nobody uses it)
[14:53:07] <archivist> never use an available wheel when you can invent a new one
[14:53:25] <JymmmEMC> cradek: Well, it is in part. Instead of file based, db based.
[14:53:27] <jepler> you'd better be prepared to learn a lot about wheels if the one you invent is to be any good
[14:53:35] <steve_stallings> steve_stallings is now known as steves_logging
[14:54:26] <archivist> I invented my own wheel for archive type data :)
[14:54:27] <JymmmEMC> jepler: I've been thinking about this for 5+ years, now it's just time to DO IT!
[14:56:04] <archivist> hide features and allow clicky additions in a control panel
[14:56:22] <cradek> JymmmEMC: it might be too late for simple CMSs. The new way is to give your content for free to a few big popular sites who use it to make money for themselves.
[14:56:59] <cradek> they do this in exchange for the simplicity they present to users who don't want to figure out how to set up a CMS.
[14:57:11] <archivist> Im just getting payback on my archive site, it can be done
[14:57:14] <JymmmEMC> cradek: This isn't for revenue generating, just site management.
[14:57:50] <cradek> maybe I wasn't clear - I meant that I think very few people want a simple CMS now.
[14:57:52] <JymmmEMC> cradek: All the kiddies just scrap content from other sites.
[14:58:20] <JymmmEMC> cradek: Ah, well this isn't for them =)
[14:58:39] <JymmmEMC> scrape
[14:59:01] <archivist> it better have no drupal tendencies
[14:59:03] <cradek> either way, I want to see what you come up with - sounds like you have some of the same goals I do.
[14:59:31] <archivist> we get far to many sql questions from that
[15:00:03] <JymmmEMC> cradek: Ok
[15:00:57] <JymmmEMC> My own REAL issue is the design for use with CSS layout - I hate mucking with css crap across all browser for layout and such.
[15:31:58] <Valen> I made a "cms"
[15:32:03] <Valen> its reeeal simple
[15:32:17] <Valen> theres 2 php pages and a database
[15:32:35] <cradek> database != simple
[15:32:55] <Valen> lol its really simple its already there as part of the LAMP stack
[15:32:58] <JymmmEMC> sure it is
[15:33:06] <Optic> i'm hungry for lunches
[15:33:15] <Valen> www.vapourforge.com for an example
[15:34:25] <archivist> I made my "search" fast enough that it can be used for links
[15:34:59] <Valen> I'm on my 4th machine running the live cd
[15:35:26] <Valen> best one i have found has a jitter of 7000 or so and about the same added as the max values
[15:36:05] <archivist> JymmmEMC, learn inverted indexes for that trick (sphinx etc)
[15:36:34] <Valen> although this latest one with an nvidia card has about 6000 with jumps when it accesses the cd rom
[15:38:43] <Valen> I wonder if there are any benifits to be had running EMC from a ram disk
[15:39:31] <Valen> mainly to negate pesky disk accesses when your doing something important
[15:43:22] <eric_unterhausen> it's not significant due to rtai
[15:49:21] <Valen> it is if its half way through a disk access when it wants to do some RT stuff
[15:49:36] <Valen> 's why there is jitter and latency in the first place
[15:51:31] <cradek> have you found that disk IO makes a large difference in latency on your machine?
[15:55:20] <Valen> on the one i just tested it did
[15:55:31] <cradek> how much?
[15:55:40] <Valen> running glxgears with the open source driver it was sitting at about 7000 jitter
[15:55:55] <Valen> md5sum /dev/scd0 jumped it up to 2400
[15:56:38] <cradek> do you mean 24000?
[15:57:50] <cradek> wonder if disk does that too, or if it's just the cd.
[16:00:13] <Valen> same controller
[16:00:19] <Valen> that machine has no physical disk
[16:00:35] <Valen> RTAI prolly cant interrupt a disk access
[16:00:45] <Valen> stuff in the hardware device driver layer
[16:00:52] <crice> Network access also does it. Latency tests done via a VNC connection will be much larger.
[16:30:13] <pcw_home_> Network latency may be due to PCI bus blockage by bus master (DMA) transfers
[16:30:15] <pcw_home_> from Ethernet/WIFI (a 1K packet block transfer would block for ~10 uSec)
[16:30:16] <pcw_home_> Systems with PCIE Ethernet should fare better
[17:10:31] <eric_unterhausen> you could almost say that the only reason for rtai is to help with disk access latencies
[17:10:41] <eric_unterhausen> on a standard pc, they can add up to 500ms
[17:11:04] <eric_unterhausen> you will see some small latency spike with disk access with rtai, but not on the order of a half second
[17:42:48] <Valen> SMP should help with all those things
[17:43:04] <eric_unterhausen> not with DMA causing latencies
[17:43:25] <Valen> latency-test shouldn't be bothered by DMA should it?
[17:43:26] <archivist> still only one bus!
[17:43:37] <Valen> that is pretty much outside the CPU's hands
[17:43:43] <archivist> exactly
[17:43:45] <Valen> kinda the point
[17:43:58] <eric_unterhausen> no, that's one of the sources of latency
[17:44:08] <eric_unterhausen> the other is interrupt latency
[17:44:09] <Valen> the point i was making is on a non DMA machine i was seeing large spikes caused by disk access
[17:44:25] <eric_unterhausen> what is a non-DMA machine?
[17:44:30] <archivist> cpu cant access the code/memory during dma
[17:44:38] <Valen> sorry non SMP
[17:45:00] <eric_unterhausen> have you built an smp kernel?
[17:45:18] <Valen> not yet but it would be interesting to test it out on the installed system
[17:45:31] <Valen> I was benchmarking all the spare PC's i have to find the best one to use
[17:45:44] <Valen> doing a md5sum of the CD caused large spikes
[17:45:59] <eric_unterhausen> I've never really done much testing on a SMP rt kernel
[17:46:08] <Valen> CPU intensive tasks alone seemed to have little impact
[17:46:17] <eric_unterhausen> SWP keeps saying that the best thing to do is put the second processor in a busy loop
[17:46:35] <eric_unterhausen> cpu intensive doesn't mess with the interrupts
[17:46:55] <Valen> interrupts should be per CPU i would imagine
[17:46:56] <eric_unterhausen> the real problem is allowing an interrupt handler to disable interrupts
[17:47:18] <Valen> so the second core could do other stuff while the first is otherwise occupied
[17:47:42] <eric_unterhausen> you'd think so, doesn't seem to be the case in general
[17:47:52] <eric_unterhausen> but I haven't tested a rt kernel
[17:47:55] <Valen> find out when i get an on disk installed
[17:48:12] <Valen> is there something missing from the generic ubuntu RT kernel?
[17:48:15] <Valen> thats SMP
[17:48:28] <eric_unterhausen> there is no smp
[17:48:36] <eric_unterhausen> kernel, it's single processor
[17:51:59] <Valen> jaunty is SMP RT
[17:52:12] <Valen> aparently
[17:53:15] <ehj> Valen: I wasn't following the conversation but saw your reference to smp. FYI, I just built EMC for smp to run on the Intel Atom 330. The real time tasks run on the second processor, everything else on the first. I am getting latency test results of 3617 and 1976 for servo and base threads respectively.
[17:53:29] <Valen> damn thats awesome
[17:53:51] <Valen> did you have to do anything to get it to boot?, the emc live cd barfed on mine
[17:54:05] <Valen> you are running 8.04 on it?
[17:55:04] <ehj> I had to build a custom kernel, then rebuild emc. In boot/grub/menu.lst you must add isolcpus=1 to the end of the "kernel" line.
[17:55:14] <Valen> i meant the install
[17:55:22] <archivist> Valen, get the mailing lists / me was just looking for the mention when ehj said
[17:55:25] <Valen> or did you start from an 8.04.2 base then install EMC
[17:55:55] <Valen> the livecd is giving me udev errors and dropping to a busybox shell
[17:55:56] <ehj> There is a full tutorial, just a sec and I will post the link.
[17:56:04] <Valen> I didn't look into it much more though
[17:56:24] <eric_unterhausen> Valen, sounds like a drive problem
[17:56:38] <Valen> its the same drive i used in 4 other computers
[17:56:43] <Jon_geo01005> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EMC_With_Custom_Kernel
[17:56:45] <ehj> Here: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EMC_With_Custom_Kernel
[17:56:52] <eric_unterhausen> then it's a cable problem :)
[17:56:55] <Jon_geo01005> beat you :)
[17:56:57] <Valen> same cable
[17:57:07] <ehj> slow fingers. :)
[17:57:08] <Valen> and the system itself boots 8.10 fine
[17:57:16] <eric_unterhausen> you broke it while removing it from the other comp :)
[17:57:24] <Valen> that was the 2nd one i did
[17:57:41] <Valen> its a known problem between 8.04 and atom
[17:57:51] <Valen> 8.04.2 solved it
[17:58:05] <eric_unterhausen> bummer
[17:58:08] <Valen> emc doesnt ship an 8.04.2 based CD though
[17:58:16] <Valen> henc me askin ehj how he did his install
[17:58:41] <Valen> did he do some magic to get the cd to work? or use a later install then put emc onto it
[17:58:55] <eric_unterhausen> well, did he?????
[17:59:09] <Valen> i dunno he has told me how to rebuild a kernel
[17:59:10] <ehj> It was built from source, then generated packages. Move the packages to the target machine and install.
[17:59:31] <Valen> i am *not* talking about the kernel
[17:59:42] <eric_unterhausen> ehj, what distribution did you start with?
[17:59:50] <Valen> I have downloaded the emc-8.04.iso burnt it to disk and stuck it in a drive
[17:59:58] <Valen> works in 4 other PC's
[18:00:01] <Valen> not in the atom
[18:00:24] <ehj> Oh, there is another tutorial on that, just a sec.
[18:00:58] <ehj> The kernel compile is based on this tutorial:
[18:01:00] <ehj> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Debian_Lenny_Compile_RTAI
[18:01:28] <eric_unterhausen> ehj: which distribution did you start with?
[18:02:12] <ehj> For the kernel, Lenny.
[18:02:33] <ehj> The packages plus the config file for the kernel build an be found here:
[18:02:33] <ehj> http://www.linuxcnc.org/experimental/smp/
[18:13:12] <ehj> FYI, per the tutorial, I used three partitions to do the whole thing. Partition 1 - Debian Lenny to build the kernel. Partition 2 - Ubuntu 8.04 to build EMC. Partition 3 - Xubuntu 8.04 for installing and running EMC.
[18:19:28] <ehj> The config file then gets copied to ~/ubuntu-hardy/debian/binary-custom.d/ for building EMC, etc. on partition 2.
[18:21:12] <cradek> I don't see why you would use lenny to build a kernel for hardy
[18:21:42] <ehj> Because there was a tutorial for it. :)
[18:23:52] <ehj> Actually as I recall, I started on Ubuntu and ran into some problem, then found the Lenny tutorial, and other than changing the version numbers of the current versions, it worked exactly as written.
[18:43:17] <Guest263> Hi all, my first message in the EMC IRC.... wheeeeeee
[18:43:47] <Guest263> Oh.. guest... sorry... Rainer it is...
[18:44:01] <cradek> hi
[18:44:55] <skunkworks> you can do a /nick whatyournameis
[18:45:23] <Guest263> Did it
[18:45:26] <Guest263> ha... not
[18:45:55] <archivist> unless someone the said nick already
[18:46:00] <Guest263> Anyways... got a RTAI message that my kernel is tainted... huh
[18:49:46] <Guest263> Massive unexpected realtime errors... like 3456985 are there docs I can browse?
[18:52:51] <MrSunshine> why do you with say steppers for example need a realtime kernel ?
[18:53:16] <MrSunshine> as you issue each step from the computer anyways, it shouldnt mater if it comes second 1 or second 6 ... you ? :)
[18:54:14] <archivist> because its a mechanical system!
[18:54:42] <archivist> and things are moving and must happen at time T
[18:55:22] <MrSunshine> but a step is kinda instantanious anyways ... even tho moving two motors to make a diagonal line they still would make something looking like a stair right? :)
[18:55:31] <MrSunshine> as long as the steps comes in the right order it shouldnt do anything ?
[18:55:44] <archivist> no its not instantaneous
[18:56:05] <MrSunshine> ok then a slong as you do not step faster then the steps can move :P
[18:56:08] <archivist> at speed its a smooth motion
[18:57:00] <archivist> stepper are worse in that there is an acceleration curve to be followed
[18:57:39] <MrSunshine> hmm ok
[18:58:23] <archivist> eg tyou cannot go from 0 to full speed in 0 secs
[20:38:56] <archivist> not on failblog but good enough http://news.bbc.co.uk/1/hi/england/north_yorkshire/8017535.stm
[21:12:09] <voxadam> Are there any hardware interfaces that aren't ISA or parport based? Is there anything PCI based that can be used while still closing the loop in software?
[21:13:19] <archivist> sure look at the mesanet cards http://www.mesanet.com/
[21:13:51] <voxadam> I thought they only did PC/104.
[21:14:40] <voxadam> Oh...
[21:14:42] <voxadam> I see,
[21:14:49] <voxadam> My mistake
[21:16:43] <alex_joni> voxadam: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EMC2_Supported_Hardware
[21:17:19] <voxadam> alex_joni: thanks. I missed the wiki.
[21:17:23] <alex_joni> np
[21:17:49] <alex_joni> a bit easier to have it gathered in one place, than search the web for each of those
[21:18:55] <archivist> hard to find page alex_joni was just searching the wiki for it search fails for mesa, M5120 two terms it should find
[21:19:56] <alex_joni> archivist: it's linked on the first page
[21:20:13] <alex_joni> under getting started
[21:20:28] <archivist> search should still not fail though
[21:20:34] <alex_joni> archivist: the mesa board is actually called '5i20'
[21:20:42] <alex_joni> and it comes up if you search for that
[21:20:53] <alex_joni> same for mesa
[21:21:18] <archivist> I found a page with M5120 and that page did not get returned in the search
[21:21:34] <alex_joni> m5i20 is an older driver for the 5i20 board
[21:22:34] <alex_joni> archivist: otoh, the wiki is a community maintained place, so feel free to adjust it how you think would be better
[21:23:49] <voxadam> Can the 5120 handle 3 fully interpolated servo axes, quadrature encoders, and limits?
[21:24:05] <alex_joni> probably 8 or 10
[21:24:12] <voxadam> Damn.
[21:24:14] <alex_joni> 3 surely ;)
[21:24:20] <voxadam> Not bad for $200.
[21:24:27] <voxadam> Pretty damn good actually.
[21:24:38] <alex_joni> you might still want some extra hardware
[21:24:44] <voxadam> such as?
[21:24:45] <alex_joni> like isolation for the I/Os
[21:24:54] <alex_joni> and some conversion from the PWM to analog
[21:24:55] <voxadam> Of course.
[21:25:04] <alex_joni> (depending of the drives you have)
[21:26:04] <alex_joni> I got a 7i31 (24 LEDs for debugging only)
[21:26:21] <alex_joni> a 7i33 - 4 axis analog servo interface
[21:26:34] <alex_joni> and a 7i37 (16 in + 8 out - isolated I/O)
[21:27:05] <alex_joni> if you get those, there is a T version now with terminals on them, which saves you some trouble
[21:27:28] <alex_joni> I think a 5i20+7i33T+7i37T would be fit for your specs
[21:27:37] <alex_joni> (at around 340$ though)
[21:28:08] <voxadam> I wish I had seen Mesa's PCI boards when I had some extra cash laying around. I hate this economy.
[21:28:28] <alex_joni> heh
[21:29:17] <voxadam> I've been wanting to dig into some VHDL or Verilog but haven't had the chance.
[21:29:34] <voxadam> Are their code blocks open source?
[21:29:45] <alex_joni> yup
[21:29:57] <voxadam> GPL, BSD or the like?
[21:30:16] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/src/hal/drivers/mesa-hostmot2/firmware/src/
[21:30:22] <cradek> all the firmware for the mesa cards is in our CVS and is released under the GPL just like the rest of EMC2
[21:30:35] <alex_joni> -- * GNU General Public License (GPL), version 2.0 or later
[21:30:36] <alex_joni> -- * 3-clause BSD License
[21:30:50] <voxadam> Very nice...
[21:31:37] <voxadam> I think I'm going to have to get myself one.
[21:31:55] <alex_joni> voxadam: there are other options out there too
[21:32:04] <alex_joni> we're not trying to sell you one, btw :)
[21:32:19] <alex_joni> (even if I think it's a very good solution together with emc2)
[21:33:16] <coden4life> alex_joni your recommending using mesa???? looking for insight from the elite
[21:34:16] <alex_joni> coden4life: well, I try to stay neutral
[21:34:24] <coden4life> I find using just the parallel port for now is fine for me but I am thinking more robust machines and I/O is the key
[21:34:32] <coden4life> is usb the answer
[21:34:37] <coden4life> pci
[21:34:41] <alex_joni> usb certainly not ;)
[21:34:45] <voxadam> USB?
[21:34:52] <voxadam> Not exactly deterministic.
[21:35:07] <alex_joni> voxadam: there are some "gimmicks" that do some motion control over USB
[21:35:09] <voxadam> 1394 maybe but USB...
[21:35:23] <alex_joni> but they add so much limitations, that it isn't worth the trouble
[21:35:26] <voxadam> I'm sure they're very gimicky.
[21:35:28] <alex_joni> rt-eth maybe :)
[21:35:30] <coden4life> pc based cnc with more than 4 axis
[21:35:40] <alex_joni> voxadam: seen EtherCAT?
[21:35:43] <voxadam> rt-eth is another posibility.
[21:35:45] <coden4life> the I/O is my hangup
[21:35:51] <alex_joni> coden4life: get more parports
[21:36:01] <alex_joni> that's probably one of the cheapest solutions
[21:36:14] <alex_joni> the emc2 hal driver supports 8 ports iirc
[21:36:20] <voxadam> I seem to remember rtLinux supporting rt-eternet
[21:36:31] <alex_joni> voxadam: RTAI does too
[21:36:40] <jepler> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Emc2HardwareDesign
[21:36:43] <alex_joni> but the problem is the device on the other end
[21:36:47] <voxadam> I'd take parport over usb any day.
[21:37:10] <coden4life> I understand parallel that would be the route I would want but is it time I get into the new age lol
[21:37:31] <alex_joni> 2 ports / PCI board seems ok (for about 10-15$)
[21:37:41] <voxadam> parallel is still available via PCI addin.
[21:37:52] <voxadam> It's a more stable option than USB.
[21:37:55] <alex_joni> even PCIex
[21:38:09] <alex_joni> although I don't know of anyone who actually tried one with emc2
[21:39:47] <voxadam> What kind of PC hardware would EMC need to close the loop in software for four axis and handle the UI locally? Pentium? Atom 330?
[21:40:12] <alex_joni> I think some users used atom PCs lately
[21:40:26] <alex_joni> for servo thread only, you don't need much of a PC
[21:40:43] <alex_joni> a P3 should do it
[21:40:48] <jepler> the userspace stuff like the GUI is much heavier than the realtime stuff
[21:41:00] <alex_joni> depends on the GUI used
[21:41:06] <voxadam> So a dual core hyperthreaded atom should do okay.
[21:41:08] <jepler> consider AXIS, which likes to make tens of thousands (if not more!) of opengl primitives for every redraw..
[21:41:18] <alex_joni> but if you're using AXIS, then probably it depends on how big the files you use
[21:42:21] <jepler> I would start with a cast off machine (p3 like alex_joni says) and then evaluate if a faster machine is required, rather than buying a very new and possibly expensive machine
[21:42:21] <alex_joni> voxadam: hyperthreading is usually evil for RT
[21:42:30] <jepler> anyway, bbl -- the weekend begins
[21:42:34] <alex_joni> have fun
[21:42:47] <voxadam> alex_joni: I hadn't thought of that. I'm sure you're right.
[21:42:52] <alex_joni> voxadam: also, consider grabbing the LiveCD and taking it to the PC store
[21:42:58] <alex_joni> to try out a couple PCs :)
[21:43:37] <voxadam> Or I could just spend $80 and buy an Atom based board.
[21:43:38] <voxadam> http://www.newegg.com/Product/Product.aspx?Item=N82E16813121360
[21:43:41] <alex_joni> voxadam: although I think you can switch off HT in some cases from the BIOS
[21:44:00] <voxadam> That shouldn't be too much of a problem.
[21:44:09] <alex_joni> voxadam: hang on, looking for a link
[21:44:53] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Latency-Test
[21:45:27] <alex_joni> there's a D945GCLF2 in there
[21:45:31] <alex_joni> with Atom 330
[21:45:44] <voxadam> The "noht" option on the boot prompt will disable HT.
[21:45:53] <alex_joni> yup
[21:54:15] <alex_joni> voxadam: nice chatting with you, I'll head to bed now
[21:54:17] <alex_joni> good night all
[21:54:23] <voxadam> Thanks for the help.
[21:54:51] <alex_joni> any time
[22:23:55] <jsr__> I'm running EMC 2.2.8, and Mesa's 7I43, 7I33, and one of their digital I/O cards. Trying to get X,Y,and Z to work for right now. Y was no problem, X was backwards (is now fixed), but Z is an opportunity.
[22:25:19] <jsr__> It goes in the right direction, homes in the right direction, but stops short of homing, or give me a "home sw inactive before start of backoff move" error.
[22:26:38] <jsr__> I'm not sure what that means. If I reset and try to move after that, I get a hm2/hm2-7i43.0.encoder.00 dT <=0, how can this be?" error - lots of them.
[22:26:55] <jsr__> I give up, how can this be?
[22:27:00] <jepler> halscope the Z home switch input -- is it noisy?
[22:27:19] <jepler> if it is, maybe you need software debounce
[22:27:26] <jsr__> I have watched it and didn't see any transitions while it was moving.
[22:27:46] <jepler> set halscope to trigger on the rising edge of the home signal, then initiate homing
[22:27:50] <jsr__> Can I wiki and find the debounce?
[22:28:07] <jepler> http://linuxcnc.org/docs/html/man/man9/debounce.9.html
[22:28:27] <jsr__> OK. THanks, I'll check it out.
[22:29:17] <jepler> this is a config file (not for mesa, though) which uses debounce on some switch inputs: http://git.unpythonic.net/view?p=zenbot.git;a=blob_plain;f=pluto.hal;hb=master
[22:29:40] <jepler> just search through it for 'debounce', you'll get the hang of it
[22:30:06] <jepler> but first it'd be nice to know whether it is bounce, or whether it's a red herring
[22:30:26] <jepler> do you need me to talk you through using halscope to view that home switch input?
[22:31:35] <jsr__> No, I've done enough of that to understand it.
[22:32:57] <jsr__> I'll make another trek out to the barn tonight with the added knowledge, and see if I can see anything.
[22:37:11] <jepler> looks like the default debounce delay isn't documented. apparently it's 5 (or 5ms if you haven't changed the default servo period)
[22:37:46] <cradek> is it going past the switch before it can stop? the switch should stay triggered all the way to the end of the axis's travel
[22:37:54] <cradek> what kind of switch is it and what actuates it?
[22:38:12] <jepler> bbl
[22:38:36] <cradek> bizarre, I thought the "how can this be?" error was fixed in 2.2.8. are you sure that's the version you are using?
[22:39:04] <jepler> jsr__: he said 2.2.8
[22:39:13] <jepler> you're "loosing" it
[22:39:40] <jsr__> It's on a Bridgeport BTC-1. It's a big, old "microswitch" brand switch.
[22:40:12] <cradek> a cam pokes it?
[22:40:20] <archivist> some switches has a lot of bounce
[22:40:30] <Martyn> Wiat!
[22:40:35] <cradek> true, they do
[22:40:36] <jsr__> It's driven directly by a ramped dog on the spindle.
[22:40:37] <Martyn> What's the "how can this be?:" error?
[22:41:07] <Martyn> I saw that error once when trying to do a fast move on the tormach... but it went away on the second take.
[22:41:13] <jepler> Martyn: it's a debugging message reported by some versions of the hostmot2 driver. I think it says "hm2/hm2-7i43.0.encoder.00 dT <=0, how can this be?"
[22:41:35] <jsr__> I am going by what the dmesg said when I started up to get the version number.
[22:41:39] <Martyn> jepler : The tormach doens't use the hotmot2 driver though... right?
[22:41:39] <cradek> it's a bug in the velocity code of the mesa driver. It is fixed now but I'm obviously not sure in which releases exactly
[22:42:20] <cradek> jsr__: does that homing dog keep the home switch actuated all the way to the end of axis travel (limit switch)?
[22:42:52] <jepler> Martyn: I suspect you saw some other message, then
[22:43:12] <jsr__> Yes, the dog keeps that switch actuated all the way up past the limit switch, and up to the physical limit.
[22:43:35] <cradek> ok, good, just checking - some machines can go past the home switch, which is bad
[22:44:07] <cradek> I agree you should look for a loose wire and then check for bounce with halscope
[22:44:18] <jepler> cradek: the message was removed between 2.2.8 and 2.3.0.
[22:44:18] <jepler> Author: Sebastian Kuzminsky <seb@highlab.com>
[22:44:19] <jepler> Date: Sat Jan 31 06:10:35 2009 +0000
[22:44:19] <jepler> I think this fixes the encoder velocity bug
[22:45:40] <cradek> jepler: yeah I was just going to say that too. darn.
[22:46:59] <jsr__> OK. I was sort of avoiding changing versions while I am in the middle of a retrofit. I'll just live with that one until I get all the axis running.
[22:47:30] <jepler> jsr__: I don't think this specific problem will affect your system
[22:47:37] <cradek> optos and the servo-loop speed polling input should make you fairly immune to regular bounce. maybe some wiring is actually loose, or the switch is pretty bad.
[22:47:55] <jepler> I got bounce big enough to see in the servo loop, but that's with cheap microswitches
[22:48:06] <cradek> oh really, ok
[22:48:47] <cradek> either way, halscope will tell the true story
[22:49:16] <jsr__> I checked on both ends, but mice could have gotten hungry in the middle somewhere.
[22:49:54] <jsr__> I have a feeling these were of the most rugged switches in their day.
[22:50:27] <archivist> rated for a million operations or more
[22:51:00] <jsr__> I'm pretty sure at least.
[22:52:34] <jsr__> Maybe this explains why the LSI-11 on it kept crashing, too.
[22:56:43] <jsr__> jepler: 4 debounce instances were loaded in your example, but it appears only the first one was added to a thread?
[23:01:35] <jsr__> Thanks, everyone. Bye.