00:16:25 * chinamill is away: fixing mill 00:17:47 quick note for the logger 00:18:34 we set up a rotary axis in HAL and EMC for chinamill and added a page to wiki 00:35:10 http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?SampleParport 00:35:21 page needs a lot of editing and additions. 00:38:01 rayh has quit 02:07:02 alex_joni has joined #emc-devel 02:25:45 rayh has joined #emc-devel 02:26:16 rayh: I didn't reply to your message but I think it's very good 02:26:47 Okay I'll send it soon. 02:26:55 thanks 02:27:10 oops, wrong channel 02:27:11 oh well 02:27:27 not a problem. 02:27:37 unless you are as old as I am. 02:32:23 probably the others have no idea what you are talking about :) 02:47:57 alex_joni is now known as alex_joni_away 03:26:52 alex_joni_away is now known as alex_joni 03:27:07 jmkasunich has joined #emc-devel 03:36:05 jmkasunich: join the board channel please ;) 03:36:48 I did dammit (the old one ;-) 03:37:09 do that every time. 03:37:51 jmk: autojoin list ;) 03:38:04 I'll ask paul today if I find him 03:38:10 jmkasunich: is that bug in stepgen's accel that you found recently possibly causing my spurious joint following errors? 03:38:22 I was trying to do something like that, either ksirc doesn't do it, or I'm too dense to figure it out 03:38:38 cradek: could be 03:38:42 easy to test 03:39:07 somewhere in your hal file (core-stepper.hal I think) is a line like: 03:39:27 wait, I'm not there, I'll be there later 03:39:29 setp stepgen.0.maxaccel [AXIS_0]MAX_ACCEL 03:39:34 change it to: 03:39:55 setp stepgen.0.maxaccel oh, ok, that's easy 03:55:46 SWPadnos has joined #emc-devel 03:57:10 SWPadnos: morning. 03:57:16 morning 03:57:48 I put one page of HAL tickle on linuxcnc.org this morning. 03:57:54 so cradek gets "Chairman", and you get "Loudmouth" ;) 03:58:02 ok - cool. I'll take a look 03:58:20 what is hal tickle? 03:58:27 it's a virus 03:58:35 slowly taking over HAL :D 03:58:45 it's what you get in your throat just before a cold ;) 03:58:49 uh, oh 03:58:54 it's some tcl code ray did to show HAL status 03:59:01 where? 03:59:02 www.linuxcnc.org/Dropbox/hal_show.tcl 03:59:08 to be able to do IOShow, or something like that.. right ray? 03:59:12 I think the idea is to make a tuning app 03:59:48 I used a very rough draft of the front page about 4 this morning to get chinamill going 03:59:54 with a rotary 4th 04:00:22 so where in my tree do I put it, and how do I invoke it? 04:01:09 in the emc2 directory and ./hal_show.tcl 04:01:24 while emc is running I assume? 04:01:29 you'll need a running hal to get much out of it. 04:01:36 Way ahead as always. 04:02:02 I'll take a look once (a) my coffee has brewed, and (b) I've booted the emc machine ;) 04:02:25 k 04:02:31 eek... (mini scares me when it pops up over the whole screen ;-) 04:02:34 SWPampy: get that coffee already ;) 04:02:45 it's brewing - you can't rush that 04:02:56 (sadly) 04:03:07 I didn't think mini was an option in the emc.ini 04:03:29 I have my sim.ini set up to run mini (don't recall why) 04:03:38 that's in CVS I think 04:03:45 I think all the UIs work - it's backplot that had some weirdness in AXIS 04:03:56 must have been me.. when I added mini to emc2 04:03:57 :( 04:04:06 ok - that could be 04:04:16 what's wrong with AXIS? 04:04:34 way back, didn't you have to fix something to get it to work with emc2? 04:04:55 we've had to catch up with emc2 changes many times 04:05:12 is 04:05:14 oops 04:05:15 maybe I misunderstood - are you saying there's something wrong with it now? 04:05:30 is "show_ HAL" the only window that works so far? 04:05:48 nope 04:05:54 nope to cradek 04:06:05 ok, forget I said anything 04:06:15 no prob 04:06:26 Right jmkasunich 04:06:59 halcmd without the typing! 04:07:21 But I was able to use it rather easily to illustrate how an axis (not the gui) pin can be followed through to signals 04:07:48 yeah, having it right there makes it much easier to talk a person thru things 04:07:49 and how to model one axis pins and params to make another. 04:08:34 are the screens live, or do you have to hit the show button to refresh (say after you've changed a param value, or added a signal) 04:09:02 the watch screen is intended to be live for the pins you select 04:09:12 ok, the show screen is a snapshot 04:09:25 Yes. World view if you will 04:09:41 * alex_joni pays a visit to the doc 04:09:43 later guys 04:09:44 although if you enter iocontrol in the search and press pins you get only those. 04:09:45 the file menu: what is that for? 04:09:47 bye alex 04:09:52 hope he can cure you 04:09:53 good luck 04:09:57 yeah.. thanks 04:09:59 alex_joni has quit 04:10:17 nice (the search) 04:10:28 I can see me using this a lot 04:10:28 I'm working there toward reading hal files and editing to match config setup. 04:10:51 I need to pass an idea to you. 04:10:51 you know about halcmd save don't you? 04:11:15 a separation between loadxx files and linkxx files 04:11:15 (although that loses any comments in the original file, and doesn't handle insmod command line params) 04:11:24 shoot 04:11:41 that's the idea I had. 04:11:54 elaborate a little please? 04:12:07 I think I know what you are talking about 04:12:07 It pretty much would hide the hal file that is run. 04:12:21 ok, I don't know what you are talking about ;-) 04:12:27 we could issue the load commands from the ini file 04:12:52 load what? a hal file? 04:12:55 then we can read, save, and run a hal file 04:13:02 from halcmd 04:13:20 no loadrt xxx 04:13:34 oh 04:14:10 not so much "no loadrt xxx" but "no loadrt xxx in the .hal files that connect everything together" 04:14:25 you could have one hal file that just loads everything, invoke that one first 04:14:25 right. 04:14:40 then invoke another(s) to do the config 04:14:53 yes and we could make a page just for it in the tickle 04:15:05 you are working toward one .hal file for the entire configuration, aren't you? 04:15:30 right now i don't know how to do otherwise. 04:15:40 (as opposed to core-servo.hal+ppmc-motion.hal+ppmc-io.hal+custom.hal) 04:15:48 within the hal_show context 04:16:00 yes. 04:16:14 right now, each individual file adds something to the config 04:16:30 but halshow can only show (and you can only save) the whole thing 04:16:53 there are pros and cons to both approaches 04:17:01 The multiple file approach is easier to understand when you work directly from a text editor. 04:17:04 SWPadnos_ has joined #emc-devel 04:17:15 the "sum of many configs" approach lets you use "standard" chunks 04:17:31 the "all in one" approach makes file management easier 04:18:02 there's another way to look at that 04:18:40 when you load a module (at least the motion-related ones, like PID and the like), there are some connections that are very likely to be made 04:18:42 hmmm, maybe we want to transition over to the all-in-one approach, but have a "new config" wizard that asks questions and loads some of the core files based on the answers....then saves the combined config for further tweaking 04:18:51 like pid.0 inputs go to axis.0 outputs 04:19:20 swp: yes, that was the intent of the core_xxx files 04:19:34 right - they can only connect "upstream" by default 04:19:49 swp and I were talking about agregating pins into a plug the other day 04:20:06 like a LabView bundle- if that helps 04:20:24 not really, I'm aware of labview, but never used it 04:20:52 what I did with chinamill this morning would have been easy if there were a "axis" plug 04:21:07 however, on the "someday" list for HAL, I was thinking of the ability to wrap a group of blocks and signals into a "megablock" 04:21:15 you can basically have a signal that consists of a struct of other signals 04:21:19 exactly. 04:21:43 rayh: which one did you "exactly" to? 04:21:52 jmk 04:22:26 I used the example of the lego blocks 04:22:34 to think about it. 04:22:48 thing is, swp's approach would be prettier 04:22:53 all of these pins fit into all of these. 04:23:11 at what level do you see the pretty? 04:23:15 code 04:23:17 user 04:23:24 hal file 04:23:38 my megablocks would still have individual pins at their border, and would still need to be conneted one-at-a-time to the next (mega)block 04:23:52 sub-sheets with ports 04:24:10 I was thinking sub-sheets, but not ports 04:24:22 the ports are the exported pins (in Protel) 04:24:31 external sheet connections 04:24:40 and worse (depending on your point of view), once loaded, in halcmd it would still be flat 04:24:43 ah -I see now 04:25:00 are ports a single signal, or multiple? 04:25:11 if you add a "subcomponent" field, you can get rid of all of them at once 04:25:20 single pin (or bus, in the schematic model) 04:25:30 ok, then with ports 04:25:37 actually, a bus is similar to the bundle idea 04:25:47 ( I thought maybe "port" was the "plug" thing you mentioned earlier) 04:25:48 just with different types 04:25:52 nope 04:25:53 bus is homogenous 04:26:40 well - you can have a bus with address and data pins, but you wouldn't usually group analog and digital llines ;) 04:26:48 both in type, and in usage (usage is up to the guy drawing the schematic, but I for one never grouped things like rd strobes and wr strobes into a bus) 04:27:14 I see busses as more like arrays than structs 04:27:18 yep 04:27:24 hence the "bundle" term 04:27:26 your "plugs" are structs 04:27:34 yes 04:28:09 connecting plugs means verifying that their structs match 04:28:24 would you require just a type match, or a name match 04:28:28 I think name 04:28:44 that is limiting tho 04:28:55 type only - there's no need to have names match now (using signals) 04:29:27 you don't automatically connect things (you meaning HAL) 04:29:28 ok, if a plug has 3 analogs and 3 bits, how do you define which analog on one side connects to which on the other 04:29:37 analog 1 connects to analog 1 04:29:42 analog 2 to analog 2 04:29:43 etc. 04:29:52 they are structs, so they should match 04:29:52 ok, so ordered by some number 04:30:07 yes - all connections are made / broken in one go 04:30:08 I thought of em as an array 04:30:10 structs is just a concept, there are no actual C structs here 04:30:17 I understand 04:30:17 matching arrays 04:30:19 so we have to define the order 04:30:22 just for discussion 04:30:34 arrays can only have one type, I 04:30:34 ray: in C, arrays means a group of identical typed items 04:30:47 you can have an array of bits, or an array of floats, but not a mixed array 04:30:55 structs allow mixing 04:31:00 arrays can only have one type, I'm thinking of something that you could connect an enable and a float output togeher with 04:31:02 so they are more appropriate here 04:31:04 I guess I'm still thinking geometry and the notion of plugs 04:31:31 antenna array not a c array. 04:31:32 sure - you take the nice MS circular connector and plug it into the correct socket 04:31:46 actually - any matching socket 04:31:53 Right and the rotation is handled by the index slide 04:32:06 rayh: there are some physical plugs where not all pins are the same 04:32:07 yep -that's the "type" in this discussion 04:32:14 like the MS connectors 04:32:26 certainly 04:32:29 skinny ones for logic, fat ones for power, maybe even coax ones for RF, all in one housing 04:32:38 that's the model I have in my head 04:32:39 exactly 04:32:49 yes - and location is significant 04:33:37 My thought this morning was something like 04:33:53 I was thinking that when you define a plug, you say: "plug pin connects to signal " 04:33:56 axis.3 ==> stepgen.3 04:34:13 where axis.3 is a plug 04:34:21 right - jmk, the idea is to be able to plug groups of things all at once 04:34:22 (and so is stepgen.3) 04:34:28 yep 04:34:30 so how to define a plug 04:34:39 beats me. 04:34:41 that's a darned good question 04:34:49 that's your job ;) 04:34:52 thats what I'm brainstorming 04:34:57 we're brainstorming 04:35:04 oh - right 04:35:05 within the plug are pins 04:35:11 well - you can take a cue from C++ 04:35:22 (plug pins, not hal pins - damn terminology) 04:36:03 the way that C++ keeps different versions of functions straight is by appending a string that tells the tpyes the function takes and returns 04:36:23 I want more than just type matching 04:36:30 (I'm thinking about how to make them internally now, not the command interface) 04:36:42 heh. command interface comes first 04:36:46 damn! 04:36:53 define what you want to do, then figure out how to do it 04:36:59 ok - fine. I need more coffee then 04:37:08 so, you wanna make a plug 04:37:21 you don't do that in halcmd, you do it in the component 04:37:26 hal_register_plug 04:37:32 nope 04:37:33 hal_register_socket 04:37:44 I've got to get some lunch fixed for the grand kids. 04:37:50 I want to be able to make these megacomponents out of stock HAL components 04:37:52 a likely story ;) 04:37:55 not have special ones 04:37:58 I know you guys have this well in hand. 04:38:12 see ya "Official Loudmouth" 04:38:16 bye ray 04:38:40 SWP: something very scary is coming into my head 04:38:53 hal with heirchary 04:38:59 damn I hate that word 04:39:00 oooohhh - I like that 04:39:02 to bad I can't stay 04:39:06 rayh has quit 04:39:06 hierarchy 04:39:20 (yes I know - damn me) 04:39:26 something like this in a hal file: 04:39:34 newblock { 04:39:40 newsig blah 04:39:45 newblockpin blah 04:39:58 linksp 04:40:17 lots of other links and sigs and such that are internal to the block 04:40:20 } 04:40:34 no, thats not right 04:40:51 because a block will probalby need more than one plug 04:40:54 well - I think it's important to show things at the same level they're created 04:41:21 so if someone loads some block hal file, then they do halcmd show, they see that there's a block, and whatever it exports to the world 04:41:28 not the underlying complex stuff 04:41:38 to do this right, we need to be able to instantiate a block (standard hal block) after the loadrt 04:41:39 you need to be able to get at that, but not by default 04:41:54 yes, and update multiple connections atomically 04:42:14 which all points to hallib 04:42:46 and a helper thread in kernel space (to instantiate blocks on demand), or an ioctl, or a syscall, or something like that 04:43:09 btw - what fifo / queue functions are available between userspace and RT? 04:43:26 there's got to be a queue - motion uses that 04:43:35 no it doesn't 04:43:41 fifo? 04:43:49 it uses a single buffer at the RT/user boundary 04:43:55 and queues inside RT 04:44:03 (stupid I know) 04:44:08 does it poll? 04:44:12 the RT side 04:44:29 the RT side is inherently periodic, so yes, it polls - it can't do anything else 04:44:35 ok 04:44:55 anyway, look at rtapi.h for info about fifos 04:45:18 will do - AC (after caffeine) 04:45:40 that documents and implements the functionaity that seemd to me to be the best common featureset between RTAI and RTLinux (as of the versions that existed at that time) 04:46:29 DC (during caffeine) 04:46:31 ok - and if you still want to support those versions, then it means that's the way it has to stay 04:46:36 ok - I can do that 04:46:45 unless we can find something I missed 04:47:15 I'm not the person to do that, unfortunately 04:47:17 did you and/or petev find anything the other night? 04:47:53 I didn't (relative to the user <-> RT sepmaphores) 04:47:59 semaphores 04:48:26 if both sides are polling, then you don't really need RTOS support for fifos 04:49:02 just allocate some shmem, set up head and tail pointers and write thread-safe put_on_fifo() and get_from_fifo() cals 04:49:08 echo "show pin" /dev/hal && cat /dev/hal 04:49:30 paul would shoot you 04:49:32 heh 04:49:35 (and I might too) 04:49:39 no parsing in kernel space 04:49:55 um - what about /proc/sys ? 04:50:00 let user space (halcmd) parse, and then issue error-checked commands to kernel space 04:50:32 drat 04:50:34 /dev/hal ioctls, /proc/hal, all are possibilities 04:50:43 must remember the leading space before / 04:50:51 heh - yep 04:51:00 but not ascii commands to /dev/hal 04:51:03 dev/hal is not a recognized command 04:51:10 that's fine 04:51:20 the problem is portability 04:51:28 I like the fifo / sem / mutex thing better anyway 04:51:40 /queue 04:51:56 /dev is endangeded by new things like udef, sysfs, etc 04:52:11 sure, but an ini file parameter takes care of that for you 04:52:17 ? 04:52:25 like specifying /dev/cdrom for k3b 04:52:38 you lost me 04:53:00 the kernel module does whatever it needs to do, and the file node gets placed wherever that kernel wants it to be 04:53:07 my understanding is that some newer systems might not have /dev at all 04:53:22 they use udev or something else 04:53:27 userspace gets told where that is with a line in emc.ini like [EMC]CONTROL_FILE = /dev/hal 04:53:39 or [EMC]CONTROL_FILE = /udev/hal 04:53:49 or CONTROL_DEVICE 04:53:55 but kernelspace needs to support all of those (I don't think they have a common interface) 04:54:19 I'll be damned if I'm gonna learn and code for three differnet interfaces just because the kernel folks keep changing stuff 04:54:20 no - I think in kernelspace, you just register the major and minor number your driver handles 04:54:27 the userspace helpers create the device nodes 04:54:36 (mknod, udev, sysfs, whatever) 04:54:45 obviously I don't know enough about these things ;-) 04:54:48 so it's distro-specific, not module-specific 04:55:03 I'm not speaking the gospel here, but I think that's how it works 04:56:45 sorry, phone, back now 04:56:57 that's not the case with /proc entries though - the kernel module does create those by name (though /proc could be /systeminfo or whatever) 04:57:05 np - I actually got that coffee refill ;) 04:57:32 if /dev/hal (or other flavors) can be done without too much nastyness I'm all in favor of that - it is more "by the book" than using a RT helper thread 04:57:49 hmmm 04:58:11 same thing with /proc, although even that is a kernel option, you can build a box without a /proc filesystem 04:58:20 actually, there can be a group of proc entries - /proc/hal/pins, /proc/hal/sigs, etc 04:58:27 just cat that, snd you get your list 04:58:39 and Paul has said that /proc is being phased out in favor of /sysfs 04:58:54 /whateverthenameisnow/hal/pins ... 04:58:59 proc entries that return more than one page (about 4K) of data are nasty to code 04:59:08 yes -I was just about to mention that 04:59:20 I'd still rather have an API, and let a user level library handle things 04:59:28 yes 04:59:50 whateverthenameisnow will need differnet code to handle it 05:00:00 I think that a polling thread in kernel isn't that bad a performance hit. the only nagging problem is the latency from command to execution 05:00:01 I have no systems with sysfs, no way to test it 05:00:22 its a fatal performance hit for something like show pins 05:00:56 only if you have to poll for each pin 05:00:59 because unless it can return an arbitrarly long list at once (which it cant), show involves a bunch of calls: get first, get next, get next, get next 05:01:46 you can have a command that asks for all pins, all pins matching a certain pattern (though regexp in kernel would likely be bad) 05:01:54 all pins with a certain owner ID 05:02:00 etc 05:02:03 but how do you return that list to user space? 05:02:17 in a big buffer 05:02:23 how big? 05:02:28 and where? shmem? 05:02:32 this big > < ;) 05:02:47 and what if two instances of halcmd are running at the same time? two buffers? 05:02:57 (right now halcmd is thread safe) 05:02:57 well - that could be an issue 05:03:15 but if two instances are running, how would they keep nextpins separate? 05:03:21 nextpin calls, that is 05:03:32 get_next(char *prev) 05:03:53 each call is atomic, it actually looks up prev, then returns the next one 05:04:15 incidentally - this is only an issue if the helper services one request per polling cycle 05:04:20 I plan to store the metadata in AVL trees instead of linear lists to speed the lookup, for exactly that reason 05:04:29 if it empties the queue, every time, then it's not so bad 05:04:43 doesn't work 05:05:15 the user prog puts get_first() in the queue... even if get_next() doesn't need the name of the previous one, how many should it queue? 05:05:15 why not (assuming that the result queue is as long as the command queue)? 05:05:45 of course if get_next needs the name of the previous, you can't queue it until the previous call returns 05:06:01 ok - one other item that can be done (possibly) - once you get a command, have a shorter wait before the next poll cycle. if nothing is found, then wait a longer time 05:06:22 a workaround, and maybe viable 05:06:28 but still a hack 05:06:55 I think I'd rather suffer thru /proc vs /sysfs, or /dev vs udev vs who knows what 05:07:35 actually - it's not that hard to add a syscall to the kernel 05:07:43 there is no nice answer, which is why I've been avoiding it 05:07:48 emc already requires a patched kernel, why not add one more? 05:07:51 do you have to recompile the kernel? 05:07:57 yes 05:08:04 not an option then 05:08:06 but only if you don't have an emc kernel already 05:08:09 I want to run on BDI-old 05:08:16 it's the same as now - you have to add the adeos patches 05:08:28 ah - the upgrade path 05:08:32