Back
[12:59:34] <qq-> psha, hey
[13:45:10] <cradek> jepler: did you ever use pluto step to run your machine?
[13:47:35] <jepler> cradek: yes. I have my config files from back then under git, in case they're of interest to somebody.
http://git.unpythonic.net/view?p=zenbot.git;a=tree;h=e01faccd047fdbf31ad2d3b694260f32ecc642ef;hb=e01faccd047fdbf31ad2d3b694260f32ecc642ef
[13:48:19] <cradek> huh, wonder what's different for this guy then.
[13:49:59] <jepler> I dunno
[13:50:35] <jepler> it was almost perfectly reliable for me. I recall one "weird, I wonder why that happened" following error. not that I operated it for a huge number of hours..
[13:51:56] <jepler> though I see my MIN_FERROR wasn't particularly small, 0.010in
[13:52:23] <jepler> but pluto has never worked as well for anybody else as for me
[13:54:14] <cradek> the pluto-servo works ok for me, when plugged into some machines
[14:30:46] <skunkworks> I only used the servo setup for pluto (cheap way to test my amps)
[14:30:51] <skunkworks> no issues.
[14:41:04] <jepler> skunkworks: sure you had issues, like "it works when I plug it into the back of the computer, but not when I use a cable"
[14:42:14] <skunkworks> jepler: yes - but you had fixed a lot of that. I remember you had change the timing for the port that pretty much made it work very well.
[14:42:34] <skunkworks> I have been using it with a short (2') cable.
[14:42:39] <skunkworks> I had been...
[14:50:56] <skunkworks> granted - if I was going to do it over - I would buy mesa.
[14:51:52] <skunkworks> I learned a lot with it. and it made it so I didn't destroy the mesa 5i20 by accident just goofin around.
[14:53:51] <jepler> before the mesa epp board and hostmot2, the pluto at least had a significant price difference in its favor. now it's got no significant advantage that I can see.
[14:54:00] <jepler> and so many people have trouble with it...
[14:54:56] <skunkworks> right
[15:16:42] <mozmck_work> why does the pluto have so many problems? bad bitfiles or hardware or both?
[15:20:07] <cradek> the hardware is defective
[15:23:23] <mozmck_work> I see. Looks like there's almost *no* hardware. Just an fpga soldered to a parport connector!
[15:23:43] <cradek> yep
[15:43:12] <jepler> pretty much it's as minimal as you can get. There'a a power/not-programmed LED, a single-transistor inverter, and a linear regulator that runs the FPGA at a voltage that is almost but not entirely outside its absolute maximum ratings
[15:43:43] <jepler> (you're supposed to run it with two power rails, 2.5v logic and 3.3v I/O, but iirc it's run with 3.3v logic and I/O)
[15:45:14] <jepler> oh, and an oscillator
[15:48:30] <jepler> oh, and surprisingly there are 22-ohm series resistors on the I/O pins on just one of the headers
[16:17:16] <andypugh> I have a query about pin naming.
[16:17:34] <andypugh> I am working on the Hostmot2 interface for Smart-Serial devices.
[16:17:58] <andypugh> (8i20, 7i44)
[16:18:42] <andypugh> Each header on the FPGA card can have up to 8 devices connected, so that's a max of 32.
[16:18:51] <qq-> * qq- ah that's those 8i20 things
[16:19:11] <andypugh> But there could be any combination of devices connected.
[16:19:26] <andypugh> I am wondering what a sane pin-naming scheme would be.
[16:20:00] <jepler> the first stepgen is stepgen.00, regardless of what pins or headers it's on..
[16:20:25] <andypugh> Indeed, and I could just label them sequentially as they are found.
[16:20:32] <jepler> so I'd say the first bitbucket would be bitbucket.00, regardless of what pins or headers it's on
[16:21:17] <andypugh> Well, you can't have a stepgen on the second set of stepgen pins without one on the first
[16:21:43] <andypugh> You say how many stepgens you want, and they are enabled in sequence.
[16:22:53] <andypugh> Typically the 8i20s would be connected by a 7i44 8-way CAT5 breakout, so it might make sense for the pn names to hint which socket the device is on.
[16:23:49] <andypugh> It seems too difficult to define the device layout in the hosmot modparam, so I am planning to interogate the devices to see what they are.
[16:24:42] <andypugh> so, the sserial modparam will be conf_sserial=0x000000FF to turn on the first 8 serial channels.
[16:25:03] <jepler> why not num_serial=8 to turn on 8 of them, just like stepgens..
[16:25:19] <jepler> then plug your first device into the first CAT5 port, and so on..
[16:26:24] <andypugh> It seems a little inflexible to mandate filling the plugs sequentially, is all.
[16:27:04] <andypugh> Perhaps there might be reasons to have some devices on one 7i44 and others on a different one, for example?
[16:28:00] <andypugh> It is probably bad to interrogate GPIO pins as serial ports, hence my bitmask idea.
[16:29:09] <jepler> stepgens could also use a mask instead of a count in principle, but in practice I don't think anybody's asked for it .
[16:29:14] <andypugh> I rather feel that the pin names for the various devices should indicate which port they have been found on.
[16:30:05] <andypugh> stepgens are typically hardwired to a breakout or daughter card. CAT5 cables rather invite shuffling...
[16:30:11] <jepler> until it's been in a stable release, we have plenty of latitude to change module parameters and pin/parameter names. I say go ahead with whatever idea you think is best
[16:31:56] <andypugh> I am thinking that the first 8i20 found, if it was on port 4 would be hm2_5i23.0.port.04.8i20.current rather than hm2_5i23.0.8i20.0.current
[16:32:29] <andypugh> But I am open to other ideas.
[16:33:21] <andypugh> Also, I am not yet sure how I will handle serial port instances having a number of possible devices connected. I am toying with using a Union
[16:33:46] <andypugh> But perhaps there is a better way.
[16:34:35] <andypugh> In effect it is going to need a structure similar to the FPGA card driver, on top of the FPGA card driver.
[16:35:03] <andypugh> (I can see I am going to be a much better C-coder at the end of this)
[16:43:06] <andypugh> Hmm, 32 x Smart Serial and 32 x 7i64 would be a _lot_ of IO. 768 pins, in fact.
[17:03:17] <SWPLinux> andypugh: this is a question that's been raised in a slightly different form for the PPMC as well. should the driver enumerate everything attached and name it, or should the user have to specify what *should* be found, and have the driver error out if that set of things isn't found?
[17:04:14] <SWPLinux> (or a combination - loadrt $mydriver -i(nterrogate) tells you what's found and prints a loadrt line to match, without the -i param, it errors if the right stuff isn't found ...)
[17:11:41] <mozmck_work> It would seem to me that having the driver enumerating and naming everything would make things easier for the end user.
[17:12:13] <SWPLinux> unless something doesn't work at some point
[17:12:43] <mozmck_work> yeah. You can always list stuff from HAL to see what's there can't you?
[17:12:46] <SWPLinux> there's no way to tell if a device isn't attached unless the user specifies what should be found, such that the driver can compare that to what is found
[17:26:38] <andypugh> That last point was why I wanted to use a bitmask, as trying to interrogate a GPIO pin (which might, for example, be a spindle-on relay) to seeif there is a serial device attached would be Wrong
[17:33:19] <andypugh> I think though, that enumerating the devices is the only sane way, as sserial can connect 32 devices, of a number of different types (currently only three, but likely to grow) and I can't see a neat way to define them in a modparam line.
[17:35:14] <jepler> whether it's by count or mask, we're going to make the user say which location(s) have sserial devices attached
[17:35:18] <jepler> after that, by definition it's OK to probe
[17:35:23] <jepler> .. for a specific device
[17:36:11] <andypugh> I ought to got on with it really.
[19:04:25] <qq-> psha, what do you think: better to adapt emc to rtai, or rtai to emc ?
[19:09:28] <psha> right way is to adopt rtai to fhs and emc to rtai
[19:09:53] <psha> but my laziness tell me that it's better to use naming scheme like in ubuntu
[19:09:54] <psha> :)
[19:10:16] <qq-> rtai is fhs , as i seen here
[19:10:39] <psha> too many garbage in /usr to be fhs
[19:10:39] <qq-> emc isn't
[19:10:51] <psha> emc just follows rtai layout
[19:11:49] <psha> give correct --with-module-dir to emc's configure script and it's fhs too
[19:12:11] <jepler> actually, there are problems if emc2's modules are placed in a directory that modprobe finds.
[19:12:35] <jepler> specifically, hm2_pci and all its dependencies will be loaded at boot time if one of those PCI cards is installed
[19:13:02] <psha> i suspected there is reason not to be fhs :)
[19:13:05] <jepler> I know this is normally a good thing, but for emc it's undesirable
[19:13:09] <psha> but was too lazy to investigate ;(
[19:13:25] <jepler> that's the big one I know of when it comes to our module location
[19:13:41] <jepler> and since we just install inside the rtai module directory, if it is in /lib/modules or if there's a symlink in /lib/modules, this problem occurs
[19:14:16] <jepler> it looks like we discovered this sometime in the 2009 timeframe.
http://mid.gmane.org/037101c96ea6$080101c0$6400a8c0@danalappy
[19:14:42] <jepler> er, 2008 I guess..
[19:15:56] <jepler> for stuff like what's in /usr/share vs what's in /usr/lib, I'd be pleased to add those kinds of improvements.
[19:16:22] <psha> share/lib is correct as far as i understand fhs
[19:16:57] <jepler> historically, "run in place" was the only choice for emc2; The "run installed" file layout was a rush job and has largely been unchanged since 2005 or so
[19:17:23] <cradek> I thought we fixed it up a little, to be more deblike for 2.4
[19:17:30] <cradek> where we = seb
[19:17:44] <jepler> oh, maybe there have been improvements that I've forgotten about
[19:18:33] <psha> your rtai-modules package is much cleaner then debian one
[19:18:42] <psha> at least it's possible to install two different versions...
[19:22:20] <psha> jepler: is it suitable solution to just kill all rtai modules on srartup?
[19:22:33] <psha> startup
[19:23:21] <jepler> mmmaybe
[19:23:21] <psha> i mean unload )
[19:24:03] <jepler> there might also be some way to change the hm2_pci driver so that it doesn't autoload ever
[19:24:03] <qq-> but using /usr/local/emc2 is not a choice ?
[19:24:33] <psha> qq-: if you are talking about package then local is not an option at all
[19:24:41] <jepler> qq-: there have frequently been bugs for any prefix besides --prefix=/usr .. I'd be happy to see fixes for any of those problems that you encounter
[19:25:08] <qq-> i see
[19:25:12] <jepler> (but since all I need in my own life are run-in-place and packages, the bugs don't ever bother me)
[19:31:50] <qq-> put it on blacklist (it== hm2_pci)
[19:32:31] <jepler> well actually I was thinking that being able to "modprobe" instead of "insmod" for hal modules would be a benefit
[19:33:20] <qq-> blacklist : In lenny and squeeze, create/edit /etc/modprobe.d/blacklist.local.conf and add a line similar to this (without quotes): "blacklist module_name". If this doesn't work, do 'echo "install modulename /bin/true" >> /etc/modprobe.d/blacklist.local.conf'. IMPORTANT: ask about <blacklist-initramfs>. To blacklist a module at installation time, ask me about <installer blacklist>.
http://wiki.debian.org/KernelModuleBlacklisting
[19:34:10] <jepler> hm, I wonder if simply commenting out MODULE_DEVICE_TABLE would do it
[19:36:19] <psha> qq-: blacklisted module may be loaded manually?
[19:36:47] <psha> i'll take a cup of tea
[19:37:01] <qq-> psha, i don't see why not
[19:37:07] <jepler> fg
[19:37:17] <jepler> oops
[19:54:40] <psha> * psha returned to foreground by jepler's request
[19:55:10] <psha> qq-: modprobe may complain about blacklisted module
[19:56:06] <qq-> maybe, not tested in emc environment
[19:56:33] <psha> oh
[19:56:39] <psha> blacklist is working just fine...
[19:57:19] <psha> so another solution is to generate blacklist file for _all_ emc2 modules
[19:57:21] <psha> for sure :)
[19:57:37] <psha> manual loading will work as desired
[19:57:45] <psha> and not at boot time
[19:59:31] <qq-> outside off context, my ubu-cnc in virtualbox freeze 'hard' .. heh