jepler: did you ever use pluto step to run your machine?
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
huh, wonder what's different for this guy then.
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..
though I see my MIN_FERROR wasn't particularly small, 0.010in
but pluto has never worked as well for anybody else as for me
the pluto-servo works ok for me, when plugged into some machines
I only used the servo setup for pluto (cheap way to test my amps)
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"
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.
I have been using it with a short (2') cable.
I had been...
granted - if I was going to do it over - I would buy mesa.
I learned a lot with it. and it made it so I didn't destroy the mesa 5i20 by accident just goofin around.
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.
and so many people have trouble with it...
why does the pluto have so many problems? bad bitfiles or hardware or both?
the hardware is defective
I see. Looks like there's almost *no* hardware. Just an fpga soldered to a parport connector!
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
(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)
oh, and an oscillator
oh, and surprisingly there are 22-ohm series resistors on the I/O pins on just one of the headers
I have a query about pin naming.
I am working on the Hostmot2 interface for Smart-Serial devices.
Each header on the FPGA card can have up to 8 devices connected, so that's a max of 32.
* qq- ah that's those 8i20 things
But there could be any combination of devices connected.
I am wondering what a sane pin-naming scheme would be.
the first stepgen is stepgen.00, regardless of what pins or headers it's on..
Indeed, and I could just label them sequentially as they are found.
so I'd say the first bitbucket would be bitbucket.00, regardless of what pins or headers it's on
Well, you can't have a stepgen on the second set of stepgen pins without one on the first
You say how many stepgens you want, and they are enabled in sequence.
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.
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.
so, the sserial modparam will be conf_sserial=0x000000FF to turn on the first 8 serial channels.
why not num_serial=8 to turn on 8 of them, just like stepgens..
then plug your first device into the first CAT5 port, and so on..
It seems a little inflexible to mandate filling the plugs sequentially, is all.
Perhaps there might be reasons to have some devices on one 7i44 and others on a different one, for example?
It is probably bad to interrogate GPIO pins as serial ports, hence my bitmask idea.
stepgens could also use a mask instead of a count in principle, but in practice I don't think anybody's asked for it .
I rather feel that the pin names for the various devices should indicate which port they have been found on.
stepgens are typically hardwired to a breakout or daughter card. CAT5 cables rather invite shuffling...
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
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
But I am open to other ideas.
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
But perhaps there is a better way.
In effect it is going to need a structure similar to the FPGA card driver, on top of the FPGA card driver.
(I can see I am going to be a much better C-coder at the end of this)
Hmm, 32 x Smart Serial and 32 x 7i64 would be a _lot_ of IO. 768 pins, in fact.
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?
(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 ...)
It would seem to me that having the driver enumerating and naming everything would make things easier for the end user.
unless something doesn't work at some point
yeah. You can always list stuff from HAL to see what's there can't you?
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
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
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.
whether it's by count or mask, we're going to make the user say which location(s) have sserial devices attached
after that, by definition it's OK to probe
.. for a specific device
I ought to got on with it really.
psha, what do you think: better to adapt emc to rtai, or rtai to emc ?
right way is to adopt rtai to fhs and emc to rtai
but my laziness tell me that it's better to use naming scheme like in ubuntu
rtai is fhs , as i seen here
too many garbage in /usr to be fhs
emc just follows rtai layout
give correct --with-module-dir to emc's configure script and it's fhs too
actually, there are problems if emc2's modules are placed in a directory that modprobe finds.
specifically, hm2_pci and all its dependencies will be loaded at boot time if one of those PCI cards is installed
i suspected there is reason not to be fhs :)
I know this is normally a good thing, but for emc it's undesirable
but was too lazy to investigate ;(
that's the big one I know of when it comes to our module location
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
it looks like we discovered this sometime in the 2009 timeframe. http://mid.gmane.org/037101c96ea6$080101c0$6400a8c0@danalappy
er, 2008 I guess..
for stuff like what's in /usr/share vs what's in /usr/lib, I'd be pleased to add those kinds of improvements.
share/lib is correct as far as i understand fhs
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
I thought we fixed it up a little, to be more deblike for 2.4
where we = seb
oh, maybe there have been improvements that I've forgotten about
your rtai-modules package is much cleaner then debian one
at least it's possible to install two different versions...
jepler: is it suitable solution to just kill all rtai modules on srartup?
i mean unload )
there might also be some way to change the hm2_pci driver so that it doesn't autoload ever
but using /usr/local/emc2 is not a choice ?
qq-: if you are talking about package then local is not an option at all
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
(but since all I need in my own life are run-in-place and packages, the bugs don't ever bother me)
put it on blacklist (it== hm2_pci)
well actually I was thinking that being able to "modprobe" instead of "insmod" for hal modules would be a benefit
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
hm, I wonder if simply commenting out MODULE_DEVICE_TABLE would do it
qq-: blacklisted module may be loaded manually?
i'll take a cup of tea
psha, i don't see why not
* psha returned to foreground by jepler's request
qq-: modprobe may complain about blacklisted module
maybe, not tested in emc environment
blacklist is working just fine...
so another solution is to generate blacklist file for _all_ emc2 modules
for sure :)
manual loading will work as desired
and not at boot time
outside off context, my ubu-cnc in virtualbox freeze 'hard' .. heh