Back
[01:36:48] <jmk-robot> SWPadnos: around?
[01:37:02] <jmk-robot> where did you get the SMP RTAI kernel that you used for the power supply project?
[01:37:03] <SWPadnos> yep
[01:37:15] <SWPadnos> linuxcnc.org I believe
[01:37:23] <jmk-robot> ISTR playing with that myself shortly after I got my core2
[01:37:41] <jmk-robot> I'd like to try it here - seems a shame to have a core sleeping
[01:37:52] <SWPadnos> lemme see if I can find it again
[01:41:11] <SWPLinux> hmmm. maybe cradek was hosting it ??
[01:41:26] <SWPLinux> I couldn't find anything named "*smp*deb"
[01:43:19] <jmk-robot> I did some googling earlier
[01:43:54] <jmk-robot> I found a few IRC logs where we were discussing SMP and do-nothing tasks in passing, but not the actual discussion the day I was testing it
[01:44:04] <jmk-robot> there'd probably be a link to the kernel near there
[01:46:04] <SWPLinux> you'd think so
[01:51:30] <SWPLinux> eventually, grep will finish looking at my local logs :)
[01:54:28] <jmk-robot> ah - now I know why you have terabyte drives
[01:56:29] <SWPLinux> aha - I think I found it
[01:56:35] <SWPLinux> and not in my local logs :)
[01:56:59] <SWPLinux> http://www.linuxcnc.org/experimental/
[01:57:31] <SWPLinux> use the 2.6.20 versions, I think 2.6.17 was the one with the kkeeyybbooaarrdd rreeppeeaattiinngggggg problem
[02:01:21] <jmk-robot> thanks
[02:01:37] <SWPLinux> sure
[02:01:49] <SWPLinux> glad I found it - I need to install it on another machine :)
[02:06:41] <jmk-robot> to install those, I point sources.list at that repo?
[02:07:09] <SWPLinux> I downloaded them and then installed with dpkg
[02:07:11] <jmk-robot> or do I download the files
[02:07:13] <jmk-robot> heh
[02:07:15] <SWPLinux> but gdebi will work also
[02:07:36] <SWPLinux> if you download in firefox (on that machine), it will ask you if you want to open them with gdebi
[02:07:52] <jmk-robot> it just did
[02:07:59] <SWPLinux> you'll have to recompile emc2, of course (with the right realtime dir selected)
[02:08:26] <jmk-robot> right - compiling is a given, since I'm doing hal-y stuff and will be compiling my own comp(s) as well
[02:08:39] <SWPLinux> yep
[02:10:34] <jmk-robot> so far I can choose (at grub menu) between RTAI and normal ubuntu kernels, and at the login menu between xfce and gnome
[02:10:42] <SWPLinux> cool
[02:10:46] <jmk-robot> another permutation should be fun
[02:10:54] <SWPLinux> heh
[02:11:06] <SWPLinux> it's no biggie
[02:11:33] <SWPLinux> too bad there isn't an easy way to have a switch (physical, connected e.g. to the parallel port) select which kernel to boot
[02:11:50] <jmk-robot> hack grub
[02:12:16] <jmk-robot> which reminds me, I need to figure out my grub problem
[02:12:19] <SWPLinux> apparently you missed the word "easy" :)
[02:13:04] <jmk-robot> when I boot, it reads the MBR from the usb disk (the one I booted for the initial install), then fetches grub, from I don't know which disk, then fetches menu.lst from the hard disk, gives me a menu, and finally fetches a kernel from the hard disk
[02:13:30] <jmk-robot> if the USB disk isn't in, it won't boot - either the HD MBR is broke, or there isn't a valid grub on the HD
[02:13:46] <SWPLinux> actually, with multiple drives you can do it, you just need to use a DPDT and flip the cable select wires around (to switch which is HD0 vs HD1), but that doesn't work with SATA
[02:14:14] <SWPLinux> grub-install /dev/hd0
[02:14:33] <jmk-robot> did that last night
[02:14:39] <jmk-robot> didn't seem to work
[02:14:53] <jmk-robot> it's not 100% clear how the devices are enumerated
[02:15:06] <SWPLinux> yeah, I was just thinking that
[02:15:11] <SWPLinux> but it's USB, not a CF slot?
[02:15:25] <jmk-robot> yes
[02:15:33] <SWPLinux> how much of a BIOS is there?
[02:15:44] <SWPLinux> ie, can you turn off USB legacy support?
[02:16:19] <jmk-robot> haven't read all the fine pring
[02:16:20] <jmk-robot> t
[02:16:28] <jmk-robot> I can turn usb boot on and off, or move it in the boot order
[02:17:15] <jmk-robot> this screen is cramped
[02:18:00] <jmk-robot> three of four smp kernel packages done
[02:18:08] <jmk-robot> (getting the source too)
[02:18:40] <SWPLinux> I was going to say ...
[02:18:57] <SWPLinux> so, was this hard disk used before or blank?
[02:19:12] <jmk-robot> it was infested with windows 98
[02:19:14] <jmk-robot> that has been fixed
[02:19:22] <SWPLinux> ok, so it should have a valid MBR
[02:19:39] <SWPLinux> you could try booting it in a desktop machine
[02:19:51] <jmk-robot> too much like work
[02:20:00] <jmk-robot> (the disconnecting and reconnecting and such)
[02:20:10] <SWPLinux> presumably you looked at the boot flag ...
[02:20:25] <jmk-robot> ISTR I looked yesterday
[02:20:34] <SWPLinux> and active
[02:20:43] <jmk-robot> I haven't messed with the "needs usb to boot" issue yet today
[02:20:52] <jmk-robot> too many open tasks
[02:21:36] <SWPLinux> I guess the worst solution is to leave the USB drive plugged in all the time
[02:21:52] <SWPLinux> "whatever works"
[02:22:10] <jmk-robot> because it "works", I moved on to RT kernels and such
[02:22:18] <jmk-robot> but I need (want) to fix it
[02:24:22] <jmk-robot> odd
[02:24:36] <jmk-robot> the packages I just (think I) installed don't appear in synaptic
[02:24:46] <jmk-robot> maybe because that repo isn't in its list?
[02:26:47] <jmk-robot> dpkg -l shows linux-image, -headers, and rtai-modules for the standard RT kernel (2.6.24-16)
[02:27:03] <jmk-robot> but only shows rtai-modules for the smp one (2.6.20-14)
[02:27:12] <jmk-robot> duh
[02:27:32] <jmk-robot> that's cause the smp one is called -magma, not -rtai, and grep can't read my mind
[02:31:46] <SWPLinux> heh
[02:35:59] <jmkasunich> bah, that kernel didn't add itself to menu.lst, and I forgot to edit it
[02:43:16] <jmkasunich> no joy - added it to the list, it appears on the menu, but "file not found" when I select it
[02:43:25] <jmkasunich> the image and initrd are in the /boot directory
[02:43:35] <jmkasunich> wonder if I typo'ed something dumb
[02:48:41] <jmkasunich> I did
[02:49:14] <jmkasunich> all the other kernels are 2.6.24-16-blahblah, the SMP one is 2.6.20.14-blahblah
[02:49:21] <jmkasunich> . instead of -
[02:57:04] <SWPLinux> heh
[02:57:07] <SWPLinux> gotta be something
[02:57:20] <SWPLinux> so here's a funny one:
http://www.newegg.com/Product/Product.aspx?Item=N82E16883220004
[02:57:27] <SWPLinux> note the quantity discounts
[04:15:48] <cradek> jmkasunich: iirc, grub-install '(hd0)'
[04:15:53] <cradek> yes with the parens for some reason
[04:16:20] <cradek> $ cat /boot/grub/device.map
[04:16:20] <cradek> (hd0)/dev/hda
[04:16:28] <cradek> ^ check this first
[04:16:30] <jmkasunich> I have some uncertainty about tha...
[04:16:36] <jmkasunich> ah
[04:16:58] <jmkasunich> the groot in menu.lst refers to hd1,0, which is uncommon - hence the uncertainty
[04:17:08] <jmkasunich> didn't think to check the map
[04:17:33] <cradek> mine says 'root (hd0,0)'
[04:18:58] <cradek> experience has taught me to solve this booting stuff before spending much time on configuring the system...
[04:19:58] <jmk-robot> what's that? ;-)
[04:20:30] <cradek> heh
[04:20:46] <jmkasunich> "mine" = your map? or your menu.lst?
[04:20:57] <cradek> sorry, my menu.lst
[04:21:06] <cradek> map is exactly what I pasted (one line)
[04:21:42] <jmk-robot> # groot=(hd1,0) <--- one of those automagic comments
[04:21:58] <jmk-robot> root (hd1,0) <--- every kernel in the menu
[04:22:01] <cradek> what's hd1 in device.map?
[04:22:16] <jmk-robot> jmkasunich@robot:/boot/grub$ cat device.map
[04:22:16] <jmk-robot> (hd0)/dev/sda
[04:22:16] <jmk-robot> (hd1)/dev/sdb
[04:22:29] <jmk-robot> that would imply booting from sdb
[04:22:30] <jmk-robot> but:
[04:22:31] <cradek> no wonder it can't boot
[04:22:42] <cradek> so I wonder why is the hard disk sdb
[04:22:53] <jmk-robot> its not:
[04:23:07] <jmk-robot> jmkasunich@robot:/boot/grub$ df
[04:23:07] <jmk-robot> Filesystem 1K-blocks Used Available Use% Mounted on
[04:23:07] <jmk-robot> /dev/sda1 9275996 4312016 4496492 49% /
[04:23:13] <jmk-robot> that is the hdd
[04:23:29] <cradek> ok, seems menu.lst and device.map are both wrong
[04:23:46] <cradek> err, device.map is fine
[04:23:48] <jmk-robot> here is another bit of oddness
[04:24:03] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/configs/hm2-servo/ (16 files): replaced m7i43_th with configs for all AnyIO boards
[04:24:07] <cradek> fix menu.lst to say (hd0,0) and run grub-install '(hd0)'
[04:24:19] <jmk-robot> wait a minute
[04:24:50] <jmk-robot> it looks like fstab is borked
[04:25:20] <jmk-robot> mtab:
[04:25:35] <jmk-robot> /dev/sda1 / ext3 rw,relatime,errors=remount-ro 0 0
[04:25:38] <jmk-robot> fstab:
[04:25:56] <jmk-robot> # /dev/sdb1
[04:25:56] <jmk-robot> UUID=d251d562-180e-4a9e-9d16-47d54516c402 / ext3 relatime,errors=remount-ro 0 1
[04:26:06] <jmk-robot> I just realised that the sdb part is a comment
[04:26:12] <jmk-robot> the UUID refers to the HD
[04:26:12] <cradek> yeah
[04:26:15] <cradek> right
[04:26:27] <jmk-robot> menu.lst:
[04:26:32] <jmk-robot> root(hd1,0)
[04:26:32] <jmk-robot> kernel/boot/vmlinuz-2.6.20.14-magma root=UUID=d251d562-180e-4a9e-9d16-47d54516c402 ro nosplash
[04:26:49] <jmk-robot> has UUID _and_ a root
[04:27:11] <cradek> root is the 'bios drive', UUID is the magic search for the root partition
[04:27:49] <jmk-robot> so, fix the comment in fstab to avoid hurting my lil' brain
[04:27:54] <jmk-robot> fix menu.lst root
[04:28:04] <jmk-robot> remove the line in device.map that refers to the usb stick
[04:28:12] <jmk-robot> and then do grub install
[04:28:22] <cradek> IMO, yes, all disclaimers apply
[04:30:46] <jmk-robot> here goes
[04:33:22] <jmkasunich> broke it good
[04:33:26] <cradek> arg
[04:33:32] <jmkasunich> still no grub at all with the usb stick out
[04:34:01] <jmkasunich> I get grub with the stick in, and it loads menu.lst from the HD, but when I attempt to boot a kernel from the HD, I get file not found
[04:34:12] <jmkasunich> it must be enumerating the devices wrong somehow
[04:34:28] <cradek> you can edit the grub settings before it boots - I forget how - read the screen
[04:34:55] <jmkasunich> you mean to get back to where I was, booting with stick, using kernel from disk?
[04:35:07] <cradek> I mean getting it booted so you can try again
[04:36:30] <jmkasunich> yeah, changed hd0,0 to hd1,0, and it is booting
[04:37:00] <cradek> did you check the bios settings for bogons about drive enumeration?
[04:37:12] <jmkasunich> not yet
[04:37:31] <jmkasunich> it's only sort of booting - X failed, I'm in a text mode root prompt
[04:37:38] <cradek> bleh
[04:37:43] <cradek> sorry I "helped"
[04:41:03] <jmkasunich> bios has "hard drive order" under the boot menu
[04:41:10] <jmkasunich> hard disk is first, usb second
[04:41:20] <jmkasunich> (it actually identifies them by make, model, etc
[04:44:18] <jmkasunich> restoring the 2nd line of device.map got me back to X
[04:44:37] <jmkasunich> apparently the x login screen uses that mapping to find its parts
[04:44:42] <cradek> I don't understand that
[04:44:48] <jmkasunich> me either
[04:45:41] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/configs/hm2-servo/ (8 files): get rid of CVS version clutter
[04:46:05] <jmk-robot> I think I have two independent problems
[04:46:14] <jmk-robot> 1) not booting at all from hard disk
[04:46:25] <jmk-robot> 2) grub trying to fetch kernels from the wrong place
[04:46:34] <jmk-robot> should probably fix #1 first
[04:46:55] <cradek> not sure you've managed to install the mbr there yet
[04:47:04] <jmk-robot> right
[04:47:10] <jmk-robot> grub-install is supposed to do that
[04:47:20] <jmk-robot> but if the enumeration is wrong, maybe I just installed it on the usb
[04:49:41] <jmk-robot> fdisk says no partitions are bootable
[04:49:47] <jmk-robot> gotta fix that, right?
[04:50:23] <cradek> ah, maybe
[04:52:06] <jmk-robot> changed and written, lets see what happens
[04:55:00] <jmk-robot> that should not have worked, but it did
[04:55:16] <jmk-robot> (it should have gotten into grub, then failed because of the hd1 thing)
[04:55:46] <jmk-robot> oh, I never "unfixed" menu.lst
[04:55:54] <jmk-robot> it still has hd0,0 as root
[04:56:06] <jmk-robot> so it should have worked, and it did!
[04:57:04] <jmk-robot> thanks!
[04:57:11] <jmk-robot> now sleep
[04:57:20] <jmk-robot> actually, I should start a latency test
[04:57:24] <cradek> heh
[04:57:25] <cradek> yay
[05:00:43] <jmk-robot> glxgears cruising smoothly (300+ fps), latency 14760
[05:01:20] <jmk-robot> opened foxfire, tried youtube but I don't have the player
[05:03:15] <jmk-robot> opened gimp, no change
[05:03:18] <jmk-robot> trying OO
[05:03:34] <cradek> what system is this?
[05:03:43] <SWPadnos> the little atom
[05:04:06] <SWPadnos> jmk-robot, is this with the SMP kernel?
[05:04:10] <jmk-robot> no
[05:04:13] <SWPadnos> ok
[05:04:21] <jmk-robot> smp kernel won't drive the network interface
[05:04:43] <jmk-robot> I may boot into it tomorrow and try the test, I don't need a net to run the maze
[05:04:44] <SWPadnos> ok, I wasn't sure that was the end result
[05:04:57] <jmk-robot> seems to be known bugs in the 2.6.20 version of that driver
[05:05:00] <SWPadnos> yeah, or video (X) really
[05:05:03] <SWPadnos> ah
[05:05:10] <jmk-robot> If I want an smp kernel, I'll have to build a newer one
[05:06:49] <jmk-robot> restarted the test - if I don't start glxgears, I'm at 8510
[05:07:18] <jmk-robot> glxgears instantly pops it up to 14xxx (14819 this time, 14760 last time)
[05:07:18] <cradek> have a url for the board?
[05:07:33] <jmk-robot> intel G945GCLF2
[05:07:54] <jmk-robot> I got mine from newegg, someone told me they're out now
[05:08:32] <SWPadnos> there are several boards that are similar to it, but no idea on latencies
[05:09:11] <jmk-robot> somebody robbed my xorg.conf
[05:10:05] <cradek> would be neat to get one for my car
[05:10:05] <SWPadnos> http://www.newegg.com/Product/Product.aspx?Item=N82E16813121359
[05:10:09] <jmk-robot> there is nothing of substance in there
[05:10:45] <SWPadnos> yeah, 8.04 (and later) xorg.conf files have no examples or markers for where you need to change things
[05:10:48] <SWPadnos> it's disconcerting
[05:11:13] <jmk-robot> not just no markers
[05:11:21] <jmk-robot> there is nothing in there to tell you what it is using
[05:11:26] <SWPadnos> no sections whatsoever
[05:11:32] <jmk-robot> Section "Monitor"
[05:11:32] <jmk-robot> Identifier "Configured Monitor"
[05:11:32] <jmk-robot> EndSection
[05:11:32] <jmk-robot> Section "Screen"
[05:11:32] <jmk-robot> Identifier "Default Screen"
[05:11:32] <jmk-robot> Monitor "Configured Monitor"
[05:11:34] <jmk-robot> Device "Configured Video Device"
[05:11:36] <jmk-robot> EndSection
[05:11:40] <SWPadnos> yeah, it auto-detects every time unless you tell it not to
[05:11:52] <SWPadnos> /var/log/Xorg.0.log will tell you
[05:11:59] <jmk-robot> fscking gawd damned microsoft followers!
[05:12:20] <jmk-robot> keep your bloody hands off my computer!
[05:13:05] <SWPadnos> huh. if you search NewEgg for "945GC", there are 31 items
[05:13:20] <SWPadnos> and some are quite inexpensive - like $40
[05:13:25] <SWPadnos> lower with rebates
[05:13:32] <jmk-robot> not small tho?
[05:13:57] <SWPadnos> mini-ITX, and some are shuttle mini systems
[05:14:47] <SWPadnos> oops, the inexpensive ones are micro ATX, which I think is just slightly smaller than ATX
[05:15:00] <SWPadnos> (and larger than mini ITX)
[05:15:36] <cradek> it's not as small as I thought
[05:15:38] <SWPadnos> the non-2 unit from Intel (same PN, no 2 at the end) is there, $69.99 with CPU
[05:16:12] <jmk-robot> I think that is single core
[05:16:21] <SWPLinux> her's my new favorite (but not for EMC):
http://www.newegg.com/Product/Product.aspx?Item=N82E16883220004
[05:16:22] <jmk-robot> it was reviewed in the same article in EDN
[05:18:40] <jmk-robot> looks like it is using the "i915" video driver
[05:18:49] <jmk-robot> might be interesting to see what happens with vesa
[05:19:08] <jmk-robot> holding at 15773
[05:21:21] <jmk-robot> btw, make -j<some-reasonalbe-number> doesn't crash the machine
[05:21:38] <jmk-robot> and with the non-RT SMP kernel, compiles go about twice as fast with j3 as without j
[05:22:03] <jmk-robot> and on that note, goodnight
[05:22:56] <SWPadnos> that makes sense
[05:22:57] <SWPadnos> see you
[05:41:11] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/configs/hm2-stepper/ (16 files):
[05:41:11] <CIA-2> EMC: replace hm2-stepper config with one that handles all AnyIO boards
[05:41:11] <CIA-2> EMC: (and is tuned for the steppers on my workbench)
[08:04:45] <alex_joni> seb_kuzminsky: whee.. that looks nice
[08:05:05] <alex_joni> it's probably lots easier on users aswell
[08:29:16] <CIA-2> EMC: 03alex_joni 07TRUNK * 10emc2/tcl/tkemc.tcl: apply fix from Dewey Garett - fix angular jogspeed value bug (if no DEFAULT_ANGULAR_VELOCITY was given any angular jogs were dropped)
[12:14:58] <micges_emc> When I've set motion.probe-input while homing there are two messages about error, "Probe tripped during homing motion.
[12:14:58] <micges_emc> Probe tripped during a jog."
[12:35:05] <alex_joni> better than no message :D
[12:44:38] <cradek_> those are both features. they would have saved your probe by stopping motion
[12:45:11] <cradek_> cradek_ is now known as cradek
[12:53:17] <micges> cradek: ok
[12:54:40] <alex_joni> I suspect the incorrect message comes from the free mode controller
[12:54:49] <alex_joni> but .. better 2 messages than none at all
[14:01:47] <cradek> oh you get them both at the same time?
[14:02:03] <cradek> that is a bug (minor) if so
[14:15:23] <micges_emc> cradek: yes minor, but bug
[14:34:33] <seb_kuzminsky> alex_joni: yeah thanks for putting that suggestion in terms i could understand ;-)
[14:43:16] <cradek> micges_emc: what version?
[14:45:37] <cradek> hm, sometimes I get only one error, sometimes 2 or 4
[14:45:44] <cradek> in trunk
[14:50:31] <cradek> up to two for each moving joint I think
[14:59:50] <cradek> now there are 18 messages...
[15:04:45] <CIA-2> EMC: 03cradek 07TRUNK * 10emc2/src/emc/motion/control.c: make sure the user gets the correct error, and only one error, when aborting due to an unexpected probe trip.
[15:07:25] <skunkworks> seems like the last few months have really added tons of features/fixes. Very cool. Nice work.
[15:14:06] <jepler> there has certainly been a burst of activitiy
[15:15:48] <cradek> I hope that's good...
[15:18:49] <cradek> (adding big features late is sometimes a bad idea)
[15:20:26] <skunkworks> na - just means they are in there if they need to be fixed. :)
[16:16:24] <alex_joni> seb_kuzminsky: hi again
[16:18:05] <seb_kuzminsky> hello
[16:18:35] <alex_joni> was wondering if you have some thoughts about the 7i64
[16:21:46] <alex_joni> I understand there's some support for it in the hostmot2 firmware, so the driver would need work, etc
[16:33:16] <jepler> cradek: that's why I built in a month for no new features before the betas and before creating the new branch
[16:33:52] <cradek> true (and smart)
[16:34:27] <alex_joni> yup, if people keep testing/fixing stuff :)
[16:44:06] <seb_kuzminsky> alex_joni: that's right, the hm2 firmware supports spi uarts, there'd need to be driver support
[16:44:14] <seb_kuzminsky> peter and i talked about this a bit
[16:44:39] <alex_joni> was wondering if there's a timeframe..
[16:44:44] <seb_kuzminsky> there's no real good way to probe for the slave at the end of the spi bus, but the driver needs to know what it is
[16:44:46] <alex_joni> 1 week/month/year/decade?
[16:45:02] <seb_kuzminsky> it's not on my short list ... :-(
[16:45:13] <alex_joni> I'm not trying to push you..
[16:45:22] <seb_kuzminsky> the driver would have to have a 7i64 sub-driver (like it currently has encoder, stepgen, etc)
[16:45:30] <alex_joni> a 'long period' is just as good for me atm
[16:45:42] <seb_kuzminsky> the user would have to tell the 7i64 driver to attach itself to a particular spi port
[16:46:03] <alex_joni> is the SPI p2p ?
[16:46:08] <alex_joni> point 2 point?
[16:46:12] <seb_kuzminsky> nothing too complicated software wise, though it makes the load-time configuration string even more awkward
[16:46:23] <seb_kuzminsky> i think so but i'm not sure
[16:46:40] <alex_joni> ok.. then it's a bit easier than point 2 multipoint :)
[16:46:48] <alex_joni> having more than one 7i64 on one spi port..
[17:36:57] <skunkworks> peter!
[17:37:22] <alex_joni> ! <-?
[17:37:28] <PCW> Alex: for 7I64 it will probably always have only one SPI per per card
[17:37:29] <PCW> Skunk!
[17:37:38] <alex_joni> PCW: ok, cool.. thanks
[17:37:41] <alex_joni> fair enough
[17:38:45] <SWPadnos> update speed gets slow if you chain a lot of them
[17:39:13] <PCW> Yes that why they are not chained
[17:39:53] <SWPadnos> do you recall offhand how many 7i64 are supported in the stock hostmot2 configs?
[17:40:42] <seb_kuzminsky> SWPadnos: 0 in the BIT files we currently have
[17:40:48] <SWPadnos> ah, ok
[17:41:13] <PCW> As many as you want basically. We have a little breakout board that supports 6 from one 50 pin FPGA conn
[17:41:16] <SWPadnos> I thought you had meant before that they're in the hardware but not supported in the driver yet
[17:41:38] <SWPadnos> ok. and what's the update rate/cycle time?
[17:41:50] <PCW> They are on the hardware, but not ant of the bitfiles EMC uses ATM
[17:41:56] <seb_kuzminsky> SWPadnos: afaik, the hm2 firmware source supports spi uarts, but no bitfiles exist that include them, and the driver doesnt support them
[17:42:11] <SWPadnos> ok, my misunderstanding - no problem
[17:42:15] <PCW> About 3/4 uSec for 24in/out
[17:42:23] <PCW> (3 or 4 )
[17:42:24] <SWPadnos> hmmm. interesting
[17:42:28] <SWPadnos> yep :)
[17:43:09] <SWPadnos> how long a cable do you suppose can be used to connect them to the anyIO board?
[17:43:39] <PCW> About 3 feet or so, its terminated TTL levels
[17:43:47] <SWPadnos> of course it's an update speed tradeoff
[17:43:57] <SWPadnos> lower clock rate may allow longer cable
[17:44:05] <PCW> Yes
[17:44:10] <SWPadnos> does the SPI block have adjustable read skew?
[17:44:39] <PCW> Not yet Every time I look at it I find something else to do...
[17:44:44] <SWPadnos> heh
[17:45:01] <SWPadnos> only a few crazies like me need it anyway :)
[17:45:35] <PCW> Actually I do want read skew adjust for the 7I65 anyway just have to grit teeth a bit-wrangle
[17:45:50] <PCW> s/a/and
[17:46:41] <PCW> Still need to finish autosend for buffered SPI interface also
[17:46:55] <SWPadnos> hmmm. what A/D is used on the 7i65?
[17:47:48] <PCW> AD7329
[17:48:36] <SWPadnos> I wonder if there's a 16-bit pin-compatible replacement
[17:49:52] <PCW> I kind of doubt it
[17:50:01] <SWPadnos> not at 1MSPS of course
[17:50:19] <PCW> Probably something similar though
[17:51:56] <SWPadnos> hmmm. 8 channels / bipolar / 16 bits is a tough one
[17:53:50] <SWPadnos> there's a 14-bitter
[17:53:57] <PCW> The 7I65 is not designed as a HS DAQ system it uses shared SPI data for cheapness, the 1 MSPS is not really usable
[17:53:58] <PCW> I just liked the AD7329s input ranges and shift clock
[17:54:03] <SWPadnos> the 7367
[17:55:21] <PCW> OK. Im also making a little test A-D for THC
[17:55:23] <PCW> BigJohn will test it
[17:57:40] <SWPadnos> well, that's good news and bad news. the bad news is that I can't just buy some 7i65 from you to replace the analog board I designed. the good news is that I actually make money on those boards :)
[18:00:32] <PCW> The 7I65 is really designed for servo use
[18:00:33] <PCW> The A-D is just a added gimcrack
[18:03:05] <skunkworks> ? a showy object of little use or value
[18:23:14] <PCW> Well I doesn't add much to the 7I65 cost and several people have asked for A-D capability
[18:25:22] <SWPadnos> with A/D it's possible to use analog tachs and close the velocity loop separately from the position loop
[18:26:00] <alex_joni> not if you have only one
[18:26:15] <SWPadnos> the 7i65 has 8
[18:26:29] <SWPadnos> 8 analog outputs, 8 analog inputs, 8 quadrature encoder inputs
[18:27:17] <alex_joni> missed the 8 x AD input
[18:28:02] <PCW> The 7I65s muxed encoders will need driver support as well (encoder counter register map is same but I/O allocation is different)
[18:28:55] <SWPadnos> how does the muxing work anyway?
[18:29:17] <SWPadnos> I saw you mention that earlier, but didn't understand where the muxing takes place
[18:29:37] <SWPadnos> (can't see how it could be the input pins, possibly overlaid registers ...)
[18:30:30] <PCW> 7I65 has 2-1 muxing so 8 encoder inputs use 13 wires instead of 24
[18:30:32] <PCW> 12 even/odd muxed encoder signal to FPGA and one mux drive out from FPGA
[18:31:13] <SWPadnos> ah, ok
[18:31:27] <PCW> Demuxing in FPGA before counters hides any difference to software
[18:31:36] <SWPadnos> righto
[18:31:52] <PCW> (other than I/O pin setup)
[18:32:54] <SWPadnos> if you have a 7i65, can those extra encoder input pins be used as GPIO?
[18:33:09] <SWPadnos> (with the muxing still enabled)
[18:33:46] <SWPadnos> that would be a PITA for the software :)
[18:35:06] <PCW> Not easliy but I have considered a virtual Input and virtual output pin PinDesc would make the accessible
[18:35:18] <PCW> (them)
[18:35:48] <SWPadnos> that would potentially be useful for the 7i64 as well
[18:35:59] <SWPadnos> since you get more I/Os than there are pins on the AnyIO board
[18:36:08] <SWPadnos> or pins used anyway
[18:36:14] <PCW> Yes
[18:36:55] <PCW> Well back to layout
[18:36:56] <PCW> BBL
[18:37:04] <SWPadnos> but you have to know the mapping of physical board pins to external virtual ones
[18:37:06] <SWPadnos> see you
[18:37:12] <alex_joni> have fun
[18:42:21] <jepler> oh darn, I missed him
[18:54:09] <stuste1> I was just reading this
http://www.linuxcnc.org/docview/html//motion_kinematics.html. The word
[18:54:32] <stuste1> 'axes' is correct according to Websters and Dictionary.com
[18:54:52] <stuste1> axes is defined as the plural of axis
[18:55:19] <stuste1> maybe it s/b axi or axii but it seems axes is suitable :)
[18:55:23] <cradek> hi stuart
[18:55:29] <stuste1> hi chris
[18:55:38] <alex_joni> stuste1: can you be more specific what you mean?
[18:56:07] <cradek> "When he is coming over, I'm always careful to hide the axes"
[18:56:18] <cradek> I've always been troubled that axes and axes are spelled the same
[18:56:23] <stuste1> at the bottom of the .html page is states axes is incorrect usage
[18:56:49] <alex_joni> stuste1: yeah in favour of joints
[18:56:53] <alex_joni> not some other spelling
[18:56:56] <cradek> stuste1: I think the objection is to using axis to refer to one motor/slide (joint)
[18:57:04] <cradek> it's not about axes being an incorrect plural of axis
[18:57:09] <stuste1> I am just reading to edukate myself on the kinematic data flos
[18:57:11] <stuste1> flow
[18:57:21] <alex_joni> The word .axes. is also commonly (and wrongly) used when talking about CNC machines, and referring to the moving directions of the machine.
[18:57:34] <alex_joni> moving directions of a CNC are joints
[18:57:42] <stuste1> oh ok
[18:57:46] <alex_joni> even if carthesian axes are aligned to the same directions
[18:58:00] <stuste1> yes I understand the difference
[18:58:19] <stuste1> I have had a crash course in kinematics the last few weeks
[18:58:25] <alex_joni> I can imagine
[18:58:48] <stuste1> when it seems I am almost there I find the end of the tunnel moved farther away
[18:59:12] <cradek> heck did you run into another problem?
[18:59:18] <stuste1> gdb is sweet - I get the values I want for most of it
[18:59:37] <stuste1> not in the C or kinematics - in the flow of data through the control
[18:59:46] <alex_joni> hmm.. how come?
[19:00:22] <stuste1> when I get a better handle on it I will be back with coherent questions
[19:00:26] <stuste1> I have to run
[19:00:32] <alex_joni> ok.. see you later
[19:00:35] <stuste1> I will be in Topeka this afternoon
[19:00:39] <stuste1> bbl - thanks
[20:04:15] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: allow the filename ~/.axisrc to be overridden by inifile [DISPLAY]USER_COMMAND_FILE (based on a patch from Dewey Garrett)