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