Back
[01:46:15] <skunkworks> Twingy: how is it coming?
[01:52:17] <skunkworks> * skunkworks finished replacing both front axles and lower ball joints in the subaru. Tomorrow the engine will start going back in.
[01:52:41] <skunkworks> whoever designed the lower ball joint should be shot.
[02:27:35] <Twingy> skunkworks, hi
[02:28:02] <Twingy> I was trying to get glx working with some nvidia or vesa driver before I left
[02:28:14] <Twingy> I'm going to try gutsy+emc on my box up in the garage
[02:28:50] <SWPadnos> did you install the Ubuntu Nvidia restricted driver, or did you get the installer from Nvidia?
[02:38:22] <Twingy> did both, the one that resulted in crap latency was the one from nvidia
[02:38:37] <SWPadnos> yep, that's a known problem :)
[02:38:43] <Twingy> so I tried droping back from "nvidia" to "nv" driver and glx module wasn't loading or something
[02:39:02] <Twingy> went to check to see if mesa-glx stuff was installed and it's there
[02:39:15] <SWPadnos> you should be able to `sudo dpkg-reconfigure xserver-xorg` and select the VESA driver
[02:39:21] <Twingy> so I'll just have to poke at the xorg.conf I guess
[02:39:27] <SWPadnos> ok, did you reconfigure or just edit the xorg.conf file?
[02:39:38] <Twingy> well I can get the vesa driver going no problem, it's just the glx junk
[02:39:52] <Twingy> I did both, edited file by hand and tried the gui thing
[02:39:58] <SWPadnos> I think dpkg-reconfigure sets that stuff up correctly for you
[02:39:59] <SWPadnos> gui?
[02:40:04] <Twingy> yea the um
[02:40:12] <Twingy> "Screens and Graphics"
[02:40:18] <Twingy> under the menu
[02:40:19] <SWPadnos> ok, that isn't it.
[02:40:42] <Twingy> that utility seems half broke
[02:40:43] <SWPadnos> you may need to drop back to text mode by stopping gdm (and possibly using ctrl-alt-backspace)
[02:40:55] <SWPadnos> then dpkg-reconfigure
[02:40:55] <Twingy> yea, I'll just /etc/init.d/gdm stop
[02:41:39] <Twingy> k, I might try that here shortly
[02:41:43] <Twingy> still working on some work related stuff
[02:41:48] <SWPadnos> heh - darned work
[02:52:30] <eric_U> have to hate it when work related crap interferes with your life
[02:52:41] <dmess> hmmm VAPT solution i'm sue
[02:52:47] <dmess> sure
[02:52:54] <cradek> eric_U: you mean every morning about 6:30?
[02:53:12] <eric_U> that's the worst of it
[02:53:25] <eric_U> I should be working now
[03:00:46] <Twingy> well I do robotics stuff for a living, so I kind of enjoy it actually
[03:01:04] <eric_U> too bad google docs doesn't display open office docs online
[03:01:10] <Twingy> building a little h-bridge for a crawler bug atm
[03:01:23] <eric_U> dc motor?
[03:01:27] <Twingy> jep
[03:01:47] <Twingy> he has to move his legs forward and reverse :)
[03:01:57] <eric_U> I'm building a brushless dc drive, hope to shrink it to fit in a robot
[03:02:02] <Twingy> if it were up to me he'd be stuck with forward ;)
[03:02:34] <eric_U> we are building a robot, mini version of the segway rmp
[03:02:48] <Twingy> oh ok, we have of those at work
[03:02:49] <eric_U> I tried to convince the other team members to just go forward
[03:02:54] <Twingy> I did some CAN code for them
[03:02:56] <eric_U> we have 4 :)
[03:03:02] <Twingy> we got ours for free :P
[03:03:21] <Twingy> you got the 4 wheel RMP or the 2 wheel?
[03:03:25] <eric_U> somebody gave us money to buy ours
[03:03:39] <eric_U> we have 2 of the 4 wheelers, wasn't counting those
[03:03:48] <Twingy> I wrote a little interface to drive around and squash crickets a few summers ago
[03:03:54] <Twingy> I'd move my mouse and *crunch*
[03:04:18] <eric_U> have you seen the 4 wheelers move?
[03:04:33] <eric_U> I'm trying to ignore the idea that they were a big mistake
[03:04:36] <Twingy> no, but we have a few of the red i-robots
[03:04:50] <Twingy> a couple of guys at work are upgrading one of them
[03:05:14] <Twingy> I stick to my autopilot work with the occasional distraction
[03:05:16] <eric_U> we have a batch of activmedia pioneer AT's, I'd love to upgrade them with a real drivetrain
[03:05:26] <Twingy> yea
[03:05:35] <Twingy> these guys aren't spending any time at all on the power system
[03:05:43] <eric_U> one of their engineers said that they work best on sand
[03:05:44] <Twingy> I was trying to talk them into going lithium iron phosphate
[03:05:50] <Twingy> and they are just putting new lead acids in >_<
[03:06:12] <eric_U> A123 is the way to go
[03:06:16] <Twingy> yep
[03:06:22] <Twingy> * Twingy <3 A123
[03:06:37] <Twingy> they got a pair of quad core mini-itx in there plus sensors
[03:06:44] <Twingy> running off a pair of 12V 35Ah lead acids
[03:06:50] <Twingy> gonna suck those dry in an hour
[03:06:57] <eric_U> what are they using for frame grabbers?
[03:07:11] <Twingy> stereo firewire and ladar
[03:07:54] <eric_U> our segways have a pair of lead acid 2/3 the size of a car battery
[03:08:28] <eric_U> been a while since we sized them, forget the ah
[03:08:50] <Twingy> I won't touch it unless it's li poly or li mang
[03:09:16] <eric_U> lipoly burns so nice
[03:09:23] <Twingy> yes, napalm
[03:09:41] <eric_U> one of our guys caught a lead cell on fire :)
[03:09:49] <Twingy> that's a rarity
[03:10:01] <eric_U> involved a screwdriver
[03:10:11] <Twingy> ok, that's not a rarity
[03:10:17] <eric_U> certainty
[03:11:27] <eric_U> http://muri.mne.psu.edu/nrsl/ robot collection
[03:12:22] <Twingy> I wonder if our group has visited you guys at all
[03:12:29] <Twingy> you ever interface with ARL?
[03:13:18] <eric_U> that's where I work most of the time
[03:13:20] <Twingy> we're getting a $500 million C4ISR building constructed
[03:13:28] <Twingy> at ARL?
[03:13:34] <eric_U> ya
[03:13:38] <Twingy> Adelphi or APG?
[03:13:47] <eric_U> wrong arl
[03:13:54] <Twingy> ok
[03:13:57] <eric_U> penn state applied research
[03:13:59] <Twingy> ah
[03:14:06] <Twingy> Army Research Lab
[03:14:10] <eric_U> ok
[03:14:30] <eric_U> where do you work?
[03:14:40] <Twingy> I work in vehicles technology directorate in micro mechanics team
[03:14:51] <eric_U> at arl
[03:14:54] <Twingy> yep
[03:15:13] <Twingy> we've got all kinds of neat toys
[03:15:26] <Twingy> hiring too :)
[03:15:29] <eric_U> we deal with the math guys :)
[03:15:41] <eric_U> you're in North Carolina?
[03:15:45] <Twingy> Maryland
[03:17:17] <eric_U> I'm trying to get one of our packbots to be autonomous
[03:17:20] <Twingy> http://www.arl.army.mil/www/default.cfm?Action=34&Page=34
[03:21:24] <eric_U> web site doesn't have enough robots on it
[03:23:18] <eric_U> fun fact: I tried to buy some of the much feared Talon robots back when they were called the lemming
[03:23:44] <Twingy> heh
[03:23:57] <Twingy> I was just looking at those a few weeks ago on my trip up to picatinny
[03:24:25] <eric_U> too bad we didn't talk them into making us some, it was full custom back then
[03:29:24] <eric_U> are you putting a computer on your legged robot?
[04:05:18] <Twingy> eric_U, an ssop PIC18F1320
[04:05:42] <Twingy> 256B RAM, 2kB flash
[04:06:29] <Twingy> plenty of room to build in some smarts
[04:06:43] <eric_U> that's the spirit
[04:07:02] <eric_U> I'm programming msp430s
[04:07:14] <Twingy> boss has me building it for the summer students to use as a basis for their project
[04:07:51] <Twingy> I got a little 1mW maxstream Xbee modem on its back
[04:08:07] <Twingy> it's gonna be so cute
[04:08:27] <Twingy> whole power system running off a 3.3V SOT-23 regulator :)
[04:08:40] <eric_U> I bought one of those, hoping to put it on my airplane
[04:08:50] <Twingy> the pro or the regular?
[04:08:56] <eric_U> pro
[04:09:09] <Twingy> yea, pro was too big and power hungry for the bugs
[04:09:25] <Twingy> 45mA is tx power on the regular one
[04:09:33] <Twingy> my SOT-23 is only rated for 150mA
[04:09:47] <Twingy> I hate driving linear regulators past half their rated current
[04:10:01] <eric_U> ya, not a good idea
[04:10:12] <Twingy> plus I got the 5mA led
[04:10:19] <Twingy> and the PIC is gonna be like 5mA
[04:10:27] <Twingy> and the op amp
[04:10:32] <Twingy> so I'm like 65mA
[04:10:39] <Twingy> don't wanna push much more through it
[04:11:37] <Twingy> before I put these SOT-23 fets in for the h-bridge I need to make sure the motors don't pull more than 150mA
[04:11:51] <Twingy> the suckers are tiny
[04:12:10] <Twingy> thinner than a pencil eraser
[04:12:21] <Twingy> geared up
[04:12:22] <eric_U> pager motors?
[04:12:29] <Twingy> dunno what they were from
[04:12:36] <Twingy> but about that size
[04:12:44] <Twingy> just geared 81:1
[04:13:00] <Twingy> got the whole thing in solid works
[04:13:06] <Twingy> using GCAM to cut parts out
[04:13:13] <eric_U> I wish I had solidworks right now
[04:13:22] <eric_U> I should learn sketchup
[04:13:24] <Twingy> yea, I'm lost with out it
[04:13:34] <Twingy> solid works + measure tool + gcam + emc = <3
[04:13:49] <Twingy> oh and eagle
[04:13:54] <eric_U> we designed the segway mounting hardware in Pro/E, what a nightmare
[04:13:58] <Twingy> heh
[04:14:04] <Twingy> Pro/E is so obfuscated
[04:14:18] <Twingy> if you use it intensely for several years it can be ok
[04:14:35] <Twingy> but for light modeling with lots of power solid works beats it hands down
[04:14:39] <eric_U> worst part is the way it handles the licences
[04:14:46] <Twingy> yea
[04:14:50] <Twingy> we have a 5-seat license
[04:14:50] <eric_U> you'll be doing something and it will go out to lunch
[04:15:18] <eric_U> I wanted to use it because it has a cam output, but that was too hard to teach myself
[04:15:35] <eric_U> just gave the files to the machinist and he converted them using mastercam
[04:16:19] <Twingy> yea
[04:16:25] <eric_U> I was supposed to have 3 other guys helping me, but it didn't work out that way
[04:16:26] <Twingy> machinists are underdogs
[04:16:48] <eric_U> ours isn't, he's top dog
[04:16:51] <Twingy> people under estimate the difficulty of being a good machinist
[04:17:07] <Twingy> we have 2 techs at work
[04:17:10] <Twingy> both suck with CNC
[04:17:18] <Twingy> had to teach them
[04:17:25] <Twingy> they can do manual machining just fine
[04:17:35] <Twingy> soon as you add a computer into the mix (durrrr)
[04:17:38] <eric_U> our machinist doesn't do manual very often
[04:17:58] <eric_U> he could, just doesn't
[04:18:09] <Twingy> we have a little Taig (same as I have at home) w/ xylotex, and we also have a Shopmaster El Durado
[04:18:17] <Twingy> Dorado
[04:18:31] <Twingy> like 18" x 24" bridgemill nothing special
[04:18:43] <Twingy> better than the little 5" x 12" taig
[04:18:52] <Twingy> we do microsystems
[04:18:53] <eric_U> sounds like creative accounting might have been employed
[04:18:56] <Twingy> so small is our focus
[04:19:08] <Twingy> we have a world class machine shop
[04:19:11] <Twingy> they just cost $$$
[04:19:21] <Twingy> so we try to do stuff our selves when we can
[04:19:38] <Twingy> they have 5-axis flow jet and plasma this and platinum EDM and all kinds of stuff
[04:19:45] <eric_U> I know how that goes, I used to be in the Air Force
[04:19:49] <Twingy> err titanium
[04:19:53] <Twingy> yea
[04:20:00] <Twingy> one of our techs used to be as well
[04:20:07] <eric_U> place I worked could make an airplane if they wanted
[04:20:08] <Twingy> lots of machinists in air force
[04:20:14] <Twingy> no doubt
[04:20:31] <eric_U> basically, the enlisted techs I worked with did, they repaired crashes
[04:21:13] <Twingy> always amusing when a million dollar plane sits on the ground because some stupid rule and can't order a $100 part for a month
[04:21:54] <eric_U> usually a hangar queen available for cannibalization
[04:24:54] <Twingy> hehe, when you program this bot the right legs will twitch
[04:25:11] <Twingy> cause I'm sharing the clock/data programming pins for the one h bridge
[04:25:39] <Twingy> will be matrix like
[04:26:03] <Twingy> ok
[04:26:05] <Twingy> bed for me
[04:26:13] <eric_U> gnite
[04:26:47] <Twingy> dpkg-reconfigure xserver-xorg tomorrow morning
[04:27:19] <eric_U> you may have to apt-get a glx package?
[07:22:23] <micges> hello
[07:50:20] <alex_joni> hi
[12:20:52] <cradek_> cradek_ is now known as cradek
[12:27:03] <skunkworks_> crappy picture..
http://www.electronicsam.com/images/house/garcon.JPG
[12:31:26] <archivist> hmm I need to turn the brightness up a BIT
[12:33:58] <skunkworks_> crappy camera - this morning.
[13:10:24] <cradek> skunkworks_: looks like you could land airplanes on that
[13:16:41] <alex_joni> at least helicopters surely
[13:17:35] <skunkworks_> heh - It is pretty much what would fit in the space provided.
[13:17:47] <skunkworks_> we only want to build it once.
[13:18:47] <archivist> build once, extend many
[13:20:23] <skunkworks_> heh - we will go up
[13:20:25] <skunkworks_> :)
[14:54:07] <tomp> Twingy: did you get glx running?
[15:28:27] <tomp> Twingy: did you get glx to run?
[15:28:37] <Twingy> so we determined that there was a huge latency when using the Nvidia hardware accelerated drivers... I'm attempting to get GLX to work with the "nv" non-hardware accelerated driver, I've got MESA stuff installed, but GLX won't seem to work
[15:29:15] <Twingy> so I'm scouring forums to figure out what glx isn't loading with the mesa glx package installed
[15:29:21] <Twingy> s/what/why
[15:30:45] <Twingy> most of the results I'm finding are idjits unable to get the hardware drivers to work and simply changing "nv" to "nvidia" to solve their problem, trying to sift through all that junk
[15:31:46] <SWPadnos> the nvidia drivers turn some of the GL libraries into symlinks to their fglrx libs. you may need to remove those links manually
[15:32:21] <cradek> Twingy: see /usr/share/doc/nvidia-glx/README.txt.gz. It says what nvidia does to xorg.conf to run. you have to undo each of these changes. probably you are missing some "Load"s
[15:33:01] <cradek> but like SWPadnos has already said a few times, you could just run dpkg-reconfigure to get a brand new xorg.conf
[15:33:16] <Twingy> I removed the symlinks and I have dbe, extmod, type1, freetype, and glx loaded
[15:33:24] <Twingy> cradek I did, doesn't fix the glx problem
[15:33:25] <cradek> yeah if you ran the NVIDIA.run, it probably screwed up your libraries
[15:33:46] <Twingy> cradek dpkg-reinstall xserver-xorg does not fix the problem
[15:34:02] <SWPadnos> ... reconfigure ... :)
[15:34:04] <Twingy> also I moved all the libGL stuff to a temporary folder and did a reinstall of Mesa-DRI Mesa-GLX etc
[15:34:06] <cradek> Remove the following lines:
[15:34:06] <cradek> Load "dri"
[15:34:06] <cradek> Load "GLCore"
[15:34:15] <Twingy> SWPadnos reconfigure, yes
[15:34:18] <SWPadnos> heh
[15:34:27] <Twingy> cradek dri and GLCore are already gone
[15:34:28] <cradek> did you put those two back?
[15:34:40] <Twingy> no, lemme try
[15:34:57] <Twingy> isn't it GLcore and not GLCore
[15:35:13] <Twingy> brb
[15:35:15] <SWPadnos> find . -iname GLCore
[15:35:40] <cradek> I don't know, I'm pasting from nvidia's readme
[15:35:51] <SWPadnos> they shuold have an unreadme
[15:36:04] <cradek> surely it's easy to reverse their instructions
[15:36:17] <cradek> (I don't think Twingy was really reading what I was typing)
[15:36:21] <Twingy> cradek I've not had glx working in software period
[15:36:36] <Twingy> cradek before _or_ after I did the NVIDIA run thing
[15:36:54] <cradek> it works on the base install...
[15:37:13] <cradek> the NVIDIA run screws everything up, including overwriting files that belong to installed packages
[15:37:18] <Twingy> I did an xubuntu gutsy install
[15:37:42] <cradek> ok, I have not used gutsy, they may have it broken (but I really doubt it)
[15:38:14] <Twingy> k, adding those 2 lines does not fix the glx problem
[15:38:48] <cradek> what exactly is the problem again?
[15:39:03] <Twingy> so, to recap, using "nv" not nvidia, with nvidia-glx removed, and /usr/lib/libGL* removed, and MESA-dri and MESA-glx reinstalled _and_ dpkg reconfigure of xserver-xorg there is no working glx
[15:39:16] <SWPadnos> http://ubuntuforums.org/showthread.php?t=380788
[15:39:36] <SWPadnos> that may have some pointers
[15:39:58] <jepler> did you install nvidia using a .deb package or using the nvidia .run installer? If you did the former, you should remove it with dpkg or your favorite package front-end. If you did the latter, you should uninstall it with nvidia-installer --uninstall.
[15:40:17] <cradek> he did both
[15:40:25] <cradek> I guess
[15:40:51] <Twingy> yes, both
[15:41:05] <cradek> it's hard to guess what the state of things is then
[15:41:28] <cradek> % apt-file search /usr/lib/libGL.so.1
[15:41:28] <cradek> libgl1-mesa: usr/lib/libGL.so.1
[15:41:44] <Twingy> which package does libGLcore live in
[15:41:55] <cradek> you can use apt-file to find out
[15:42:10] <SWPadnos> only if it's installed, which takes a while for the initial database download
[15:42:25] <cradek> only nvidia-glx has libGLcore
[15:42:43] <Twingy> ok, because X11 log says it cannot load libGLcore since I removed the NVIDIA stuff
[15:42:58] <SWPadnos> it shouldn't be trying to load that
[15:43:25] <SWPadnos> if it is, then the wrong GL library is being loaded from xorg.conf
[15:43:30] <Twingy> libGLcore.so.1: cannot open shared object file: ....
[15:43:58] <Twingy> so I should remove GLcore from xorg.conf, which I think cradek told me to just put in there
[15:44:16] <SWPadnos> dunno
[15:44:41] <cradek> % apt-file search libGLcore
[15:44:44] <cradek> xserver-xorg-core: usr/lib/xorg/modules/extensions/libGLcore.so
[15:44:45] <SWPadnos> unfortunately, the only PCs I have with nvidia hardware are using the nvidia driver
[15:45:03] <cradek> it probably screwed this up too. keep reinstalling packages!
[15:45:19] <SWPadnos> that's helpful ;)
[15:45:20] <Twingy> ok, so reinstall xserver-xorg-core
[15:45:30] <cradek> yes at least that and libgl1-mesa
[15:46:07] <Twingy> k
[15:46:25] <SWPadnos> you could also try a --purge of the nvidia restricted package
[15:47:19] <Twingy> kudos to cradek, fixed
[15:47:25] <cradek> yay
[15:47:35] <Twingy> k, trying jitter test
[15:47:37] <Twingy> sec
[15:47:41] <cradek> I like apt-file as much as I loathe the nvidia driver
[15:48:08] <SWPadnos> heh
[15:48:29] <SWPadnos> I kept wondering why in hell I didn't have it, then I realized it's a separate package
[15:48:52] <Twingy> ok, max latency is 10,000 ns = 10us
[15:49:09] <Twingy> does apt-file need to build a database?
[15:49:14] <cradek> yes
[15:49:38] <tomp> hello, i have probe with vnc. the new xsession ( :1) has no glx extensions. Thats reported when i try to open axis, tkgate, tkpaint ( any tk app ) in the new session. all those apps run fine in :0, any ideas?
[15:49:39] <Twingy> which db does it use the same for 'locate' ?
[15:49:43] <SWPadnos> no
[15:50:00] <SWPadnos> it needs all the package info, since it searches uninstalled packages
[15:50:00] <Twingy> what's the util to build the database or does it live in a cron file somewhere?
[15:50:17] <SWPadnos> I think it's an update download
[15:50:26] <SWPadnos> you don't have all the information locally
[15:50:39] <SWPadnos> (unless I'm thinking of a different program)
[15:50:47] <cradek> apt-file update
[15:51:20] <Twingy> yea
[15:54:43] <Twingy> k, bbiab
[16:03:31] <dimas> hello all
[16:03:50] <dimas> * dimas just got bare pcb's from pminmo.com
[16:04:11] <dimas> thanks guys for suggestion
[17:00:49] <Twingy> ok, so emc is working again on the Taig... running GCAM and EMC (while cutting) pretty much guarantees a kernel panic
[17:01:49] <Twingy> is there something in BASE_PERIOD or CYCLE_TIME [TASK] that I can change to get rid of this behavior?
[17:03:32] <SWPadnos> hmmm. usually if BASE_PERIOD is too low, the machine just stops working - you don't get a panic
[17:04:05] <Twingy> like I can run calculator and emc at the same time
[17:04:12] <Twingy> but if I fire up gcam and do nothing it's fine
[17:04:26] <Twingy> but as soon as I start spinning the 3D view around while EMC is cutting it's kills X and machine hangs
[17:04:44] <SWPadnos> nv or vesa driver?
[17:04:46] <Twingy> 3D view in gcam that is
[17:04:49] <Twingy> 'nv' driver
[17:05:13] <SWPadnos> does glxgears run?
[17:05:26] <Twingy> glx gears works now
[17:05:46] <Twingy> haven't tested glxgears while emc is running though
[17:06:01] <SWPadnos> ok. try glxgears and gcam, and glxgears and EMC. the problem could be multiple access to the 3D code
[17:06:09] <Twingy> like it works for about 5 - 10 seconds with EMC + GCAM going then problem
[17:06:19] <Twingy> ok
[17:06:28] <Twingy> so you thin kmaybe it's a MESA thing ?
[17:06:37] <Twingy> or a MESA/kernel shard memory thing
[17:06:43] <SWPadnos> I don't know. it could be MESA, or NV
[17:06:50] <SWPadnos> you can also try the vesa driver
[17:07:38] <Twingy> yea, ok I'll try those things later today, some one is using the machine now that it's back online again
[17:07:44] <SWPadnos> heh
[17:07:47] <SWPadnos> pesky users
[17:07:52] <Twingy> jes
[17:07:55] <Twingy> * Twingy s hakes fist
[17:08:13] <Twingy> it's offline too otherwise I'd hijack it :>
[17:09:07] <Twingy> I checked out bamcam yesterday, too bad it's windows only
[17:32:35] <cradek> Twingy: I've had bad luck with nv. try vesa.
[17:33:25] <cradek> you could check the xorg errors in /var/log, you'll probably see a sig11
[18:59:33] <skunkworks_> huh - looks like our direct-to-screen machine had galil hardware in it.
[19:07:14] <awallin> what's a direct-to-screen machine?
[19:08:53] <skunkworks_> awallin: instead of using film to explose screens for screen printing - this is like a printer that exposes the screen sort of like a projector
[19:12:37] <skunkworks_> awallin: like this
http://www.sefar-screens.com/catalog/index.php?main_page=product_info&cPath=32_38&products_id=83
[19:14:13] <awallin> I see. Are you going to put emc on it?
[19:15:57] <skunkworks_> heh - no. this is brand new equipment for us.
[19:18:33] <skunkworks_> awallin: was it you that used emc to run a screen printing machine?
[19:18:50] <awallin> no. don't know who that is.
[19:19:18] <skunkworks_> maybe it was acemi
[19:24:15] <Twingy> ok, just finished the test with glxgears and emc
[19:24:26] <Twingy> anytime (2) gl contexts are open the system locks
[19:24:34] <Twingy> killing X just before doing so
[19:24:41] <cradek> even with vesa?
[19:24:47] <Twingy> yes, just tested with vesa
[19:24:53] <Twingy> same behavior
[19:24:58] <cradek> yuck.
[19:25:05] <cradek> anything in the X error log?
[19:25:14] <Twingy> system is coming back up, sec
[19:25:32] <cradek> does the system lock or is the console just screwy?
[19:29:47] <lerman> I've just installed new firewall software. Would each of you wait a random time and if no one else has replied let me know that you see this? Thanks.
[19:30:16] <cradek> haha
[19:30:19] <awallin> huh?
[19:30:27] <cradek> I'm similarly puzzled
[19:31:39] <Twingy> ok, so I didn't find anything in the logs, but running glxgears and GCAM causes X to restart, but the system doesn't hang
[19:32:13] <cradek> I suggest you search for a matching bug on launchpad and submit one if you can't find it
[19:32:28] <Twingy> yep
[19:32:34] <Twingy> looking now
[19:32:40] <cradek> be sure you can reproduce it with the stock kernel
[19:33:20] <skunkworks_> lerman: I saw it. (random enough?)
[19:33:35] <lerman> Thank you.
[19:39:20] <skunkworks_> net coolant-flood <= iocontrol.0.coolant-flood
[19:39:28] <skunkworks_> net coolant-flood => parport.0.pin-01-out
[19:39:33] <skunkworks_> is the same as
[19:39:53] <skunkworks_> net coolant-flood iocontrol.0.coolant-flood parport.0.pin-01-out
[19:39:57] <skunkworks_> correct?
[19:40:04] <awallin> yes
[19:40:11] <skunkworks_> Thanks
[19:40:42] <awallin> also, the arrows don't matter, you can drop them if you want
[19:44:04] <jepler> gnu bison
[19:44:05] <jepler> argh
[19:46:40] <skunkworks_> http://www.cnczone.com/forums/showthread.php?p=436666#post436666
[19:48:47] <awallin> with my LabVIEW hat on: what color would that signal wire be? :)
[19:48:58] <skunkworks_> jepler: does maybe the step-conf not do coolant correctly?
[19:49:00] <skunkworks_> plue
[19:49:03] <skunkworks_> oops
[19:49:04] <skunkworks_> blue
[19:49:11] <skunkworks_> ;)
[19:49:24] <awallin> I thought booleans were green...
[19:49:36] <skunkworks_> * skunkworks_ is making shit up.
[19:49:39] <SWPadnos> yes, green
[19:49:41] <SWPadnos> blue is ints
[19:49:57] <Twingy> boss saw my tektronix TDS2002B and wants us to get one now
[19:49:59] <Twingy> go figure
[19:50:04] <awallin> SWP has clearly seen LV
[19:50:04] <Twingy> personal one that is
[19:50:12] <SWPadnos> sadly, that's true
[19:50:49] <Twingy> think I will get the TDS2012B since its not much more
[19:51:20] <awallin> get a LeCroy. Tek's are toys.
[19:51:50] <archivist> never got close to a LeCroy
[19:51:57] <SWPadnos> they're very nice
[19:52:09] <archivist> specs are nice
[19:52:19] <SWPadnos> the newer WaveRunners (I think) have an options for a 32-channel digital pod
[19:52:21] <Twingy> yea, I <3 my 2002B
[19:52:32] <Twingy> we're getting a spectrum analyzer next month
[19:52:35] <SWPadnos> the total cost is much less than a similar Agilent unit with only 16 digital channels
[19:53:02] <SWPadnos> how deep is the memory on the 2002B?
[19:53:17] <SWPadnos> that's one thing Agilent has always beaten Tek on
[19:53:24] <archivist> memory depth is normally the killer
[19:53:31] <Twingy> I can live with agilent or tektronix, both are good
[19:53:39] <Twingy> mine only does 2500 data samples
[19:53:43] <SWPadnos> ewww
[19:53:46] <Twingy> 1 gigasample
[19:53:54] <Twingy> 1GS/s
[19:53:57] <SWPadnos> the Agilents are all 1-4M points these days
[19:53:58] <Twingy> 60mhz 2 channel
[19:54:07] <Twingy> we have a 4 channel 500mhz agilent here
[19:54:14] <Twingy> well they're computers
[19:54:20] <Twingy> with a probe cards
[19:54:22] <SWPadnos> you can zoom in about 6 clicks of the timebase knob after capturing
[19:54:25] <SWPadnos> heh
[19:54:34] <SWPadnos> which one do you have? the infiniium?
[19:54:35] <Twingy> you ever open one up?
[19:54:45] <SWPadnos> no, I like to keep the warrantees :)
[19:54:52] <Twingy> yea, infinium
[19:55:02] <SWPadnos> ok, those are the more expensive series
[19:55:23] <SWPadnos> they have a 7000 series now that has lots of extra features over the 6000 (the one I have)
[19:55:35] <Twingy> personal or work?
[19:55:42] <SWPadnos> similar specs, but better software - things like I2C and SPI triggering
[19:55:46] <SWPadnos> both - I work for myself ;)
[19:56:08] <Twingy> trying to find this dual opengl context crash is a pita
[19:56:17] <jepler> gold linker scritp
[19:56:22] <jepler> argh argh argh
[19:56:28] <SWPadnos> hopefully it happens with any pair of apps?
[19:56:33] <jepler> * jepler should learn what window he has focused
[19:56:35] <SWPadnos> ie, gcam and glxgears do it too
[19:56:39] <SWPadnos> heh
[19:56:48] <Twingy> SWPadnos yes
[19:56:57] <Twingy> any 2 guaranteed to kill X
[19:57:17] <Twingy> where's a glx developer when you need one
[19:57:59] <SWPadnos> #glx ? :)
[19:58:09] <archivist> get the code start fixing
[19:58:20] <archivist> * archivist ducks
[19:58:23] <Twingy> yea seriously
[19:58:33] <Twingy> it's open sauce right? :)
[19:59:45] <Twingy> think I will just wait until hardy heron distro of emc comes out
[19:59:56] <Twingy> not worth the effort to fix and just replace with something in a month or two
[20:00:52] <cradek> you're assuming that opengl isn't screwed up even worse on hardy?
[20:01:14] <Twingy> no
[20:01:25] <Twingy> I'm assuming that I can let some other dev worry about it
[20:02:25] <Vq^> when will hardy emc be released?
[20:02:40] <cradek> some time after hardy is released
[20:02:46] <SWPadnos> or later
[20:03:06] <Twingy> hehe
[20:03:24] <cradek> Twingy: it would be nice to try your test on hardy beta. if they have broken opengl, it MAY still be soon enough to fix it
[20:03:26] <Twingy> when will we go to mars? After the spaceship is built.
[20:03:30] <Vq^> im having problem with drivers on the current dist
[20:03:43] <lerman_> lerman_ is now known as lerman
[20:03:48] <Twingy> cradek: it would be, but I don't really have the time
[20:04:22] <Vq^> sata and gfx, is there some half-simple way to compile the emc-package and the kernel for another ubuntu version?
[20:04:23] <Twingy> spent all day getting emc to compile and run yesterday
[20:04:34] <Twingy> I used up my months supply of system hacking time
[20:08:49] <Twingy> see the article on the self reproducing rapid prototyping machine?
[20:08:55] <Twingy> self replicating
[20:10:45] <fenn> what article?
[20:15:02] <SWPadnos> slashdot reporting on reprap, maybe?
[20:15:10] <tomp2> i was just googling for a used scope. any leads on a THS720?
[20:15:31] <SWPadnos> if not, don't buy it. the leads are expensive ;)
[20:16:05] <tomp2> got the leads
[20:16:08] <tomp2> :)
[20:16:45] <tomp2> damn english leads/suggestions leads/probes
[20:17:20] <tomp2> was looking to buy a refrub THS720
[20:17:38] <tomp2> refurb (damn fingers )
[20:19:37] <SWPadnos> I have an Agilent 54622D I can sell you
[20:20:44] <tomp2> im
[20:20:59] <awallin> what's with the second 'out' in this pin definition in a comp example: pin out float sin_ out;
[20:21:23] <jepler> an error, maybe?
[20:21:27] <jepler> sounds fishy to me
[20:21:34] <awallin> http://www.linuxcnc.org/docs/devel/html/hal_comp.html
[20:21:56] <awallin> 1.13.2 sincos
[20:23:16] <jepler> yeah it's just wrong
[20:23:20] <jepler> the second out or in shouldn't be there
[20:23:45] <awallin> is 'state' a reserved word in C or comp?
[20:23:59] <SWPadnos> comp
[20:24:01] <SWPadnos> or nothing
[20:24:24] <awallin> I get compile errors when trying to name a pin state
[20:25:00] <jepler> "struct state" is the type which holds all the per-instance data for a component
[20:25:19] <awallin> that explains it.
[20:33:03] <tomp2> SWPadnos: I im'd you about the Agilent, not familiar with IM tho
[20:33:24] <tomp2> is that 'invite'?
[20:33:26] <SWPadnos> do you mean /msg ?
[20:34:58] <tomp2> SWPadnos: email tomp-tag@sbcglobal.net about the Agilent, i'll reply, thx
[20:35:16] <SWPadnos> ok. I'll do that in a little bit. I have to get some breakfast before I fall down
[20:35:25] <tomp2> go for it
[20:51:38] <awallin> how often does halui read its pins?
[20:52:34] <jepler> awallin: there's no guarantee, since it's a userspace component. it looks like it tries to sleep 0.02 seconds (grep sleep halui.cc), or RETRY_INTERVAL or EMC_COMMAND_DELAY, whatever those are
[20:53:07] <cradek> no faster than 50Hz
[20:53:41] <awallin> I see, there are some pins I want to set high, but the need to reset low again. And it seems if I do that too fast halui doesn't 'get the message'
[20:54:18] <cradek> yuck
[20:54:38] <cradek> everything (?) has a reflected status - can you keep the pin high until it's acknowledged?
[20:55:02] <awallin> yes, probably that's better, I'll try that
[20:55:45] <awallin> from a comp, are the pins set at the line in the C-code where I do out=1, or only after the function has finished?
[20:56:52] <cradek> they are set immediately
[21:00:02] <awallin> yay, waiting for the is-on 'handshake' works much better. maybe there's some merit to this 'nist-logic' after all...
[21:00:16] <cradek> cool.
[21:00:55] <awallin> and I didn't have to learn CL, just a custom comp in good old C
[21:01:30] <cradek> one of the reasons CL is cool is that you can see what's happening as it executes
[21:02:05] <cradek> the source code is the program is the debugger
[21:02:23] <cradek> but, C is sure comfortable and simple
[21:02:59] <cradek> awallin: is this the pushbutton->halui thing?
[21:03:22] <awallin> yes, sets coolant based on a momentary-on pushbutton
[21:03:44] <cradek> it would be great if you would put that on the wiki. people have asked about it before, and I bet your solution is the best one
[21:03:55] <awallin> seems to work, I'll post it on the blog and call it a day.
[21:04:07] <cradek> goodnight, time to go home here.
[21:04:21] <jepler> you might add code or links to
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ContributedComponents
[21:04:42] <awallin> yep, I linked to 'idb' there I think
[21:04:57] <jepler> ah I see that now
[21:08:45] <awallin> damn, can't get a network connection from vmware... I never remember if it should be bridged or NAT from home/work
[21:09:59] <tomp2> one of the tuning tests we do is to evaluate the smallest command the system will react to , so it's related to idb. in general, small is good, a very few lsb's of the dac must cause a response
[21:10:27] <tomp2> more important for those who must move well at slow speeds
[21:10:40] <awallin> ok. are these analog input or pwm input amps?
[21:10:53] <tomp2> mine. analog
[21:11:05] <tomp2> copley 423's
[21:11:18] <tomp2> and the yaskawas now
[21:11:29] <awallin> I think with PWM there are inveitably problems around 0 and + or - 10
[21:11:43] <awallin> what's a pwm with 0% duty? or 100%
[21:12:29] <awallin> there must be some minimum width that the amp reacts to. in my case that seems to be between 0.15 and 0.2
[21:12:31] <tomp2> both are likely seen as hardware errors ( lost signal or shorted supply ) ;)
[21:12:45] <awallin> also there is some maximum, which in my case is around 9.7
[21:13:00] <awallin> this is with 50kHz pwm from a m5i20 and driving jon elsons dc servo amps
[21:13:58] <tomp2> your idb is concerned with min, might you force max when close enuf to max? (the 9.7)
[21:14:29] <awallin> the simple and stupid way is to just reduce the pid max output by the same amount as you do idb
[21:14:45] <awallin> a smarter idb component might ensure the old max is not exeeded
[21:21:58] <tomp2> still studying idb, what it does when amount>in>-amount... ok, it skips that band except for the 0 input case
[21:29:12] <awallin> meet toggle2nist
http://www.anderswallin.net/2008/04/toggle2nist/
[21:41:51] <awallin> gnight
[21:51:21] <jepler> another day, another 100MB of updates on Ubuntu 8.04 beta
[21:51:28] <jepler> (actually, more like 12 hours..)
[22:03:54] <lerman_> lerman_ is now known as lerman
[22:07:29] <Sweeper> does EMC support serial control of cnc devices? I'm pondering a cnc controller board based on arduino....
[22:07:51] <SWPadnos> no
[22:09:52] <Sweeper> hmm
[22:10:29] <Sweeper> any idea how hard it would be to slap together a quick protocol? bitbanging is inefficient, and parallel ports aren't exactly common :D
[22:10:40] <Sweeper> well, on new gear, anyways
[22:13:53] <micges> I use AXIS about 1,5 year, have installed and run 10 machines with it and I have some suggestions
[22:14:58] <micges> suggestion for better fit effective 24h working
[22:17:11] <SWPadnos> Sweeper, at the moment, EMC assumes that it has direct control and feedback to/from the motors. IO can be done with non-realtime protocols (you could put NML on a microcontroller), but not motor motion
[22:17:52] <SWPadnos> micges, if you have a lot of things to suggest, maybe you cuold put them in an email or a wiki page ??
[22:18:20] <archivist> going to have to buckle down and play with USB2 one of these days
[22:19:13] <SWPadnos> hmmm. Maybe I'll have to talk to Ampro again at ESC. I just got an email with this subject line:
[22:19:23] <SWPadnos> "Ubuntu goes embedded and Core 2 Duo gets rugged!"
[22:20:22] <archivist> SWPadnos, I skim read the USB2 spec the other day and it looked fast enough
[22:20:47] <SWPadnos> it's hard to tell, because they don't seem to talk about latency or "turnaround" much
[22:21:10] <SWPadnos> latency is usually referred to in terms of how long it will take to get the next frame or whatever to/from the PC
[22:21:26] <archivist> they do there its 250 us secs per frame
[22:21:36] <SWPadnos> err
[22:21:49] <SWPadnos> I wonder where that would come from. that's two microframe
[22:21:53] <SWPadnos> s
[22:22:12] <archivist> andsorry yes 125 per microframe
[22:22:12] <tomp1> archivist: could you look at firewire, it is used in realtime already, but we have no drivers
[22:23:02] <archivist> and there is a periodic interrupt setting for timed data
[22:23:13] <SWPadnos> tomp1, both USB and firewire are used, but I don't think either is used with the standard stack
[22:23:27] <SWPadnos> we don't have timed data for anything except steppers
[22:23:44] <SWPadnos> I think the Yaskawa Mechatrolink is USB - at least it uses USB connectors :)
[22:23:54] <tomp1> dunno what standard stack is but aerotech cnc uses firewire between motors
[22:23:54] <SWPadnos> then again, they use firewire connectors for their encoders
[22:24:20] <SWPadnos> I meant the standard drivers for the Firewire/USB chips
[22:24:56] <SWPadnos> it's like ethernet - you can have a realtime protocol using the same hardware, but you have to write your own software to do it (RTNet)
[22:25:16] <SWPadnos> there are projects for RTUSB and I believe RT-Firewire
[22:26:27] <tomp1> http://ostatic.com/61935-software-opensource/rtfirewire
[22:26:36] <SWPadnos> I guess there is one then :)
[22:27:46] <SWPadnos> I wonder if the FW servo drives really caught on much. I see an article saying that they were introduced in 2002 or so
[22:28:17] <tomp1> still googlin usb realtime open source ( found closed )
[22:28:21] <SWPadnos> heh
[22:28:30] <SWPadnos> RTAI/COMEDI has some USB RT thing I think
[22:29:03] <SWPadnos> http://developer.berlios.de/projects/usb4rt
[22:29:30] <tomp1> yay berlios!
[22:38:23] <tomp1> i think something smells in glx/tk land. so far vncrec doesnt like it, now Vapt hangs the kbd & mouse when resizing a window. this is on 2 very different systems.
[22:43:45] <Sweeper> SWPadnos: how much of an issue is the timing going to be? I would think a 192000 serial connection would be plenty fast enough
[22:44:38] <SWPadnos> 192kbaud? :)
[22:45:05] <fenn> not fast enough
[22:45:17] <SWPadnos> the normal servo cycle is 1 millisecond, so even at 115200 baud, you only get about 1150 bytes per second, which is 11.5 per servo cycle
[22:45:34] <fenn> unless you are sending high level commands and doing most of the motion planning on the other side of the serial link
[22:45:35] <SWPadnos> you either need a separate serial port for each motor, or you need faster communications
[22:45:52] <Sweeper> * Sweeper looks at the spec on his UART
[22:46:13] <SWPadnos> it may go up to 9216kbaud, but that would require some special cabling and care
[22:46:23] <SWPadnos> err - 921.6k
[22:46:59] <Sweeper> 115200 is top for the standard arduino
[22:47:54] <Sweeper> * Sweeper wishes he knew more about cnc software...
[22:47:58] <SWPadnos> heh
[22:48:07] <fenn> Sweeper: what's your target mechanical hardware?
[22:48:34] <Sweeper> MDF cnc mill with dot-matric steppers
[22:48:47] <fenn> half stepping or microstepping?
[22:48:53] <SWPadnos> a fundamental part of EMC is that it is closed loop. stepper output was added long after closed-loop servo control
[22:49:12] <SWPadnos> must have been a big printer
[22:49:12] <fenn> using steppers would simplify things a lot
[22:49:38] <Sweeper> fenn: neither at the moment. just full steps. 1.8 deg and some really finely threaded rod
[22:50:08] <fenn> you could just dump a list of timestamped steps for each motor, and let the arduino handle timing and hardware interface
[22:50:12] <SWPadnos> you would be better off using 1/2 or 1/4 stepping due to resonance issues
[22:50:29] <fenn> yeah full step has horrible resonance issues
[22:50:31] <SWPadnos> the ncpod EMC interpreter would be a good place to start for that
[22:50:33] <Sweeper> fenn: ooo, I like. would that be complicated to make emc do?
[22:50:38] <SWPadnos> yes
[22:50:42] <Sweeper> D:
[22:50:49] <fenn> what's ncpod have to do with it?
[22:50:50] <SWPadnos> a company did it for their proprietary USB hardware
[22:51:04] <Sweeper> SWPadnos: did they release it? :D
[22:51:05] <SWPadnos> they used the EMC2 interp, and it outputs positions at 1/1000 second intervals
[22:51:11] <tomp1> some of the firewire 'smart' drives close the position loop on the drive side, but its only the tp value that is moved, and any error reported back
[22:51:12] <fenn> i thought that was an embedded x86 with an fpga card?
[22:51:13] <archivist> Sweeper, find an old pc with a parallel port
[22:51:14] <SWPadnos> yes, it's on their site somewhere
[22:51:35] <SWPadnos> it is, but the Windows app is a heavily modified EMC2 interpreter that spits out 1-millisecond waypoints
[22:51:47] <fenn> Sweeper: unless you're interested in exploring new territory and developing a lot of software, get an old pc with a parport
[22:51:54] <Sweeper> fenn: I am :)
[22:51:55] <SWPadnos> yeah, I'd spend the $15 on a parport card and be done with it
[22:52:09] <SWPadnos> oh, excellent! :)
[22:52:13] <Sweeper> I've got some sketches for an arduino motor driver shield that can be stacked
[22:52:21] <fenn> btw i'm glad you're using arduino, it's neat
[22:53:16] <fenn> oh ncpod is tiny
[22:53:57] <fenn> i was thinking arcnc100:
http://atelierrobin.net/p41.htm
[22:54:10] <SWPadnos> ah, yep. not that one :)
[22:54:51] <Sweeper> time-stamped motions would also allow basically any kind of arduino comms to be used
[22:55:18] <Sweeper> "what, you mean your cnc controller DOESN'T run over bluetooth?"
[22:55:35] <SWPadnos> well, there are issues with that
[22:55:55] <SWPadnos> feed rate override, stop/pause commands, spindle-synchronized motion ...
[22:56:12] <Sweeper> stop/pause, yea
[22:56:26] <Sweeper> although it'd be a lot easier to just wire up an e-stop into the arduino
[22:56:42] <Sweeper> big red buttons are attractive to me :d
[22:56:44] <Sweeper> :D
[22:56:51] <SWPadnos> sure, you basically end up putting all of EMC at the end of the serial/whatever link
[22:57:24] <SWPadnos> that's the point - you can't really separate the motor drive from the trajectory planner if you need to support feedback for any reason
[22:57:26] <SWPadnos> for the most part
[22:57:53] <Sweeper> I suppose so
[22:58:21] <Sweeper> basically, all you'd end up with is a motion "pager" and logger on the pc side
[22:58:58] <SWPadnos> right. and probably a separate codebase, unless the other end can run Linux + RTAI :)
[22:59:09] <Sweeper> yup
[22:59:31] <Sweeper> * Sweeper wonders if he's gonna have enough ram/memory in the arduino
[22:59:36] <SWPadnos> nope
[22:59:43] <Sweeper> not for linux, I mean
[22:59:52] <SWPadnos> oh. in that case maybe ;)
[22:59:55] <Sweeper> for the stuff I'm gonna need to write
[23:00:07] <SWPadnos> depends on whether you intend to write in C or assembly ;)
[23:00:12] <Sweeper> the reprap guys are using arduino, and they've got more stuff
[23:00:42] <Sweeper> 'course, their tolerances are pretty high
[23:00:59] <SWPadnos> and they're just using it to spread the powder, I thought
[23:01:03] <SWPadnos> like a slow PLC
[23:01:25] <Sweeper> spread the powder?
[23:01:39] <SWPadnos> oh - I may be thinking of the 3D printer people
[23:01:40] <jepler> have you tried to ballpark the attainable step rate with an arduino? If it's 16MHz, and each stepper calculation takes 100 cycles plus 50 for interrupt overhead, and it takes two cycles for one step, you're down in the realm of 22kHz which isn't all that great. (And that doesn't budget for the time required to read timestamped position inputs)
[23:02:00] <jepler> (that calculation's for 3 axis)
[23:02:09] <Sweeper> reprap IS the 3d printer people
[23:02:37] <Sweeper> 100 cycles? D:
[23:02:48] <Sweeper> I really hope it doesn't take that long
[23:02:54] <archivist> Sweeper, using standard EMC only code you need to write is g code for your parts (using commercial stepper amps)
[23:05:12] <Sweeper> also, I thought decimelia ran at 18mhz
[23:05:28] <Sweeper> err
[23:05:29] <Sweeper> 20
[23:06:09] <jepler> 16.000H7F is the crystal marking on mine.
[23:06:19] <SWPadnos> it says 16 MHz on the website
[23:06:22] <SWPadnos> also
[23:06:42] <Sweeper> wth was I looking at...
[23:06:51] <SWPadnos> I have no idea
[23:06:58] <jepler> Sweeper: I think the AVR itself is rated up to 20MHz
[23:07:11] <Sweeper> ah, gotcha
[23:08:50] <jepler> but my point is that you should have a general idea whether the arduino will be fast enough to do what you want -- whether it's simply to move your motors as fast as they can go with a naive 4-transistor driver, or whether it's to provide higher step rates than a PC with a parport, or whatever your goal is
[23:09:32] <Sweeper> troof
[23:11:05] <jepler> emc's step generator works based on 64-bit position and velocity registers (position += velocity; if position changed by one count, manipulate outputs); you can make trade-offs that reduce this width, but you may still end up doing some arithmetic that is painfully wide for an AVR..
[23:11:25] <jepler> or maybe you'll find a different step generation core that is better suited to an 8-bit micro
[23:11:42] <Sweeper> mebbe
[23:11:44] <archivist> Sweeper A proper current limited high voltage stepper driver will allow faster steppers
[23:11:53] <jepler> (the one at
http://www.arduino.cc/en/Tutorial/StepperUnipolar is painfully bad)
[23:11:59] <Sweeper> archivist: I'm making one of those!
[23:12:05] <Sweeper> jepler: yes, I saw that :v
[23:12:17] <Sweeper> I want to experiment with a few designs
[23:12:33] <Sweeper> I was hoping i2c would be fast enough to bus the drivers, but I don't tink it will be
[23:13:00] <jepler> bbl
[23:13:03] <jepler> good luck on your project
[23:13:11] <Sweeper> kk, thanks :D
[23:13:52] <tomp1> I think the tp >is< separated from the drive during any one TRAJ_PERIOD. At the beginning of a TRAJ_PERIOD, EMC2 checks the present position, develops a new step/voltage/pwm for each involved joint, then just waits during the TRAJ_PERIOD. There is no feedback >during< the TRAJ_PERIOD.
[23:14:31] <SWPadnos> the link between TP and drive needs to be realtime
[23:14:41] <tomp1> that is a realtime description
[23:14:48] <SWPadnos> this is due to the requirements of feedback-driven systems
[23:15:05] <SWPadnos> so you can't use a slow comm channel and buffer
[23:15:20] <SWPadnos> therefore the comm channel needs to be realtime
[23:15:31] <Sweeper> mmm
[23:15:34] <SWPadnos> and fast enough to carry all necessary data every cycle
[23:15:34] <archivist> or fixed delay
[23:15:40] <SWPadnos> no, not fixed delay
[23:15:45] <Sweeper> for feedback-driven systems, yea....
[23:15:48] <jepler> if you don't care where the machine actually ends up (or trust other parts of the system as a whole to figure that out) you can loop back position cmd to position fb, like sim does, then hook cmd to whatever else you want
[23:15:54] <SWPadnos> tapping = spindle-synchronized motion
[23:16:03] <tomp1> any protocol that can achieve that command/check time can be used in realtime
[23:16:11] <SWPadnos> yes, that's one option (one I suggested for use with devices like the G-Rex)
[23:16:27] <jepler> tomp1: no, only the ones for which someone will write a driver
[23:17:08] <Sweeper> tapping is hardcore cnc stuff tho
[23:17:16] <tomp1> thats true in execution but not a limit for what can be done
[23:18:10] <archivist> no such thing as a comm channel without delay
[23:18:30] <archivist> its just degree
[23:18:58] <tomp1> that doesnt mean there is no real time comm channel in use
[23:19:23] <tomp1> realtime has requirements, but limits to those requirements
[23:19:46] <tomp1> it is not 'perfect' or instantaneous
[23:20:13] <archivist> exactly, so what are the limits
[23:21:33] <tomp1> what you need
[23:56:29] <BigJohnT> Hiya
[23:58:16] <fenn> hullo
[23:58:20] <fenn> cut any metal yet?
[23:58:24] <fenn> with your portable table
[23:59:01] <BigJohnT> just the once fenn, busy building the material support system
[23:59:14] <fenn> oh. i must have missed it
[23:59:33] <BigJohnT> yea, I cut up a 4x8 sheet of 12 gauge into small bits
[23:59:39] <BigJohnT> for a duck pit
[23:59:54] <BigJohnT> to make boxes to hold the coffee and shells
