yeah, teleop is truly bitrotted
I got impatient waiting for the MDI to unwind B, so I tried to go back to the manual tab
it popped up an error message (which I don't remember), and then popped out of $ mode, back to numbered axes
and of course now I its stuck in that mode
"all axes must be homed before going into coordinated mode"
even immediately after I hit home all
its gotta be that mess of homed state flags
yeah I bet so too
good or bad news I dunno: teleop accel is also wrong in rt
good I think
I thought I fixed that once already
I wonder if it's a units problem. This is a metric config.
differences between sim and rt are bad
* jmkasunich draws a ball by jogging in joint mode
$ grep _FLAG *|wc -l
those aren't even the ones I was talking about
(and most of them aren't homing related)
teleop uvw are totally missing
things like "all_homed" in control.c, and JOINT_HOMED_FLAT, JOINT_AT_HOME_FLAG
checkAllHomed() in command.c
all kinds of nasty intercoupled stuff
* cradek hides
* jmkasunich hid a long time ago
(from that stuff anyway)
there is serious bustage in the axis vs. joint distinction (or lack thereof)
checkAllHomed() returning false is the condition that causes the "all axes must be homed before going into coord (or teleop) mode" error
MAX_ACCELERATION = 800.0
DEFAULT_ACCELERATION = 800.0
this makes teleop work better
it returns true if emcmotDebug->allHomed is true
but teleop smashes right through soft limits...
if not true, it tests the HOMED_FLAG for all joints, and if all are homed, it sets emcmot_debug->allHomed and returns true
if any joint is not homed, it returns false, and doesn't touch allHomed
the problem with teleop and limits is that you don't know what limits to apply
are the limits in the ini file applied to the raw joint pos, or to the cartesean coord?
limits are on joints, teleop moves in world
maybe turning C causes X to move out of range
goodnight - nice to see you around again
hey cradek - why do you make a new hal pin for motion instead of just grabbing it from emcStatus in the kinematics code?
I thought it would be nice to have on a hal pin (not necessarily for use in kins)
is emcStatus even available in kins? they are just modules...
yes, unfortunately :\
emcStatus is available
there's no "x input" for example
you have to do emcStatus.tran.x
kins modules have 3 functions that are called by motion
type, forward, inverse
er.. well, it's something like that
x = world->tran.x;
I agree the EmcPose structure is a little goofy if that's what you're saying
it should be three PmCartesians
but ... it's not
(and it would be silly to change it)
aroo.. i think i'm off my rocker
or i fell through a time portal
anyway, emcStatus isnt in kinematics anywhere now that i look
ok, I'll remove my baffled look then
cradek: I've been doing 3D stuff all day again
and one feature I really use when drawing 3D stuff is the scroll button (zooming) to pan around
it usually zooms towards the point where the mouse is positioned
so zooming with the mouse in the middle of the screen is quite different than zooming with the mouse close to an edge
would this be something to consider for AXIS? I think it's a bit more intuitive..
I agree that would be great
I know other software that does it like that
I wonder how hard it is to do
in an ortho view, probably not too hard - in perspective, probably harder
yeah, perspective is the one I was talking about
does AXIS treat ortho differently?
or just a special case of perspective?
on another program I have it always rotates around a certain point. but I can change that point (by double clicking the middle button)
it puts a point at the intersection from the current view with the first solid it finds
they're different, because you have to do something different in gl to get ortho
cradek: ok, gotcha..
03tissf 07TRUNK * 10emc2/docs/src/config/ (9 files): French translation
03tissf 07TRUNK * 10emc2/src/po/fr_axis.po: French translation
03tissf 07TRUNK * 10emc2/docs/src/install/ (compiling_emc2_fr.lyx installing_emc2_fr.lyx): French translation
03tissf 07TRUNK * 10emc2/docs/src/ (Submakefile docs.xml index.tmpl index_fr.tmpl): French translation
03tissf 07v2_2_branch * 10emc2/src/po/fr_axis.po: French translation update
03tissf 07v2_2_branch * 10emc2/docs/src/ (Submakefile docs.xml index.tmpl index_fr.tmpl): French translation
03tissf 07v2_2_branch * 10emc2/docs/src/config/ (8 files): French translation
yay more french documentation!
jepler: Why a single parallel port possible with Stepconf? Why not one OR two?
Now you must create Stepconf II ;)
jepler: in vismach, can I make a cylinder (tool) that changes length with a hal pin?
cradek: good question
not at present, but a new class could easily be written. For your purposes, should it be most like CylinderZ, or most like one of the other cylinder classes?
most like cylinderZ
03cradek 07TRUNK * 10emc2/src/emc/kinematics/5axiskins.c: for tool length compensating moves to work
03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/5axisgui.py: make a thing that looks like a spindle.
03cradek 07TRUNK * 10emc2/configs/5axis/5axis.ini: remove stupid comments
cradek: try copying india:/usr/local/jepler/src/emc2/lib/python/vismach.py and use HalCylinder()
03cradek 07TRUNK * 10emc2/configs/5axis/5axis_sim.hal: hook up tool offset to kins
args are comp, z1, r1, z2, r2; if the arg is a string then it's taken to be a component pin name, otherwise it's taken to be a constant
if it doesn't work right away I'll come debug it over your shoulder
yeah isn't that the coolest
I bet fenn also ran into the need for a CylinderZ where the end points are computed based on hal values, instead of hardcoded
for the hexapod linear actuators
jepler: the gcodemodule fix needs to be backported?
actually i just made them move up and down
but i did write a HalScale transform
03cradek 07TRUNK * 10emc2/configs/5axis/ (5axis.var 5axis_sim.hal): 5 axis tool length offset, and tool length visualization in vismach
03cradek 07TRUNK * 10emc2/nc_files/cone.ngc: 5 axis tool length offset, and tool length visualization in vismach
03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/gcodemodule.cc: 5 axis tool length offset, and tool length visualization in vismach
03cradek 07TRUNK * 10emc2/lib/python/vismach.py: 5 axis tool length offset, and tool length visualization in vismach
03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/5axisgui.py: 5 axis tool length offset, and tool length visualization in vismach
alex_joni: didn't we help ray with this PROGRAM_PREFIX thing before?
(it works for me)
cradek: I just answered him
he's using a sample config from /etc/emc2
and those I think have busted PROGRAM_PREFIX values
oh is that what he meant
if you select to copy the config to your own dir, it gets fixed during the copy
at least that's how I understood it..
I read something else entirely, but I can also see your interpretation
(not the best bugreport..)
no, not at all.
I would have liked emc2-version, rip vs. installed, steps to duplicate.. etc
03cradek 07TRUNK * 10emc2/nc_files/cone.ngc: make this less confusing
aw ffs lyx totally munges the entire file
should i run lyx2lyx if i'm using lyx 1.4x?
check the lyx file version
< #LyX 1.3 created this file. For more info see http://www.lyx.org/
< \lyxformat 221
> #LyX 1.4.4 created this file. For more info see http://www.lyx.org/
> \lyxformat 245
yup.. it needs to be 221
oh there's an export 1.3 option
Export in V1.3 is 221?
in case someone ever asks about USB and RT
[20:27:54] <alex_joni> https://mail.rtai.org/pipermail/rtai/2007-October/017940.html
tissf: yes it says 221 in the exported file
03fenn 07TRUNK * 10emc2/docs/src/gcode/main.lyx: added named parameters section, cleaned up wording of numbered parameters.
alex_joni: you broke the stepper-xyza configuration
03jepler 07v2_2_branch * 10emc2/configs/stepper-xyza/inch.ini: revert changes accidentally committed in rev 1.12
03jepler 07TRUNK * 10emc2/configs/stepper-xyza/inch.ini: revert changes accidentally committed in rev 1.12
oh bugger it.. sorry
* alex_joni goes to remove those pesky gamepad.hal's
are there more? I didn't look..
huh.. that was 6 months ago..
I don't see any other commited
jepler: I see it's added in some other configs, but commented out
cradek: did you intend to take these ">>>>>>> 1.5" out of the 5axisgui.py file? 'cause it really doesn't want to compile with them in.
of course i could be full of sh... as you're not done yet...............................
or i did something wrong in a cvs update.
Roguish: that means you edited the file and so did another developer, and cvs couldn't automatically "merge" both sets of changes
Roguish: your changes appear between ">>>" and "===", and the other developer's changes appear between "===" and ">>>"
google "cvs conflict" should turn up more information
at this point you can: remove the file, 'cvs up' again to get the version from the cvs server and discard all your changes, or manually edit the file
ok. that figures. how do i fix it? delete the file and update again?
duh, good guess on my part.
i don't commit any changes to cvs (at least not yet.)
updating now. thanks.
do you have any docs on how all that modelling (box, cylinder, ect.) is written? kinda cool. i'ld like to try and make a model.
you'll get some documentation by typing 'pydoc vismach' (after sourcing emc-environment for RIP)
ok, what do you mean
sourceing emc-environment for RIP )run in place
sorry about the typing. i'm on a little mini keyboard.
Roguish: if you look at tracking-test.py, it has a pretty minimal set of stuff you need to make a new gui/visualization
it can get tricky with setting up the various coordinate systems
ok. i believe that.