Back
[03:58:42] <CIA-22> EMC: 03cmorley 07cl_v7124_branch * 10emc2/src/hal/classicladder/classicladder.c: oops misspelled 'UpdateAllGtkWindows'
[13:41:39] <jepler> alex_joni: I never use the numeric keypad, and neither should our users.
[13:43:26] <skunkworks_> feature by design.
[13:43:50] <skunkworks_> jepler: reading a book on python.. (I bet you cringe when you hear that)
[13:44:17] <skunkworks_> * about using a book and me reading about it..
[13:54:47] <jepler> I hate books about computer languages
[13:55:35] <skunkworks_> * skunkworks_ figured as much ;)
[14:00:03] <alex_joni> jepler: 0-100% <- how serious was that answer?
[14:03:40] <jepler> well, it's true that I never use the numeric keypad..
[14:04:07] <jepler> hm this is not good
[14:04:09] <jepler> joint 0 on limit switch error
[14:04:15] <jepler> task is just spewing this over and over again ^^
[14:07:35] <jepler> hm can't make it happen again
[14:09:02] <jepler> in sim, I had linked Xhomesw => axis.0.pos-lim-sw-in axis.0.neg-lim-sw-in, then jogged onto the switch
[14:12:01] <skunkworks_> The book did have a cd.. ;)
[14:38:44] <CIA-22> EMC: 03jepler 07TRUNK * 10emc2/share/axis/tcl/axis.tcl:
[14:38:44] <CIA-22> EMC: * next attempt to fix numeric keypad
[14:38:44] <CIA-22> EMC: * fix closing main axis window while "touch off" window is displayed
[14:38:52] <jepler> somebody who cares about the numeric keypad should test trunk now ^^
[14:38:54] <CIA-22> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py:
[14:38:54] <CIA-22> EMC: * next attempt to fix numeric keypad
[14:38:54] <CIA-22> EMC: * fix closing main axis window while "touch off" window is displayed
[14:40:41] <SWPadnos> what's the 5 key called? (just curious)
[14:51:12] <alex_joni> SWPadnos: got a nice new monitor :)
[14:51:20] <SWPadnos> cool. what kind?
[14:51:47] <alex_joni> samsung 245B
[14:52:00] <alex_joni> (not top of the line.. but nice)
[14:52:07] <SWPadnos> ok - I don't know it by number :)
[14:53:11] <alex_joni> it's a 1920x1200 widescreen 24"
[14:53:40] <SWPadnos> cool. that's a good size and resolution
[14:54:08] <SWPadnos> I've messed with a couple of dual-30" setups, and they're a bit big (possibly even "too big"
[14:54:14] <SWPadnos> )
[14:54:25] <alex_joni> heh..
[14:54:36] <alex_joni> (although I doubt there's such a thing as too big :)
[14:54:45] <SWPadnos> and I still have more pixels on my 22" than two 30" combined ;)
[14:54:58] <SWPadnos> yes, there is - when you have to turn too far to see the edges
[14:55:24] <SWPadnos> it's nice to have a lot of real estate for datasheets and stuff - so you have all that available at a glance
[14:55:42] <SWPadnos> but the actual area you can work in is not that large
[14:55:59] <SWPadnos> mostly dependent on your vision and how far from the monitor(s) you are :)
[14:56:38] <alex_joni> at home I have a 22"@1680x105, at roughly 3m away
[14:56:46] <alex_joni> maybe 2m sometimes :D
[14:57:00] <SWPadnos> heh - that's not "too big" ;)
[15:03:41] <alex_joni> nope, it works ok.. I can read small print barely
[15:04:49] <jepler> SWPadnos: on my system, xev shows it as KP_Begin (numlock off) or KP_5 (numlock on)
[15:05:12] <SWPadnos> ah - Begin - that's what I was looking for
[15:05:14] <SWPadnos> thanks
[16:02:19] <mxxxxxx> moin
[16:02:29] <mxxxxxx> alex zufällig da ?
[16:03:17] <alex_joni> mxxxxxx: jo
[16:04:03] <mxxxxxx> juhuuuu ;)
[16:04:15] <mxxxxxx> eben warst noch bei Peters CNC Ecke
[16:04:19] <mxxxxxx> aber ich hab Dich verpasst ;)
[16:04:36] <mxxxxxx> hab seit 2 Tagen mit nem Fehler zu kämpfen gehabt
[16:04:41] <mxxxxxx> und scheint am CVS zu liegen....
[16:04:44] <mxxxxxx> http://5128.rapidforum.com/topic=115669760024
[16:04:46] <alex_joni> mxxxxxx: waer am besten wenn du englisch in hier sprechen koenntest :)
[16:04:53] <alex_joni> mxxxxxx: I saw that..
[16:05:02] <mxxxxxx> ok, no problem
[16:05:37] <alex_joni> mxxxxxx: so you reported an following error problem (ferror is related to the joint position)
[16:05:49] <alex_joni> this only happens with CVS-TRUNK not with 2.2.x
[16:06:02] <alex_joni> code to make it happen pastebin.ca/895104
[16:06:36] <alex_joni> mxxxxxx: am I correct?
[16:06:41] <mxxxxxx> yes
[16:06:45] <mxxxxxx> very nice ;)
[16:06:55] <alex_joni> (I only wrote the stuff in here, because I need to leave.. but maybe someone else can look at it)
[16:07:11] <alex_joni> mxxxxxx: it would be best if you could open a bugreport at sourceforge.net/projects/emc
[16:07:14] <mxxxxxx> I mentioned that
[16:07:22] <alex_joni> (then it's certain it won't get forgotten)
[16:07:50] <mxxxxxx> ok, I'll do that
[16:07:50] <alex_joni> mxxxxxx: can you make the bug happen with any of the sample configs?
[16:08:08] <alex_joni> if not, please attach your config (ini mainly) to the bugreport
[16:08:17] <alex_joni> mxxxxxx: thanks for the report.. gotta run home now
[16:08:21] <mxxxxxx> I have to try that, I just tested TRUNK and 2.2.2 with my config, but I try the stepper_mm
[16:08:33] <alex_joni> mxxxxxx: sounds great
[16:08:35] <mxxxxxx> kk, thanks
[17:00:30] <Roguish> good morning all. question about gantrykins?
[17:01:35] <Roguish> gantrykins was modified to include all 9 axes, but there is one line that still only references 6 axes:
[17:01:38] <Roguish> char *coordinates = "XYZABC";
[17:02:00] <Roguish> shouldn't that line also include 'UVW' ?
[17:02:49] <Roguish> jepler: cradek: SWPadnos: ????
[17:03:25] <jepler> Roguish: no
[17:03:53] <Roguish> why not?
[17:04:18] <jepler> coordinates is intended to be defined on the halcmd 'loadrt gantrykins' line, e.g.,: loadrt gantrykins coordinates=XXYZ
[17:05:01] <jepler> the default doesn't matter, anyone who is using gantrykins will be setting the mapping from axes to joints by specifying coordinates= on the loadrt line
[17:05:21] <fenn> xxyz doesn't do anything
[17:06:03] <fenn> gantrykins has some hal params defining which joint/axis to double
[17:06:47] <Roguish> the 'stepper-gantry' example does not do that. there are no axes specified with the 'loadrt gantrykins' line.
[17:07:10] <fenn> setp gantrykins.joint-3 1 is the magic line
[17:07:15] <fenn> for an xyyz system
[17:07:29] <fenn> change that to setp gantrykins.joint-3 0 for xxyz
[17:07:31] <jepler> halcmd: loadrt gantrykins coordinates=xxyz
[17:07:36] <jepler> halcmd: show param
[17:07:36] <jepler> Parameters:
[17:07:36] <jepler> Owner Type Dir Value Name
[17:07:36] <jepler> 32769 s32 RW 0 gantrykins.joint-0
[17:07:36] <jepler> 32769 s32 RW 0 gantrykins.joint-1
[17:07:39] <jepler> 32769 s32 RW 1 gantrykins.joint-2
[17:07:41] <jepler> 32769 s32 RW 2 gantrykins.joint-3
[17:07:56] <jepler> so I guess either the coordinates= or the setp method can be used to set the mapping
[17:08:10] <Roguish> docs on that?
[17:08:32] <jepler> no, I read the source code
[17:08:32] <fenn> ah the coordinates= is not the same as COORDINATES=
[17:08:51] <fenn> in the ini files
[17:09:57] <jepler> fenn: the hope is that for an appropriate [TRAJ]COORDINATES setting, you could use 'loadrt gantrykins coordinates=[TRAJ]COORDINATES would work but I don't know what happens since [TRAJ]COORDINATES is often specified with embeeded whitespace (e.g., "X Y Z")
[17:10:06] <fenn> if you want it to work, rather than finding obscure bugs, you might want to use xyzx instead of xxyz
[17:10:40] <fenn> jepler: does hal syntax support quoting?
[17:10:54] <jepler> fenn: no, it's a fucking mess
[17:11:03] <Roguish> i am not looking for obscure bugs. i just need a gantry with 5 axes.
[17:11:11] <fenn> Roguish: :)
[17:11:18] <Roguish> that would be 6 motors.
[17:11:42] <Roguish> SWP mentioned the other day that one can only load 1 'kins'
[17:11:49] <Roguish> is that correct?
[17:11:51] <jepler> Roguish: yes that's correct
[17:11:54] <fenn> yep you'll have to merge the two modules
[17:12:04] <jepler> Roguish: you will have to write source code to "combine" 5axiskins and gantrykins into a single kinematics module
[17:12:15] <Roguish> that's why i am looking at the
[17:12:30] <Roguish> c files. for both 5axiskins and gantrykins.
[17:14:03] <Roguish> not being programmer, i was just looking for patterns, and i noticed the missing UVW on that line in the gantrykins.c file.
[17:16:08] <cradek> 5axiskins is only appropriate for one style of 5 axis machine. You are going to have to write kins for yours, and you are probably going to need a programmer's help to do it - he should definitely be good at trig.
[17:16:25] <jepler> fenn: here's what I recall I discovered when I tried to figure out why 'loadrt hal_parport cfg="378 in 278"' works in RT, but not in sim (aside from the fact that hal_parport isn't appropriate for sim)
[17:17:06] <jepler> fenn: it appears that halcmd simply splits on whitespace, so it invokes execv with the argv [..., "hal_parport", "cfg=\"378", "in", "278\""]
[17:17:34] <jepler> in RT that eventually becomes an 'insmod' command, and apparently insmod re-parses that into a single argument cfg="378 in 278"
[17:17:39] <jepler> while rtapi_app doesn't have that parsing magic
[17:18:24] <jepler> on the other hand, when you type at the shell: sudo insmod hal_parport cfg="378 in 278" the argv is [..., "hal_parport", "cfg=\"378 in 278\""]
[17:18:34] <jepler> because the shell understands quoting when it splits words
[17:19:06] <jepler> so for RT systems, it is likely that coordinates="[TRAJ]COORDINATES" would work if COORDINATES has embedded whitespace, but it would fail on sim
[17:19:07] <cradek> jepler: at the shell those quotes would be removed before they get to argv
[17:19:14] <jepler> cradek: er, you're right -- thanks
[17:19:29] <jepler> this is what I should have said: [..., "hal_parport", "cfg=378 in 278"]
[17:20:20] <jepler> IMO it makes more sense to modify halcmd so that its word-splitting is more sophisticated and it doesn't depend on this behavior of insmod (which I don't believe is documented anyway, so who knows if it will stick around)
[17:20:26] <jepler> but I haven't actually done anything about it
[17:22:19] <cradek> what I always say about writing a new interpreted language must also apply to writing a new shell
[17:25:05] <alex_joni> jepler: I think there were some magic bits in halcmd to do the splitting
[17:25:26] <alex_joni> but it was hard to find a "right" fix for all platforms tested back then
[17:25:31] <alex_joni> so it might have been removed
[17:33:06] <jepler> if only halcmd were written in python, we could use its built-in shlex module...
[17:36:07] <skunkworks_> stupid question (mainly because I haven't gotten that far..) you can run .py files - I assume there must be a way to 'compile' then into executables?
[17:36:28] <fenn> yes but it goes against the 'theme' for hal
[17:36:41] <skunkworks_> I ment python in general
[17:36:57] <jepler> skunkworks_: It depends what you mean by "compile" and "executable"
[17:37:27] <fenn> one can make standalone .exe files, but python also makes .pyc files which are a compressed bytecode (?)
[17:37:48] <jepler> fenn: I don't think they're compressed files, but they are bytecode
[17:38:46] <jepler> it exists, but there's virtually advantage to using "freeze", which is the Python utility that converts a group of .py source files into a single executable binary
[17:39:53] <jepler> it's only marginally faster to start, no faster to run; it probably takes more disk space than the .py and .pyc files on its own; and you end up duplicating the contents of a bunch of .pyc files that are probably already installed on your (linux) system anyway
[17:40:21] <jepler> the equation is a bit different on windows, where you can't depend on a modern installation of python already being available -- there it might be a sensible way to distribute a python application.
[17:40:38] <fenn> disk space is cheap these days
[17:40:45] <skunkworks_> That is mainly what I was wondering - thanks
[17:41:37] <jepler> I think this is specific to windows:
http://www.py2exe.org/
[17:41:44] <jepler> "py2exe is a Python Distutils extension which converts Python scripts into executable Windows programs, able to run without requiring a Python installation. "
[17:45:43] <skunkworks_> * skunkworks_ saves that link.
[17:45:46] <skunkworks_> Thanks
[17:49:27] <skunkworks_> heh - the vb guy here is anal about tab indenting.. But doesn't like the fact that it is requred for blocks in python.
[17:49:34] <skunkworks_> tabbing/spaces
[17:51:58] <skunkworks_> he is a bit rigid.
[17:59:57] <SWPadnos> sigh. it's always the time when you need to get things done that everything around you becomes high maintenance
[18:00:03] <SWPadnos> and everyone
[18:04:23] <alex_joni> SWPadnos: that's expectable
[18:04:34] <SWPadnos> yeah, in theory
[18:04:48] <SWPadnos> so - do you know anyone who has been arrested for walking in the road?
[18:05:01] <SWPadnos> that happened to my sister a couple of days ago
[18:08:30] <alex_joni> in the road?
[18:08:32] <alex_joni> or on the road?
[18:08:43] <SWPadnos> well, on - she's not that heavy
[18:09:49] <alex_joni> heh
[18:10:09] <alex_joni> strange .. that she got arrested
[18:10:20] <SWPadnos> she met all sorts of interesting people in jail - talked to quite a few of them
[18:10:22] <SWPadnos> yes, I agree
[18:10:46] <SWPadnos> the sidewalks in Galveston really suck, and she was headed to the beach to watch the sunrise (like she does just about every morning)
[18:12:07] <fenn> http://www.stillmadeinusa.com/blog/2006/01/why-im-drinking-more-coffee-in-2006.html
[18:12:47] <fenn> a related incident
[18:14:02] <SWPadnos> indeed
[18:27:08] <alex_joni> heh, a guy is whining on the rtai mailing list that his latency sucks with the nvidia proprietary driver
[18:27:20] <alex_joni> and that he payd money for the fancy & fast GPU
[18:27:37] <alex_joni> yet his latency is better without HW accel :)
[18:36:30] <SWPadnos> hmmm. that does mean what I thought - the CVS server is unavailable
[18:36:45] <SWPadnos> at least via webcvs
[18:37:04] <skunkworks_> hmm - raining there?
[18:37:09] <SWPadnos> dunno
[18:37:11] <skunkworks_> I would not think so.. ;)
[18:37:26] <SWPadnos> we've got a foot or more of snow, but that probably didn't have any effect :)
[18:37:49] <skunkworks_> heh - we just missed the snow dump they got south of us
[18:40:53] <fretless85> alex_joni, hey alex
[20:09:01] <CIA-22> EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/halcmd_commands.c: fix several typos in comments
[20:15:32] <CIA-22> EMC: 03flo-h 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: yY should be translateable, misunderstood this
[20:59:55] <Roguish> jepler: i'm going to 'attempt' to combine 5axis and gantry 'kins' into one. plan is to do a cvs on trunk and merge gantry into 5axis so i don't have to mess with altering any of the 'make' stuff.
[21:00:15] <Roguish> is my plan ok? or is there a simpler approach.
[21:03:21] <skunkworks_> as cradek said - you need to make the 5 axis kins for your machine.
[21:04:01] <skunkworks_> <cradek> 5axiskins is only appropriate for one style of 5 axis machine. You are going to have to write kins for yours, and you are probably going to need a programmer's help to do it - he should definitely be good at trig.
[21:06:16] <Roguish> his '5axiskins' is the appropriate style, i just need to add a 'slave' axis on the Y.
[21:06:40] <Roguish> call it 'V'
[21:06:48] <Roguish> or 'Y2'
[21:09:19] <SWPadnos> Y2 has more characters than "Y" :)
[21:10:33] <Roguish> point taken. i don't need to muck with trig, just the slaving part, which is what gantrykins does.
[21:10:58] <Roguish> how 'bout you guys changing the whole thing so we can load more than one 'kins' file?????
[21:11:05] <SWPadnos> nope
[21:11:08] <SWPadnos> :)
[21:11:31] <Roguish> didn't think so, didn't expect you to.
[21:12:07] <SWPadnos> it would be nice if there were a way to have some HAL module other than the motion controller able to communicate with the GUIs (outside of HAL signals)
[21:12:33] <SWPadnos> I think that's the reason the gantry thing has to be in kins - so you get to jog and such in the GUI
[21:12:48] <jepler> it doesn't make sense to "stack" kinematics in general -- what would it mean to cascade the scara and puma kinematics together?
[21:12:56] <SWPadnos> right
[21:13:10] <Roguish> one has to be reasonable.
[21:13:34] <SWPadnos> it does make sense to have some custom stuff on one or more axes, and have that stuff accessible from the GUI
[21:13:44] <jepler> it seems like a simple modification to 5axiskins to produce the pos->y value on two items in joints[] so I must be missing the problem
[21:13:47] <SWPadnos> (for example homing multiple slaved axes and whatnot)
[21:14:19] <Roguish> in looking at both c sources, i think i can do it.
[21:14:22] <jepler> you might need to increase EMCMOT_MAX_JOINTS beyond its current value of 9
[21:14:47] <jepler> depends if you want to use joints[9] (e.g., one past W) or joints[3] (e.g., where the unused A value is now)
[21:15:12] <SWPadnos> oh right - UVW are actually used in 5axis
[21:15:33] <SWPadnos> so the unused rotary would be an easy but unmaintainable* way of doing it
[21:15:36] <jepler> yes, if you're going to use UV for motion in the coordinate system of the tool, you have to loop back the joint values that correspond to UVW
[21:15:55] <SWPadnos> * - unmaintainable in 6 months when you have no idea why C is being output Y2
[21:16:16] <SWPadnos> ^ to
[21:16:17] <cradek> if you use a rotary you better not ever change your units with g20/g21
[21:16:30] <SWPadnos> boing!
[21:17:29] <SWPadnos> cradek, is that really true?
[21:18:04] <cradek> I haven't thought through all the results, but g20/g21 definitely change units on XYZUVW and not ABC
[21:18:12] <SWPadnos> ah - hmmm
[21:18:26] <skunkworks_> abc don't have a metric/english degrees ;)
[21:18:44] <Roguish> abc are 'absolute', yes?
[21:19:03] <cradek> apparently all the world can agree that rotation is in degrees (<- irony)
[21:19:05] <SWPadnos> yeah. thinking about it very little, it seems that ABC shouldn't have to change with G20/G21 - the TOV doesn't change
[21:19:15] <SWPadnos> heh - not radians or grads?
[21:19:20] <cradek> certainly not
[21:19:55] <Roguish> i realize this is a 'hybrid' machine.
[21:20:12] <Roguish> but a very real configuration.
[21:20:12] <jepler> I don't see what that has to do with producing a copy of the Y-axis commanded position on joints[3]
[21:21:17] <cradek> you're probably right
[21:22:47] <Roguish> in the 'stepper-gantry' configuration, axis 3 is defined as LINEAR. wouldn't that be screwed up by g20/g21?
[21:23:24] <SWPadnos> you want it to be screwed up that way
[21:23:31] <cradek> I doubt those declarations actually do anything
[21:24:21] <Roguish> [AXIS_3]
[21:24:23] <Roguish> TYPE =LINEAR
[21:24:39] <cradek> but jepler is right and the units are only important in the interpreter
[21:24:47] <Roguish> you mean the TYPE does nothing? then why is it there?
[21:25:03] <cradek> I suspect it does nothing
[21:26:33] <jepler> they are used to help find the 'units' value eventually passed to emcAxisSetUnits(). For instance, if it says LINEAR then [TRAJ]LINEAR_UNITS are used if [AXIS]UNITS are not specified, otherwise UNITS is parsed using the list of linear units such as inch, mm, and so on.
[21:27:08] <cradek> the one who actually checks the source code is right
[21:27:29] <cradek> you might also expect them to control whether they honor g20/g21, but that's not the case
[21:27:40] <jepler> that value is put in stat[axis].units ...
[21:28:27] <SWPadnos> hmmm. that's a bad thing - I suspect it's from the days when joints and axes were the same thing
[21:28:29] <SWPadnos> like now, sometimes
[21:28:37] <jepler> this one aspect of the inifile not clearly making a distinction between joints and axes. make sure you just sit and bitch about it, because otherwise it will never just fix itself.
[21:29:10] <SWPadnos> ok. so if people bitch enough it will fix itself? :)
[21:29:18] <cradek> that's what I'm going to continue trying
[21:29:51] <jepler> SWPadnos: if at a time 't' it is still unfixed, then at time 't' the amount of bitching has been insufficient so far
[21:30:20] <SWPadnos> hmmm. how to test that theory ...
[21:30:35] <jepler> unfortunately this doesn't help predict how much bitching is actually necessary
[21:30:57] <SWPadnos> I suppose you could say that if at time 'T' it isn't fixed, then integral [0..T] bitching(t) wasn't sufficient
[21:31:16] <SWPadnos> no indeed. it's s bit like religion
[21:31:21] <SWPadnos> s/s/a/
[21:31:46] <Roguish> i didn't mean to start a row. just understand what's going on.
[21:31:59] <cradek> not your fault. we're always like this
[21:32:04] <SWPadnos> no problem. I think we're joking :)
[21:32:05] <Roguish> oh, ok.
[21:32:09] <SWPadnos> (at least in part)
[21:32:37] <Roguish> how 'bout a simple (read: stupid) programming question?
[21:32:50] <cradek> Roguish: as I've said before support for machines this complex is very new and not done yet
[21:33:13] <Roguish> ...to go where no man has gone before.
[21:35:22] <Roguish> if i compile a new 5axiskins, does the 'make' relink the whole code?
[21:35:48] <SWPadnos> if you change an existing file, it will be remade
[21:36:07] <cradek> one make builds everything in the tree that needs it
[21:36:13] <SWPadnos> the realtime code isn't quite linked at compile time - that's what module loading does for you
[21:36:37] <Roguish> so i just have to do the 'make', not the './configure', correct?
[21:36:42] <cradek> yes
[21:36:44] <jepler> right
[21:36:59] <Roguish> cool. that's what i was hoping.
[21:38:11] <Roguish> i don't mean to be a PITA, but i have a client with gantry machine that wants B and C axes added.
[21:38:38] <Roguish> it on FLASHCUT now and the proposal is EMC2.
[21:38:59] <jepler> cool, the extra income from a 5-axis emc license will help me buy a new car this year
[21:39:30] <alex_joni> jepler: don't forget additional extras
[21:39:42] <Roguish> me too.
[21:39:45] <SWPadnos> like S-words
[21:39:46] <alex_joni> like 'extension to use the tooltable'
[21:39:53] <alex_joni> and s-word, yeah
[21:40:10] <Roguish> and a new post.
[21:40:18] <jepler> Roguish: except in my case I was joking about the money. funny, that.
[21:40:41] <Roguish> they just spent $47k on a cam program.
[21:41:18] <Roguish> 'cause mastercam won't do 3d contouring on stl surfaces.
[21:41:50] <SWPadnos> what a piece of excrement
[21:43:53] <Roguish> well, i'm going to try this. i will be doing a lot of RTFMing on programming, but i may still ask a few silly (read: stupid) questions.