how's things? still travelling lots?
My travel this week got pushed to next week.
So some most of this one.
rayh: you've been away lots :D
typing is easy to forget :))
yes I have.
he's tired of us :)
(not that I should talk, I've been away lots also)
What do you guys think of an all xml configuration
I'd love it, if the files were human-readable
I'dstill accept it, even without human-readable files
I'd like a web enabled reader.
how do you mean?
Well xml can be parsed and the markup hidden.
That is a part of the reason for it.
I'm not quite sure we can move everything into xml
and I'm certain it won't gain any advantages with novice users
except that they won't be able to edit them any more..
I can understand that.
rayh: I'm not saying I'm against the idea (just to clear that up)
I'm saying that if we do go to the xml approach, then we need a config editor
the main advantage I see is that all configuration data could be contained in one file
because people won't be able to do it manually
SWPadnos: yeah, that's an advantage
but if you imagine HAL embedded in xml.. I'm not so sure
I think it's a pretty big advantage, actually
probably there are ways I don't grasp
yes, HAL configuration could be embedded in XML, but I'm not sure we could create a DTD for checking it
unless the DTD were generated by the make, so all possible command names (and config parameters) were part of it
that would make third-party components problematic
SWPadnos: not sure how to instruct users to add stuff
you don't know the list of pins and parameters a priori
yep - that's a big problem
it's one of hte issues with creating a GUI HAL editor as well
SWPadnos: unless the editor works on a live system
add component (loadrt in the background)
true, though you still can't tell if the component loaded in the intended configuration
and you can't create configs on a system that doesn't have the intended hardware
I intend to add a simple documentation mode to 'comp', which would allow the user to document the component, pins, and parameters in the source file
e.g., pin in0 float in "non-inverting input of the comparator";
jepler: nice idea
My thinking with respect to hal config is that we need a single file that has a structure that allows editing and saving using a gui based editor.
I wonder if it's feasible to do something similar by scanning the C source files for MODULE_PARAM and friends
I don't so much mind the idea of requiring that HAL be running with the proper hardware.
It should be possible to make those strings appear in "modinfo" but I haven't worked out the details yet
rayh, the problem is with one of us trying to help someone, for instance
I agree with ray and think the ONLY reason to go to xml, or make any other sweeping change, is to move toward full gui config editing
If the HAL data were stored in an xml file it would make editing from a gui possible.
xml may be part of that but I think it makes sense to talk about the big picture before these kinds of specifics (particular file formats)
I think that might get rephrased to "the only SANE moment to switch to xml is when we have full gui config editing"
That is the wall I ran up against with Hal Show
rayh: hal show works great
Except no save when you add or subtract or change stuff with the line editor
rayh: I doubt anyone does that :)
but it's great for watching, showing, etc
I know you had a great goal in mind
we have a chicken and egg problem if we want to both write a full gui editor and a change to a new config file format
but I don't think it's doable :( .. people like the click approach better than command line
a bit optimistic I think now.
cradek: the full gui editor is on the todo list for a few _years_
unless there's a way of generating "sim" modules, that you can tell what hardware they should emulate (or fake), it'll be very hard to make a GUI HAL editor
The netlist save thing works.
SWPadnos: like I said.. it can only work properly on a live system
it's generating the netlist that I'm more concerned about
and the GUI to tell you what is really happening
even on a live system, it's difficult. you need to be able to remove and re-load modules, such as blocks, when you want to add another functional block
though the GUI should keep track of the necessary connections, so that shouldn't be too bad
SWPadnos: one day you won't need that
and with jepler's comps it's getting closer :)
heh - true enough
HAL 3.0 ;)
each thing separately
on HAL 3.0 you don't need to unload/load stuff for changes
there is a branch for HAL refactor where this already kinda worked
using iopl calls
yep - kinda
but that was code from more than a year ago
* alex_joni uses them scarsely, and still messes them up
Is this ioctl/iopl thing something that has a known set of possible commands and responses?
rayh: it's a mechanism to send data from userspace to kernelspace
you implement some function numbers, and then can use those
ioctl = I/O Control. it's used for setting things like file options, serial port baud rates, etc.
for instance there are ioctl functions on serial port drivers (to set baud rate & all)
which are kinda standard
alternatively, it can be used for generic requests into the kernel
hi guys, looks like i'm falling in the middle of an interesting discussion
rayh: this is Bas, new developer who has worked on backlash compensation
Bas: ray is our resident emc loudmouth
indeed he is.. he said it himself :)
cradek: and what's your function ;-)
sjml: we do have these talks about interesting topics once in a while..
sjml: you're addressing the Chair Person :P
chair person of the board of directors :))
sjml: I fix bugs mostly, but I also irritate people and have other functions too
ok, getting the picture :)
question: what do you intend to use the ioctls for ?
things like creating/deleting threads, and creating/deleting functional instances of HAL components
ok, so this is no high speed thing
sjml: no, only configuration stuff
no, not for RT stuff
where do you get the file descriptors to ioctl on? something in /proc? /dev?
but no other way to get things from user space to kernel space
i've used the /proc in the past for this
something like /proc/hal
[20:07:28] <alex_joni> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/?only_with_tag=halrefactor-0-1
As it is now we use loadrt and send a set of args with it.
i personally hate ioctls, using proc can make thing much more accessible
I think we're in waters where I don't know anything, so I'll watch you guys discuss
the ioctl would allow mods to a module after it has loaded?
[root hal]# insmod hal_lib.o
[root hal]# insmod blocks.o
[root hal]# echo "blocks mux2" > /proc/hal/create
[root hal]# cat /proc/hal/show_blocks
0: blocks mux2
[root@vader hal]# cat /proc/hal/show_components
but so could proc
ioctl seems so primitive to me
that's a paste from what zwisk got going ..
and a cat /proc/hal/xx would produce a report?
rayh: like you do cat /proc/version or /proc/cpuinfo
imagine all pins/signals and their values being available in /proc
like the halcmd produces for us now.
What about making changes to modules? Say blocks for instance.
like alex said
rayh: look above
echo "add blocks mux2" > /proc/hal/create
echo "blocks mux2" > /proc/hal/create
without the add
would create a new mux2
I suppose there would be a /proc/hal/remove, and you'd echo something lioke "blocks mux2.2" > /proc/remove to delete something
but as this all is not really implemented.. it's open for discussion :)
why show_blocks? we have a tree here, I thought the idea is to treat it like the filesystem
cradek: sane too
I suppose that should be more like /proc/hal/modules/<module_name>
yeah something like that
If a block module is in the kernel, can we add to it or change it.
overall hal stuff in /proc/hal, subdirs like pins, signals, modules, threads ...
sjml: this is the _perfect_ example for one of our discussions, and the level of digression
echo 1 >/proc/hal/modules/blocks/mux2/0/input1
sjml: remember.. it started with XML :)
rayh: yes surely so
missed that part, will have been fun ;-)
rayh, that's independent of this discussion, and planned (hoped) for the next major revision of HAL
sjml: there's a logger usually around
rayh: there's no reason why we can't do that now, except it's not written that way
sjml: another logger in #emc (logger_aj)
we don't have a good userspace<->kernel communications scheme
yes insmod arguments are a bit limited
shmem could be used, but it requires programs that can deal with shmem and the like (and C structs)
a la halcmd
[20:17:57] <jepler> http://linuxcnc.pastebin.ca/176618
something like this would be quite adequate for any component that is not "variable"
there is quite some stuff added to the hal_refactor
[20:18:58] <alex_joni> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/Attic/hal_refactor.c?rev=126.96.36.199;content-type=text%2Fplain;only_with_tag=halrefactor-0-1
but how would this work for hal_parport, or any other device where you have flexible functionality?
even variable ones, as long as the variation is controlled by insmod parameters instead of hardware detection
any gui configurator would need very special knowledge
but wouldn't we use xml ? :-]
or we'd need to make userspace detection / pin creation program along with the drivers
ie, ppmc_pins USC@378:1
or ppmc_detect ...
(picking on that one since I think it's the most variable)
are there still a number of "personalities" that you could enumerate?
you'd have to know exactly what's connected, and where
the hardware can have any grouping of devices, split into 16 chunks of the address space
so there are a lot of possibilities
plus the fact that you can have multiple parallel ports with devices attached
other than IO provileges, there's no reason the detection code (or even the whole driver) can't be compiled into a userspace app
so the hypothetical configuration would just run some external program, and it could print something in a like format to my 'modinfo' output.
the external program could do whatever it likes
or it could actually create pins and functions, assuming that userspace functions are doable with HAL
jepler: userspace functions.. not really
there are no userspace threads afaik
true - no threads, but all we need are the function names, for a GUI config tool
SWPadnos: I think there's no way to register userspace functions
but that's only a SMOP
the NSSMOP is automagically making a userspace version of the driver ;)
SWPadnos: and from there it's quite easy to generate the comp automagically
with the pin info embedded of course
but modules like ppmc have variable pin info, depending on detected hardware
right.. run the userspace thing to detect
and generate the RT part with all the info in it
it may make more sense for userspace to do detection chores - it would simoplify the kernelspace portions of the code
yeah, that's what I meant
oh, ok ;)
but probably lightyears away :P
I wasn't sure if it was just me - I have a terrible cold and am not thinking well
shall we 'return ;' a couple of function spawns ?
get back to the initial talks :)
sjml: still around?
yes, just had to look in the sources what ppmd did!
back all the way to XML?
SWPadnos: wouldn't go that far :)
ppmc is likely the most complex driver
ppmc is a driver for jon elson's boards
[20:38:47] <alex_joni> http://pico-systems.com/motion.html
i saw, it's also using the parport, just like my driver
sjml: indeed.. I was meaning to ask you that..
can you describe your work in a few words?
phew, a few words...
I heard bits and pieces about FPGA, parport, communications :)
oh, I think I missed that :)
SWPadnos: wasn't very loudly spoken :)
i've build a 3-axis servo controller which can operate stand-alone as DRO or as interface to EMC
sjml: so it's doing analog output for servos and encoder input ?
besides the comms to emc ?
it's very compact and operates with dc motors i got from old plotters
since the pc i'm using has no slots, i've used the parport to interface to a controller
that communicates with the motor controller via a serial cable :-)
motor controller beeing the motor driver ?
i'll try to post some pictures soon
motor controller (called ms245) is one small box combined with the DRO
i need to make a pcb for the interface someday, it's a proto just now
I can probably help with that
though I don't have Eagle or any other free/inexpensive PCB CAD system, so the source files wouldn't be editable (gerber outputs would be OK though)
SWPadnos: don't tell Bas how much you payd for PCB editing..
SWPadnos: i've done all myself, but everything is going fast now and i don't have much spare time
alex_joni, I won't - it's embarrassing ;)
SWPadnos: you'll scare him for good
heh - he may think I'm a profesional though
err - professional
I have a very expensive schematic/FPGA/PCB package, since I'm an independent electrical engineer/programmer
ah, like me!
but my package probably isn't that expensive, at least not embarrassing :-)
it's not _that_ much
over here you get 2 new cars for that money :)
oops, sounds like the real stuff! and the yearly fee will also be impressive
are you using mentor or what?
I paid $99 for mine... I'm 1/120th as much a professional
heard of it, but not used it.
cradek: so you're an eagle user ?
actually, you're getting 120x the bang for the buck ;)
autogenerated manpage: http://emergent.unpy.net/files/sandbox/comp.9.txt
good inexpensive product, although improvements come slow nowadays
just to change the subject: what about the discussion of yesterday (shown tool size) ?
sjml: I don't think anything's been done
no, but i've looked in the sources and came up with a question.
just have to find the question,....
i'm not a python expert, so just to make sure: what does vars.metric.get() return ?
is this the gui choice for inch/mm display :?
if so, can't we assume that a metric guy will use a metric tool table and vice versa ?
that would make an easy workaround until a final solution is found
vars.metric.get() returns a true value if the current display is metric
what about my assumption?
it'll still be wrong in some respects, but it might give better results than now
did you test it that way?
yes, but i'm not sure i tested it completely for inches
i've a patch that i can mail, but it's so easy anyone can reconstruct it
or shall i commit it to head for testing ?
if it makes things worse for somebody, we'll hear about it
we'll have to fix the tool table right one of these days
it's official ;)
emc is in columbia now :P
cradek: the guys from the cool tool are somewhere around there
jepler: i noticed your comp's, are these going to replace the c-code or is it documentation only?
sjml: they can replace the c-code
it's actually a way to easily/fast write new HAL modules
is this functional or work in progress ?
but you need some deps
of course, yapps... where did i put my yapps...
so should i port my new components to comp's after i find my yapps???
ah, should have guessed: a parser generator.
it's getting late, i'm off.