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