#emc-devel | Logs for 2006-10-31

[01:24:01] <SWPadnos_> heh - interesting to take a peek at the source of the classic ladder RTAI module
[01:29:12] <cradek> why? (I haven't)
[01:29:38] <SWPadnos_> MODULE_LICENSE("GPL");
[01:29:39] <SWPadnos_> MODULE_AUTHOR("Paul Corner");
[01:29:40] <SWPadnos_> MODULE_DESCRIPTION("ClassicLadder RTAI module");
[01:29:42] <SWPadnos_> from 2003
[01:30:25] <SWPadnos_> done for emc compatibility, according to the comments
[01:32:19] <cradek> I don't quite follow ...?
[01:32:59] <SWPadnos_> well, it's just funny that the RTAI compatibility they tout was from Paul / EMC in the first place
[01:33:08] <SWPadnos_> and now we're having a nard time making it work with emc2
[01:33:10] <SWPadnos_> ironic, a little
[01:33:16] <SWPadnos_> s/nard/hard/
[01:33:25] <cradek> oh I see, I didn't understand that was their tree, not ours
[01:33:42] <SWPadnos_> oh yeah - sorry about that :)
[01:35:17] <SWPadnos_> they have a relatively modular hardware interface - it may be possible to get some HAL compatibility by rewriting a single file
[01:36:53] <SWPadnos_> but I've only started looking, so I'm sure there's more
[02:05:21] <skunkworks> Issues with cl in emc2?
[02:05:53] <cradek> on the user list, there's talk of updating it
[02:06:08] <cradek> a large task, I understand, although I don't know anything about it
[02:06:13] <skunkworks> crap - I wish the web interface would update.
[02:06:25] <cradek> ?
[02:07:21] <skunkworks> oh - I read the sourceforge email lists using the site interface - it has not been updated since oct 1
[02:07:29] <cradek> oh!
[02:07:38] <jepler> has anyone in our project filed a support request? AFAIK they claim the archives are working....
[02:08:30] <cradek> doubtful
[02:09:04] <skunkworks> I filed a bug report - but I notice a bunch of other projects have also.
[02:09:21] <cradek> thanks
[02:09:25] <cradek> can't hurt
[02:11:19] <jepler> yeah I see those
[02:19:31] <jepler> hi jmk
[02:19:55] <jmkasunich> hi
[02:51:51] <jmkasunich> jepler, cradek was just telling me you have a patch to fix the license typos?
[02:58:13] <jepler> jmkasunich: yes, let me find the URL
[02:58:29] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/copyright.patch
[02:58:32] <jepler> it was generated by a script
[02:58:51] <jepler> find | xargs perl -pi -e 's/modify it under the terms of version 2.1 of the GNU General/modify it under the terms of version 2 of the GNU General/'
[02:59:02] <jepler> I reviewed it only partially
[02:59:36] <jmkasunich> I see
[03:00:11] <jmkasunich> so it doesn't change anything from GPL to LGPL or vice versa
[03:00:26] <jmkasunich> there are only a few things that I'd like to be LGPL
[03:00:49] <jmkasunich> basiclly, I want to make it possible (but not neccessarily easy) to make a non-GPL hal module
[03:01:09] <jmkasunich> does comp automatically put a GPL notice in the generated code?
[03:01:17] <jepler> no, it doesn't put a notice in the generated code
[03:01:35] <jepler> it will copy one if it is after the ";;" in the comments, though
[03:01:40] <jmkasunich> ok
[03:01:53] <jmkasunich> guess I gotta go thru a bunch of .comps and add the notice then
[03:02:04] <jmkasunich> I certainly want any components I wrote to be GPL
[03:02:10] <jepler> I think I want people to have freedom of license when they write things in .comp
[03:02:19] <jmkasunich> ok
[03:02:35] <jmkasunich> I did notice that .comp files vary widely in what they include right now
[03:02:45] <jmkasunich> some have a license notice (big old comment block)
[03:02:51] <jmkasunich> others have a one line license
[03:02:54] <jmkasunich> some have nothing at all
[03:03:00] <jepler> they should at least have a MODULE_LICENSE()
[03:03:07] <jepler> to avoid tainting the kernel and all that
[03:03:30] <jepler> it feels bad putting a 10-line notice on a 10-line comp
[03:03:35] <jmkasunich> yeah
[03:04:10] <jmkasunich> question - if I put MODULE_LICENSE() in a .comp, what happens when its built for simulation?
[03:04:16] <jepler> it's ignored
[03:04:17] <jmkasunich> does the macro just disappear
[03:04:27] <jepler> I think it does leave something in the .so but I'm not 100% sure
[03:04:38] <jmkasunich> seems like the comps should also include a one-line license notice then
[03:05:07] <jmkasunich> /* license: GPL version 2.0 */
[03:05:21] <jepler> it looks like MODULE_LICENSE() puts in a symbol called "rtapi_info_license"
[03:07:31] <jmkasunich> thinking about this stuff makes me tire
[03:07:34] <jmkasunich> tired
[03:07:39] <jepler> yeah I know how you feel
[03:07:55] <jepler> worse than writing documentation
[03:08:10] <jepler> about on par with cleaning the cat box
[03:08:16] <jmkasunich> yeah
[03:08:33] <jmkasunich> anyway, if you are willing to apply that patch and commit, I'd be grateful
[03:08:47] <jmkasunich> we can worry about the finer details later
[03:08:49] <jepler> yes, I can do that
[03:09:02] <jmkasunich> thanks
[03:09:10] <jepler> and I will
[03:09:21] <jmkasunich> ;-)
[03:19:36] <jmkasunich> I wonder how the fsf found out about that little typo anyway
[03:20:29] <cradek> eh, it's good to get it fixed anyway.
[04:37:38] <jmkasunich> bedtime
[19:14:01] <logger_dev> * logger_dev is logging
[19:38:15] <jepler> hmph. axis works poorly with gantry kinematics (4 joints and 3 axes)
[19:38:20] <jepler> it assumes the number of joints and axes is the same
[19:38:49] <alex_joni> jepler: bet it's not the only piece of code that does that
[19:39:01] <alex_joni> * alex_joni remembers that even the motion controller treats that badly
[19:39:14] <alex_joni> it only initializes num_axes joints
[19:39:17] <SWPadnos_> that may be a problem with any non-trivkins setup
[19:39:36] <alex_joni> SWPadnos_: any setup where num_joints!=num_axes
[19:40:51] <SWPadnos_> right
[19:41:07] <jepler> please comment: http://emergent.unpy.net/files/sandbox/gantrykins.c http://emergent.unpy.net/files/sandbox/axis-xyyz.ini http://emergent.unpy.net/files/sandbox/sim-xyyz.hal
[19:41:36] <jepler> I don't know much about gantry systems, but I've attempted to write a kinematics module that is adaptible to various ganged axis setups, like xyyz, xxyz, etc
[19:42:26] <jepler> as an example, for an xyyz machine you might configure gantrykins to say that joint 0 corresponds to axis 0, joint 1 corresponds to axis 1, joint 2 corresponds to axis 2, and joint 3 corresponds to axis 4
[19:42:31] <jepler> using "setp"
[19:43:21] <alex_joni> * Description: trivkins.c
[19:43:29] <jepler> it seems to work, and with 'halcmd show' I see that joints 1 and 3 move together, according to the commanded Y position
[19:43:35] <alex_joni> jepler: might wanna change that :)
[19:43:39] <jepler> alex_joni: oh well if you're gonna nitpick
[19:43:40] <jepler> hi ray
[19:43:44] <SWPadnos_> Hi Ray
[19:43:50] <rayh> Hi guys
[19:45:38] <SWPadnos_> ah, so you assign joint numbers by parameters, and multiple outputs can be derived from the same input
[19:45:43] <jepler> right
[19:45:43] <alex_joni> jepler: I'm reading through them :)
[19:46:11] <jepler> probably the complicated SET() is overdesigned
[19:46:19] <alex_joni> a tiny bit.
[19:46:29] <alex_joni> jepler: this is also a nice addition to trivkins
[19:46:36] <jepler> it was designed to provoke some kind of error when the joints were not close together, but following error will do that already
[19:46:40] <alex_joni> to be able to specify with halcmd setp's what each joint is
[19:47:01] <alex_joni> gets rid of XYZ setups for lathe
[19:47:21] <jepler> alex_joni: you could use gantrykins for that as well
[19:47:26] <SWPadnos_> it returns the position of the highest valued joint assigned to a particular world ordinate
[19:47:57] <SWPadnos_> not a combination or a master joint (or an error if two joints for the same ordinate are different)
[19:48:40] <jepler> as written it is supposed to return an error if there are two joints to an axis and they are further than 'tol' apart'
[19:49:04] <SWPadnos_> also, the joint number should default to -1, so that axis 8 having 0 doesn't screw up X (I didn't notice it if the initialization is there)
[19:49:05] <alex_joni> what's pos->f ?
[19:49:30] <SWPadnos_> ah - set does that, I think
[19:50:37] <jepler> alex_joni: in SET(), f is replaced with the macro argument
[19:50:41] <SWPadnos_> ok - didn't notice the SET / set stuff
[19:50:43] <jepler> so it's pos->tran.x, etc
[19:50:55] <alex_joni> ok, beeing blind here ;)
[19:53:19] <jepler> I'll make it default so that joint i is axis i
[19:53:26] <jepler> but that seems to be a problem for joints 7 and 8
[19:53:26] <SWPadnos_> I wonder if it would be more generic to have a separate hal component that has a tolerance parameter and "splits" a single position command into two outputs (with appropriate feedback)
[19:54:25] <jepler> SWPadnos_: at least one person has suggested that, but it seems like you want to take advantage of kinematics to get a separate motor-joint offset for each joint
[19:54:57] <alex_joni> especially now that emc2 remembers the motor-offset on shutdown ;)
[19:54:59] <SWPadnos_> does motion even deal with joints 7 and 8?
[19:55:14] <alex_joni> SWPadnos_: besides exporting the pins? no :)
[19:55:18] <alex_joni> unless they are enabled
[19:55:19] <SWPadnos_> that's what I thought
[19:55:24] <SWPadnos_> hmmm
[19:55:32] <alex_joni> but num_axes can't be 8 so they are rarely enabled ;)
[19:56:06] <cradek> joint mode is scary and dangerous with this scheme
[19:56:14] <cradek> and I don't see how you can possibly home and get into teleop
[19:56:55] <alex_joni> cradek: which scheme? the one SWP suggested?
[19:57:07] <cradek> using kinematics
[19:57:52] <SWPadnos_> hmmm
[19:58:04] <alex_joni> you mean because you can move each side of the gantry independently ?
[19:58:13] <SWPadnos_> jogging is an issue with a separate hal component
[19:58:18] <cradek> yes
[19:58:38] <cradek> and you can home only one joint at a time
[19:59:01] <alex_joni> well.. I think you can home 2 with the changes jepler did lately
[19:59:09] <SWPadnos_> you have to home slaved joints simultaneously though (or is that what you're pointing out?)
[19:59:15] <alex_joni> but I agree it's a source for possible errors
[20:00:24] <alex_joni> jepler: does AXIS change to teleop these days?
[20:00:43] <jepler> alex_joni: yes -- though I'm sure some of the details are wrong
[20:03:10] <alex_joni> jepler: how about we tackle that for 2.2 ?
[20:03:30] <jepler> there are two possibilities -- either it's this easy, and anybody with a gantry can build this
[20:03:35] <jepler> or it's complicated and it's best to leave it
[20:03:40] <jepler> so yeah let's put it off
[20:03:53] <jepler> I'll put this up on axis.unpy.net along with the other stuff that ain't ready for prime time
[20:04:24] <alex_joni> ok, good
[20:04:31] <SWPadnos_> oops
[20:04:38] <alex_joni> serves you well logger_devel :P
[20:04:42] <alex_joni> SWPadnos_: the old one ;)
[20:04:47] <SWPadnos_> oh, good ;)
[20:04:52] <alex_joni> logger_dev: still around?
[20:04:52] <alex_joni> I'm logging. Sorry, searching removed.
[20:04:58] <SWPadnos_> heh
[20:05:03] <alex_joni> did you change that?
[20:05:06] <SWPadnos_> nope
[20:05:19] <alex_joni> * alex_joni suddenly feels that he knows even less perl
[20:05:49] <SWPadnos_> I wonder if the ? is meant to signify a search
[20:05:49] <SWPadnos_> logger_dev: help
[20:06:17] <alex_joni> hmm.. the search.cgi I didn't move over to DH
[20:06:22] <alex_joni> and I'd rather not do that
[20:06:35] <SWPadnos_> ok
[20:06:45] <alex_joni> I'm not fully confident in the security risks it might contain
[20:06:50] <SWPadnos_> was that a generic site search if used "improperly"?
[20:06:53] <SWPadnos_> ok
[20:07:14] <alex_joni> not necessarely, I think it's as good as I can write it
[20:07:32] <alex_joni> but it can probably be exploited through various attacks
[20:13:34] <alex_joni> SWPadnos_: google search can take over
[20:13:39] <SWPadnos> yep
[20:13:51] <alex_joni> it's under linuxcnc.org now.. so it should get indexed at some point
[20:57:10] <jepler> http://axis.unpy.net/index.cgi/01162326817
[22:24:14] <alex_joni> good night gents