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