Back
[11:03:07] <alex_joni> morning all
[12:57:28] <jepler> hi alex_joni
[12:58:28] <alex_joni> hey jeff..
[21:10:39] <jmkasunich> hi guys
[21:10:54] <alex_joni> hi jmk
[21:11:03] <alex_joni> wanted to talk to you about something ;)
[21:11:23] <jmkasunich> saw the discussion of the tripod... wish I had more time on my hands, I'd build one, jeff could build one, maybe cradek too, and we could seriously attack all the issues of non-trivial kins
[21:11:49] <alex_joni> speaking of which.. reminds me of my topic :=
[21:12:08] <alex_joni> there is one conceptual limitation I've noticed in the motion controller
[21:12:14] <alex_joni> which I think we need to address
[21:12:18] <zwisk> Are there plans for a hexapod that isn't too pricey?
[21:12:25] <alex_joni> it will be probably be a HUGE PITA to build it
[21:12:40] <alex_joni> zwisk: I have some hexapod plans I gathered from the web..
[21:12:50] <alex_joni> can't remember where, but I can email them if you like
[21:13:08] <zwisk> I'm newby enough that I don't know anything about screws and screw types, so that slowed me down a lot when looking at putting one together.
[21:13:48] <jmkasunich> zwisk: building a hexapod is a pretty hefty project
[21:14:00] <zwisk> darn. That's what I was afraid of :)
[21:14:05] <jmkasunich> especially one rigid enough to actually hold a cutting tool
[21:14:08] <alex_joni> zwisk: it's a 700kB archive holding about 80 dxf's
[21:14:44] <zwisk> alex_joni: cool. I guess that's a big enough sampling to either convince me I should or convince me I shouldn't consider it :)
[21:14:50] <alex_joni> looks quite complete
[21:14:57] <jmkasunich> each screw needs a 2DOF joint at each end, and any slop in the joints hurts both rigidity and accuracy
[21:15:33] <jmkasunich> thats one nice thing about a cable hexapod, the joint issue goes away, since the cable can bend
[21:15:46] <zwisk> So, I got the feeling that the accuracy and slop in the joints would be lessened by the distance between the joints and the cutting surface. At least some of the time. I guess pure up and down moves might be the exception.
[21:16:04] <alex_joni> jmkasunich: care to talk a bit about joints and axes?
[21:16:16] <zwisk> Anyway, I didn't mean to interrupt the flow o conversation about deficiencies in the algorithms...
[21:16:25] <alex_joni> zwisk: no biggie ;)
[21:16:33] <alex_joni> jump in at any time
[21:16:43] <zwisk> :)
[21:16:53] <alex_joni> jmkasunich: the biggest problem I've seen is that the motion controller expects that the number of joints = number of axes
[21:16:59] <alex_joni> and I think that's not always true
[21:17:14] <jmkasunich> agreed
[21:17:17] <alex_joni> especially with redundant axes
[21:17:22] <alex_joni> like X and X'
[21:17:24] <jmkasunich> its not just the controller....
[21:17:36] <alex_joni> yeah .. unfortunately I know that ;)
[21:17:40] <jmkasunich> all thru the system, the distinction between joints and axis is pretty much ignored
[21:17:46] <jmkasunich> we can blame trivkins for that
[21:17:56] <alex_joni> I didn't even want to go there .. but you're right
[21:18:06] <alex_joni> the ini is in joints not axes
[21:18:14] <alex_joni> and the TP should work on axes, not joints
[21:18:23] <alex_joni> and call inversekins every cycle
[21:18:25] <alex_joni> and so on..
[21:18:32] <jmkasunich> right
[21:18:52] <alex_joni> but what I find rather limiting is the numbering scheme
[21:18:59] <alex_joni> which tends to be easily broken
[21:19:12] <alex_joni> both on the interp side (XZA)
[21:19:20] <alex_joni> or on the joint side (j0,j2,j3)
[21:19:45] <alex_joni> actually I'm not very sure what I want :)
[21:20:11] <alex_joni> I know fixing the whole mess is a HUGE problem ..
[21:20:24] <alex_joni> zwisk: mail away, btw
[21:20:28] <jmkasunich> I really do think that the core developers all need to have access to some non-trivkins machine to address this
[21:20:35] <zwisk> thanks alex_joni... got it...
[21:20:41] <jmkasunich> (or a simulation of a non-trivkins machine)
[21:20:47] <alex_joni> zwisk: hope it'll be of any good
[21:20:51] <alex_joni> jmkasunich: yeah, I agree
[21:21:02] <alex_joni> and building a tripod like that shouldn't be much of a problem ;)
[21:21:07] <zwisk> A simulator is an interesting idea...
[21:21:10] <alex_joni> I did it in a couple of hours
[21:21:18] <jmkasunich> I've thought about making a simulator before
[21:21:32] <jmkasunich> use openGL or something, that can render boxes, cylinders, etc
[21:21:34] <zwisk> I wonder how hard it would be to strap a simulator on to axis...
[21:21:55] <jmkasunich> build a machine out of primitives, and give it hal pins to control it (it would replace motors and encoders)
[21:22:14] <jmkasunich> (we're overloading the word simiulator again....)
[21:22:45] <zwisk> Hmm.. yes. There's a project called ODE that might be helpful; it lets you define joints and interactions and simulates the physics...
[21:22:49] <jmkasunich> I'm talking about a machine (perhaps a hexapod, perhaps just a normal mill) that would be displayed on the screen in 3D, and would move as commanded, with no iron
[21:23:42] <zwisk> http://www.ode.org/
[21:23:54] <zwisk> Hmm... yes, we are talking about slightly different concepts I guess.
[21:24:26] <alex_joni> too much of a simulator for this purpose :)
[21:24:30] <jmkasunich> well, it seems the two of us are using the same meaning for simulator (or close)
[21:25:18] <jmkasunich> two others: the ability to run emc on a machine without a RT patched kernel, and the 'sim' configs, that let you run without an actual machine (faking the servo motors and encoders)
[21:25:33] <zwisk> I guess to me, though, the cutting edges are the most important. So, in axis, for example, I'd be happy with it doing the 'simulation' and just displaying the tool tip position, where 'simulation' in that context might just be running the math (forward kinetics) and not necessarily drawing all the parts in between.
[21:26:05] <alex_joni> zwisk: yeah, but that shouldn't be done by axis
[21:26:11] <alex_joni> emc should take care of that
[21:26:21] <alex_joni> and axis should only plot the carthesian position
[21:26:53] <zwisk> Well... sorta... It seems like using EMC to simlute EMC opens things up for some self-checking that might be wrong both ways, but ... ok... sure..
[21:27:24] <alex_joni> axis could also plot joints
[21:27:40] <alex_joni> and if it would plot a 3d model moving around that would be just too cool
[21:27:50] <zwisk> (Right now I'd be excited to have axis plot the tool tip [G43] :) )
[21:27:55] <jmkasunich> currently gui's don't know beans about kinematics, and I'm not so sure they should
[21:28:12] <alex_joni> jmkasunich: it can be another simulator ;)
[21:28:18] <alex_joni> not necessarely axis
[21:28:29] <jmkasunich> ok, that I can agree with
[21:28:52] <alex_joni> short change of topic:
http://sourceforge.net/forum/forum.php?thread_id=1529217&forum_id=88266
[21:29:16] <zwisk> A true 'simulator', in my mind, would be a hal plugin sorta think like jmk described, which runs outside of emc completely, and acts like the iron would. If the simulator has encoders of any sort, they would accurately feed back in to emc, but in an open loop system, EMC would have no direct knowledge of the simulator itself.
[21:30:15] <jmkasunich> alex: already read the thread (from a little bit ago)
[21:30:30] <jmkasunich> zwisk: exactly
[21:30:34] <alex_joni> jmkasunich: ok.. just wanted to point it out
[21:31:15] <jmkasunich> the simulator would accept joint position commands and return joint position feedback (using hal pins), and would display the corresponding machine positions
[21:31:24] <jmkasunich> it would also simulate things like limit and home switches
[21:31:42] <alex_joni> nice
[21:31:52] <alex_joni> jmkasunich: can I make a short feature request?
[21:32:07] <jmkasunich> sure
[21:32:11] <jmkasunich> you can even make a long one
[21:32:15] <alex_joni> I want a halvcp designer
[21:32:20] <alex_joni> lol
[21:32:25] <jmkasunich> graphical?
[21:32:29] <zwisk> vcp?
[21:32:31] <alex_joni> drag & drop kinda thing ;)
[21:32:35] <jmkasunich> virtual control panel
[21:32:37] <alex_joni> zwisk: virtual control panel
[21:32:46] <alex_joni> zwisk: lets you control hal pins using buttons
[21:32:52] <alex_joni> and display pins using leds
[21:32:54] <alex_joni> and so on
[21:32:56] <alex_joni> on a GUI
[21:32:57] <jmkasunich> lets you put buttons and leds on a screen, then hook em to hal pins
[21:33:10] <zwisk> That'd be nice... jmk's always talked about having a netlist-style config interface to hal...
[21:33:20] <jmkasunich> behaves just like if you had real buttons and leds hooked to a parport or some other digital IO
[21:33:35] <alex_joni> zwisk: that's the HAL config GUI
[21:33:38] <alex_joni> different
[21:33:50] <alex_joni> this one is more like a GTK design software
[21:33:50] <zwisk> more like a hal-pin breakout box?
[21:33:59] <jmkasunich> the thing with both the schematic based hal config, and the drag-n-drop vcp builder, is that they are major GUI projects
[21:34:00] <alex_joni> which lets you drag & drop buttons and widgets
[21:34:15] <alex_joni> jmkasunich: yeah, I know.. I'll keep editing text for now :D
[21:34:15] <jmkasunich> zwisk: you familiar with glade?
[21:34:36] <zwisk> yeah, moderately familiar with glade. It makes ugly code though, so I don't tend to use it :)
[21:34:50] <jmkasunich> well, alex is asking about a "glade for halvcp"
[21:35:07] <jmkasunich> vcp has a small set of widgets, and currently you place them by editing a text file
[21:35:19] <zwisk> cool...
[21:35:43] <alex_joni> zwisk:
http://cvs.linuxcnc.org/cvs/emc2/configs/halui_halvcp/halui.vcp?rev=1.4;content-type=text%2Fplain
[21:35:54] <zwisk> resedit was by far better :)
[21:36:23] <zwisk> wow... that's kinda cool...
[21:36:38] <zwisk> I haven't played with vcp at all..
[21:36:42] <alex_joni> in the meantime I'm at 300+ lines
[21:36:51] <jmkasunich> I believe that config runs without any hardware
[21:36:52] <alex_joni> and it's kinda annoying if you want to restructure it :D
[21:36:58] <alex_joni> yes it does
[21:37:02] <alex_joni> and it uses halui too ;)
[21:37:08] <alex_joni> hal User Interface
[21:37:10] <jmkasunich> if you want to see what the panel looks like, just run the halui_halvcp config
[21:37:38] <alex_joni> which is supposed to be means for building a hardware panel with knobs & switches & leds to run emc
[21:37:52] <alex_joni> basicly it exports hal pins, and sends NML messages according to those
[21:38:53] <jmkasunich> so halvcp or a real panel interfaces human<->hal, and halui interfaces hal <-> emc (for user type stuff, like "cycle start", "jog X", etc)
[21:39:29] <zwisk> nifty... More stuff to play with...
[21:39:36] <alex_joni> and right now it's human<->halvcp<->hal<->halui<->NML<->emc..
[21:39:38] <zwisk> ls
[21:39:40] <zwisk> oops :)
[21:39:45] <alex_joni> .
[21:39:46] <alex_joni> ..
[21:45:10] <alex_joni> jmkasunich: do you think there is a limitation of the number of boxes I can stack one into the other?
[21:46:04] <jmkasunich> not that I'm aware of
[21:46:18] <alex_joni> I have about 5 levels
[21:46:22] <alex_joni> and it segfaults.. not sure why :D
[21:47:07] <jmkasunich> eww
[21:47:17] <alex_joni> indeed :P
[21:50:32] <jmkasunich> and it was OK with fewer levels?
[21:53:10] <alex_joni> jmkasunich: I think I found the problem
[21:53:20] <alex_joni> if I have it like this
[21:53:26] <alex_joni> box = box + button
[21:53:34] <alex_joni> it crashes
[21:53:52] <alex_joni> not sure you get what I mean
[21:54:02] <jmkasunich> you mean boxA contains boxB and buttonA
[21:54:08] <alex_joni> box { box {..} button }
[21:54:10] <alex_joni> yeah
[21:54:25] <alex_joni> if it's box { button box{..}} it works
[21:54:33] <jmkasunich> when does it crash? when reading the halvcp file?
[21:55:06] <alex_joni> I think so
[21:55:11] <alex_joni> it doesn't get to display the GUI
[21:55:18] <alex_joni> I think LED's work.. just buttons don't
[21:55:37] <jmkasunich> I'll investigate
[21:56:04] <alex_joni> hmm.. no
[21:56:10] <alex_joni> moving the button around doesn't help..
[21:56:15] <alex_joni> maybe it's stack depth
[21:56:57] <alex_joni> this is box { box { box { box { button box {} } } } }
[21:57:17] <jmkasunich> what if you put the button inside the innermost box?
[21:58:14] <alex_joni> still crashes
[21:58:32] <jmkasunich> so its not "button and box inside box" that does it
[21:58:50] <jmkasunich> because in the last case, you only have a single button inside the innermost box
[21:59:13] <jmkasunich> can you send me (or pastenbin, or paste here) your vcp file?
[21:59:38] <alex_joni> you don't want it in here ;)
[21:59:40] <alex_joni> I'll pastebin
[22:00:21] <alex_joni> http://pastebin.ca/82764
[22:02:01] <jmkasunich> quite a panel there
[22:02:03] <alex_joni> argh
[22:02:09] <alex_joni> I think I forgot a layout = ..
[22:02:15] <alex_joni> on a box, and that's the reason it crashes
[22:02:37] <alex_joni> but it doesn't say anything ;)
[22:03:06] <jmkasunich> thats still a bug
[22:03:12] <alex_joni> yup
[22:03:15] <jepler> jmkasunich: the comment in hal.h says that when all component have exited, hal_malloc()'d memory is freed. this doesn't match my experience, which is that repeatedly running a component that allocates 4000 bytes with hal_malloc() and then calls hal_exit() eventually starts failing.
[22:03:21] <jmkasunich> "layout = " is optional, it should have a default balue
[22:03:35] <jmkasunich> jepler: you caught me
[22:03:53] <alex_joni> lol
[22:04:11] <jmkasunich> a correct comment would say "memory associated with its pins, params, etc, is freed, but memory allocated with hal_malloc() is not"
[22:04:31] <jmkasunich> either that, or I'd write a better allocator that actually supports free()
[22:04:38] <jepler> hah
[22:04:45] <jmkasunich> s/write/steal from somewhere/
[22:05:10] <jepler> at first I worried there was a bug in my python hal module
[22:05:12] <jmkasunich> 4000 bytes is a pretty large block
[22:05:19] <jmkasunich> what are you doing with those bytes?
[22:05:30] <jepler> nothing; this was just the test program
[22:06:14] <jmkasunich> OK (you should only use hal shmem for pins and params, or perhaps a few local variables... if you need lots of local storage, malloc a normal block, don't use shmem)
[22:08:43] <jepler> to create a generic pin, is this right or wrong usage of hal_malloc?
[22:08:44] <jepler> pin->data = hal_malloc(MAX_PIN_SIZE);
[22:08:52] <jepler> res = hal_pin_new(pin_name, type, dir, pin->data, self->hal_id);
[22:09:11] <alex_joni> hal_pin_new allocs it
[22:09:18] <jmkasunich> alex: no
[22:09:22] <alex_joni> no?
[22:09:43] <alex_joni> oh.. hal_pin_new.. thought hal_pin_bit_new
[22:10:02] <jmkasunich> you pass hal_pin_<type>_new a pointer to a *hal_pin_<type>_t that is already allocated in shmem
[22:10:05] <zwisk> ooh! Cradek just committed my g43 wish! Rock!
[22:10:08] <jmkasunich> usually its part of a struct
[22:10:28] <jmkasunich> but I gather jepler is asking about doing a single pin?
[22:10:46] <jepler> yes .. this is the python interface to hal, and it works (so far) by creating one pin at a time
[22:11:34] <jmkasunich> first I'll do the struct version (because its the one I grok), then we'll figure out the single pin version
[22:11:56] <jmkasunich> typedef struct {
[22:12:10] <jmkasunich> hal_bit_t *bitpin;
[22:12:17] <jmkasunich> } mystruct;
[22:12:38] <jmkasunich> mystruct *msp;
[22:12:52] <jmkasunich> msp = hal_malloc(sizeof mystruct);
[22:13:30] <alex_joni> so the pointer is allocated in the shm
[22:13:36] <jmkasunich> res=hal_pin_bit_new(name, type, &(msp->bitpin) );
[22:13:47] <jmkasunich> I guess the single pin version is:
[22:14:28] <jmkasunich> hal_bit_t **mypin;
[22:14:44] <jmkasunich> mypin = hal_malloc(sizeof *hal_bit_t);
[22:15:04] <jmkasunich> hal_bit_pin_new(name, type, mypin);
[22:15:36] <jmkasunich> the double indirection is because a pin isn't a hal_bit, its a pointer to a hal_bit
[22:15:53] <jmkasunich> (the connected signal is what it points to, a linksp changes the pointer)
[22:16:22] <jmkasunich> jepler: am I making any sense?
[22:16:26] <jepler> I think so
[22:16:34] <jepler> you haven't told me my code is wrong yet
[22:17:04] <jmkasunich> well, you used "pin->data", and I have no idea what the type of "pin" is...
[22:17:21] <jepler> pin->data is a void*
[22:17:58] <jmkasunich> pin is an instance of some struct that you defined?
[22:18:05] <jepler> yes
[22:18:40] <jmkasunich> then yeah, I think your code is correct
[22:18:51] <jmkasunich> accessing the value of the pin will be a problem tho
[22:19:12] <jmkasunich> hal_bit_t abit;
[22:19:24] <jmkasunich> abit = **(pin->data);
[22:19:33] <jepler> yeah it was messy
[22:19:36] <cradek> zwisk: tell me whether you think tool offset works right in axis
[22:19:38] <jmkasunich> except that since data is a void *, the compiler doesn't know what to do
[22:19:42] <jepler> I am changing it to use a union of pointers to hal_XXX_t
[22:19:57] <jmkasunich> oh, you're trying to be _very_ generic
[22:20:13] <jepler> yes
[22:20:56] <jmkasunich> are you going to provide "read pin" and "write pin" methods? they would do the **(pin->data) thing, but use the proper union member
[22:21:47] <jepler> argh, I've borked something in my working copy of emc
[22:22:01] <jmkasunich> oops
[22:22:08] <jepler> jmkasunich: in python, when you get/set the value of a pin, it will automatically take care of all the types at the C/Hal level
[22:22:24] <jmkasunich> but how does it know what the hal pin type is?
[22:22:31] <jepler> it records it when the pin is created
[22:22:46] <jepler> pin->type
[22:22:49] <jmkasunich> so "pin" has a type field in addition to data
[22:23:20] <jmkasunich> and the python "set" will check type, then use the appropriate union member to dereference data
[22:23:24] <jmkasunich> ?
[22:23:52] <alex_joni> ARGH
[22:23:54] <alex_joni> I hate indent
[22:24:02] <alex_joni> it completely fscked up the whole vcp
[22:24:05] <jmkasunich> what did it do?
[22:24:05] <jepler> jmkasunich: yes
[22:24:16] <alex_joni> and I ran it twice :((
[22:24:33] <jmkasunich> somebody needs to write "undent"
[22:24:45] <jmkasunich> run it twice, and you are back to where you started
[22:24:53] <alex_joni> for instance it splitted the names (foo-is-activated)
[22:25:14] <jmkasunich> oops
[22:25:25] <alex_joni> same for 'on-color'
[22:25:36] <jmkasunich> at least the copy in the pastebin is a handy backup
[22:30:32] <jmkasunich> alex: the segfault happens after then entire vcp file is parsed, and after connecting to HAL...
[22:30:57] <alex_joni> yes
[22:32:57] <alex_joni> jmkasunich: there is another bug I noticed
[22:33:10] <alex_joni> when you run halvcp, the first button clicked doesn't do anything
[22:33:18] <alex_joni> it only works the second time, and from there on
[22:33:38] <jmkasunich> one bug at a time ;-)
[22:42:41] <fenn> zwisk: the hexapod plans page went down a couple months ago:
http://fenn.dyndns.org/pub/www.i-way.co.uk/~storrs/
[22:42:57] <alex_joni> fenn: I mailed them to him
[22:43:02] <fenn> wish he had taken some pictures of the actual machine
[22:43:10] <alex_joni> the plans I mean
[22:43:53] <alex_joni> did they ever build it?
[22:44:03] <fenn> yeah he made tons of harpsichords with it
[22:45:10] <jmkasunich> alex: found the first bug...
[22:45:21] <jmkasunich> the "layout" attribute is a string
[22:45:41] <jmkasunich> I want to see if it is either "vertical" or "horizontal", but don't care about case
[22:45:59] <alex_joni> ok
[22:46:00] <jmkasunich> so I did "layout[0] = toupper(layout[0]);
[22:46:15] <jmkasunich> which works OK, if the user provided a value (the value is malloced in ram)
[22:46:33] <jmkasunich> but if they didn't, "layout" still points to the default, which is a constant...
[22:46:42] <jmkasunich> iow, its in the code segment
[22:46:54] <jmkasunich> so attempting to write to it segfaults
[22:47:21] <jmkasunich> gonna change it to use strcasecmp
[22:47:51] <jepler> jmkasunich: btw here's an example working python component:
http://unpy.net/cgi-bin/viewcvs.cgi/axis/scripts/haltest.py?rev=1.2;content-type=text%2Fplain
[22:48:22] <jmkasunich> neat
[22:48:37] <jmkasunich> (I don't know python, but I kinda understand what is going on)
[22:48:50] <jmkasunich> the full names of the pins are test.i, test.f, and test.u8?
[22:49:16] <fenn> what exactly does "from hal import *" do?
[22:49:30] <jmkasunich> damned if I know, I glossed over that part
[22:50:28] <jepler> it's a shortcut
[22:50:57] <jepler> usually you 'import module' and then refer to 'module.method' or 'module.CONSTANT'. but with '... import *' you can refer to method or CONSTANT without naming module each time
[22:51:13] <fenn> yes but what is the "hal" module?
[22:51:19] <jepler> jmkasunich: yes, you're right about the full names of the pins
[22:51:34] <jepler> fenn: it's a new python module I've written for axis
[22:51:54] <jepler> 'component' and HAL_XXX come from it
[22:55:54] <jmkasunich> its amazing how many error messages you can get from one missing paren
[22:58:28] <alex_joni> jmkasunich: yeah ;)
[22:59:17] <jmkasunich> ok, fixed the first bug
[22:59:32] <alex_joni> cool
[23:02:39] <jmkasunich> what was the second one again?
[23:02:56] <alex_joni> first time you push a button nothing happens
[23:03:06] <alex_joni> only the second and any further pushes work
[23:03:19] <alex_joni> although I suspect it's halvcp (not halui)
[23:03:24] <alex_joni> hang on I'll look..
[23:03:35] <jmkasunich> put a halmeter on the signal from halvcp to halui
[23:05:47] <alex_joni> that's what I want
[23:07:07] <jmkasunich> ?
[23:07:10] <alex_joni> something crashed really hard now
[23:07:19] <alex_joni> halcmd is not doing anything usefull anymore
[23:07:25] <alex_joni> system is up and running though
[23:07:33] <alex_joni> but something about the shm is borked
[23:07:42] <jmkasunich> scripts/realtime restart
[23:07:54] <jmkasunich> oh, sorry
[23:08:05] <alex_joni> sudo rmmod scope_rt
[23:08:05] <alex_joni> Password:
[23:08:05] <jmkasunich> you're running emc itself, not just halvcp
[23:08:09] <alex_joni> and it hangs..
[23:08:33] <jmkasunich> open another shell, and try "bin/halcmd -R"
[23:08:48] <alex_joni> coo.. that was it
[23:09:04] <jmkasunich> that means something somewhere died while holding the hal mutez
[23:09:09] <alex_joni> right
[23:09:09] <jmkasunich> mutex
[23:09:46] <alex_joni> ok.. I stand corrected
[23:09:49] <alex_joni> it's a halui bug ;)
[23:10:13] <alex_joni> I do need to init all those vars probably ;)
[23:29:43] <alex_joni> jmkasunich: finished the VCP for now ;)
[23:29:46] <alex_joni> http://wiki.linuxcnc.org/uploads/halvcp.png
[23:31:33] <jmkasunich> looking
[23:31:55] <jmkasunich> what do the leds under the home buttons show?
[23:32:04] <jmkasunich> limit and home switches?
[23:32:13] <alex_joni> from left to right
[23:32:23] <alex_joni> hard min, soft min, error, soft max, hard max
[23:33:44] <alex_joni> and the big led is for homed
[23:33:44] <fenn> can we get tooltips on vcp widgets?
[23:34:06] <alex_joni> if someone writes that.. sure
[23:34:43] <alex_joni> jmkasunich: one more thing..
[23:34:56] <fenn> should be easier than what i was trying to do with classicladder
[23:35:04] <fenn> since they're actually widgets to start with
[23:35:10] <alex_joni> jmkasunich: the stuff that comes out of the motion controller is called axis.*.
[23:35:17] <alex_joni> instead of joint.*.
[23:35:26] <jmkasunich> yeah, that was probably a mistake
[23:36:10] <alex_joni> yeah, but changing that.. might bring lots of breaking after it
[23:36:18] <alex_joni> * alex_joni thinks about core_stepper & co
[23:36:29] <alex_joni> along with custom configs
[23:36:38] <jmkasunich> its the custom ones that are the problem
[23:36:51] <jmkasunich> the standard ones can be fixed at the same time we fix the code
[23:36:57] <alex_joni> if we say 2.1.x can't use 2.0.x configs.. we're safe
[23:37:21] <alex_joni> so users need to replicate their configs on newer emc's, based on sample configs
[23:37:28] <alex_joni> but that's not the nicest thing to ask of them
[23:37:33] <jmkasunich> no, its not
[23:37:44] <fenn> i think version numbers in the sample configs is a good idea.. so if you try to load a 2.0.x config in 2.1 it yelps
[23:37:45] <jmkasunich> one possibility would be to provide two files:
[23:38:01] <fenn> then you can provide a list of things that have changed in the config format
[23:38:05] <jmkasunich> 1) a list of every pin that has changed, one per line, old name, then new name
[23:38:19] <jmkasunich> 2) a script that reads the file and goes thru a .hal file fixing things
[23:38:20] <alex_joni> or a script with sed
[23:38:25] <alex_joni> yeah
[23:38:37] <alex_joni> s/foo/bar/ ;)
[23:38:50] <fenn> gets ugly with axis-> joint
[23:39:00] <jmkasunich> why?
[23:39:14] <fenn> s/axis/joint/ will replace all the stuff that is supposed to be axis
[23:39:26] <jmkasunich> you can't do s/axis/joint
[23:39:28] <alex_joni> you can have axis.0./joint.0./ ...
[23:39:30] <alex_joni> and so on
[23:39:37] <jmkasunich> s/axis.0.foo/joint.0.foo/
[23:39:47] <jmkasunich> you'll likely need dozens of sed lines
[23:39:49] <alex_joni> no-one says you need to replace it with a one-line script
[23:39:57] <jmkasunich> thats why I want us to supply the script
[23:40:34] <fenn> although.. all the stuff in the ini related to axis accels.. it actually is axis accels :(
[23:40:46] <alex_joni> no, it's joint accels
[23:40:53] <alex_joni> at least that's how it's supposed to be
[23:41:00] <alex_joni> it's borked now
[23:41:09] <alex_joni> I mean .. it should be joint accels
[23:41:11] <fenn> yep
[23:41:30] <alex_joni> I must say I like vcp ;)
[23:41:31] <fenn> but the code plans in cartesian space
[23:41:43] <alex_joni> fenn: yeah, without using inversekins :(
[23:42:20] <fenn> it gets icky if you try to plan in cartesian space and use joint limits
[23:42:37] <jmkasunich> icky is putting it mildly
[23:42:44] <fenn> you have to build a n-dimensional map of joint limits
[23:42:55] <alex_joni> there was a thing called jacobian
[23:42:58] <fenn> so you really need to plan in joint space
[23:44:19] <alex_joni> jacobianInverse
[23:44:30] <alex_joni> which somehow converts joint speeds to carthesian speeds
[23:44:37] <alex_joni> but I've never seen it used :)
[23:44:46] <fenn> jacobian is just the derivative of the transformation matrix (?)
[23:44:47] <alex_joni> genhexkins has it implemented iirc
[23:44:58] <fenn> i hate fancy words
[23:45:36] <alex_joni> no
[23:45:42] <alex_joni> that's InvMat :D
[23:45:51] <alex_joni> or something like that
[23:47:00] <fenn> "it represents the best linear approximation to a differentiable function near a given point. In this sense, the Jacobian is akin to a derivative of a multivariate function."
[23:47:39] <alex_joni> fenn: ok.. still might bear another meaning inside emc :D
[23:48:04] <fenn> someone or other said it didnt actually do anything in emc
[23:48:32] <alex_joni> I did say that
[23:48:33] <fenn> can we please put genhexkins back in? or at least have a vote on it
[23:48:41] <alex_joni> it still is in HEAD
[23:49:10] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/src/emc/kinematics/
[23:49:30] <fenn> why did you remove it from a branch?
[23:49:54] <alex_joni> I thought the commit message was clear?
[23:49:54] <jmkasunich> cause you-know-who was pissing (without good reason) about licensing
[23:51:35] <alex_joni> we're starting to sound like harry potter & co.
[23:51:36] <alex_joni> LOL
[23:52:46] <fenn> * fenn is glad to have never sullied his psyche with such rubbish
[23:53:09] <jepler> second rev of the "userspace component ready flag" patch:
http://emergent.unpy.net/index.cgi-files/sandbox/ready.patch
[23:53:35] <alex_joni> Other names: 'Lord Voldemort,' 'You-Know-Who,' 'He Who Must Not Be Named,' 'The Dark Lord,'
[23:53:53] <jmkasunich> * jmkasunich looks at the patch
[23:53:57] <jepler> userspace components should now call hal_ready(id) when they've created all their pins and signals and before entering their event loop or whatever
[23:54:18] <jepler> halcmd can optionally wait on the component, using the executable name as the component name unless it is explicitly specified
[23:54:31] <alex_joni> * alex_joni is also looking at the patch
[23:54:42] <jepler> the new "halcmd unloadusr" sends signals to all userspace components, but that's not strictly related
[23:55:26] <jepler> and 'halcmd show comp' is extended to show the PID and ready flag of userspace components
[23:55:37] <alex_joni> jepler: some stuff missing from the patch
[23:55:47] <alex_joni> * alex_joni grins
[23:55:50] <jepler> alex_joni: is there? I trimmed some by hand, maybe I screwed it up
[23:56:10] <alex_joni> I don't see any reference to halcmd.1
[23:56:17] <jmkasunich> heh
[23:56:22] <alex_joni> docs/man/halcmd.1 :D
[23:56:27] <alex_joni> jepler: just teasing you
[23:56:33] <jepler> ok ok I didn't get the joke
[23:56:49] <alex_joni> it looks great I say
[23:57:23] <jmkasunich> there is still an issue, but I don't know of an answer yet...
[23:57:27] <jmkasunich> still reading, more in a bit
[23:57:30] <jepler> er, "when they've created all their pins and parameters", I mean
[23:57:49] <jmkasunich> one comment: the HAL_VER in hal_priv.h should be incremented, since a struct member was added
[23:58:19] <jepler> OK
[23:59:28] <jepler> * jepler notices that 'unloadusr all' would send a signal to the halcmd too
[23:59:49] <jmkasunich> in unloadusr, you call kill inside a loop where you hold the mutex
