jmkasunich__: thanks for this parport breakout thingy
when you gave it to me, I thought "whatever, I don't need that right this second"
but, I've used it a lot
I'm often shortsighted that way
(like the ballscrews at boeing surplus)
there's a boeing surplus in wicheta?
they were $5 each
and I didn't take them
O_O O_O O_O
I just couldn't come up with any use for them right then... (um, still can't)
I guess I need to drive there, maybe with a trailer
there are few gems there, lots of junk you don't care about
CNC - err - garage door opener!
a 6x12 trailer
they were shortish
16" long maybe
12" travel maybe
long enough for a shoptask Y
that's plenty for a bridgeport Z also
true but who needs that? bridgeports come with ballscrews already on them unless you really mess up :-)
or get a manual mill ...
or are currently building a hexapod with 18" screws
they're probably not there now.
that's why you have to snap them up when you see them!
there's also ebay, for those so inclined
cradek: maybe the RC filters mean you have much higher step lengths needed?
the datasheet matches your numbers, but my drives want more
I set step reset time to 6us and it works now
ouch. what's the BASE_PERIOD?
including the rotary
oh, that's quite large then
* jepler tries to remember if any of his systems *require* probe_parport
jepler: I don't spot the pin 14 problem right off
oh! yes I do.
jepler: the axis test in stepgen doesn't work for me, but the generated configuration does now
jepler: to get the rotary to work right, I set [TRAJ]MAX_VELOCITY to 999999
jepler: that needs to be higher than the highest velocity
"A" axis test?
or any axis test?
maybe they don't set the stepper params?
I think it misses parport.0.reset-time in the test?
that would do it
try this? http://pastebin.ca/735852
jepler: the rotary ferror are too small
jepler: I changed the default traj maxvel, so just don't write that out
jepler: that patch fixes the online test
jepler: I can set accel=0 in the online test, I don't know if you intend that or not
what nonzero accel limit should I have?
I don't know
I think you know this already - the jog buttons and the back-and-forth test have very different velocities
yeah we talked about that
cradek, I think the default TRAJ limit needs to be low
the default limits on A should be -large to +large
good evening. help with a small error? 'emc/task/emctask.cc 312: interp_error: Coordinate system index parameter 5220 out of range'
if a limit isn't specified in an axis section, that axis gets set to traj default
SWPadnos: oh, ouch
I think it's meant to be a safe default, not a sane one :)
SWPadnos: maybe make those default to 1 instead of this one
Roguish_: your var file is messed up, edit it and make sure 5220 is set to 1.0
Roguish_: what is the last thing you did that might have caused it?
I hope nobody relies on it, but you could set TRAJ to 3, and remove the limit from all the axes, and use that one spot to change them all
i'm adding gantrykins to a m5i20
Roguish_: could it be this? http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UpdatingConfigurationsForDevelopmentVersions#var_file_changes
cradek: better. thanks. at least the axis gui comes up. where would i find a correct 'new' var file?
if you changed 5221 to 1, then you now have a correct var file
err - 5220
Roguish_: in the configs/common directory, for one
i changed 5220 to 1.
I suggest getting a new var file
to make sure it has all the right lines in it
just did. thanks again.
jepler: thanks, I got jdi.py going. Fixed my install mess and things work.
I didn't have the concept of 'run-in-place' : )
thanks again. i'll be back at the gantrykins in the morning.
cradek: did you or did you not spot the cause of the pin14 problem?
it looked to me as though he did
there was a commit mentioning a copy/paste error
oh now I see the checkin
SWPadnos: did you see code to make TRAJ MAXVEL be the default for AXIS MAXVEL or were you just remembering that behavior?
because I see code that defaults it to 1
I thought it used a default value for TRAJ, then used the traj value for any axis that didn't have its own setting
default if there's no tRAJ setting, that is
that doesn't appear to be the case
1 unit/s is a strange default, but whatever
that's actually pretty fast for inches
unless you object I'm going to leave my change for now
try taking out the TRAJ MAXVEL setting and see what happens
well, we know what happens I guess
I did, it does what I want
testing some more...
what happens if you leave out individual axis maxvel settings?
you do get 1.0
that was what I thought defaulted to [traj]maxvel
then I have no problem leaving it as is
axis, keystick, and xemc all read [TRAJ]MAX_VELOCITY
I'm not sure what they do with it
they incorrectly set the top of the jog speed slider
that could be a problem ;)
there's got to be an NML message (or something in status) to get that setting with
axis knows how to read other things instead: MAX_LINEAR_VELOCITY, MAX_ANGULAR_VELOCITY
I don't know what the general solution is
I didn't touch any other configs; there's no harm in leaving that value in there
(except it bites people when they try to add a rotary axis)
i have what appeared 3 hours ago to be a simple task: return the x,y,z coordinates of an object in vismach
is there something missing? like reverse traversal of the tree?
i'm trying to implement a Track transform that points one object at another
fenn: you can use minigl.glGetDoublev(minigl.GL_MODELVIEW) to get the 4x4 matrix that represents the current transformation
(returned as a 16-element list, not a matrix)
yes but how do i get to the object to do that and then return it?
it seems i'd have to traverse the tree until i find the one i'm looking for
fenn: a Capture object grabs a copy of its modelview matrix each time it's traversed
.. in its self.t property
you can arrange to have a Capture at one point in the hierarchy, and use its .t at another point in the hierarchy
so i can do object.t.capture()?
or is t the matrix i want?
Capture is an object you put in the tree, like a Sphere or a Collection
its .t gets updated when that part of the tree is traversed
* fenn tries
(by the automatic redraw procedure)
# note that this tranforms from the current coordinate system
# to the viewport system, NOT to the world system
cant you get the world system with a different gl call?
no, the world system isn't really stored anywhere by opengl
so i will need to pass the tool Capture to my function also right?
where tool is the tool coordinate system
or i guess i could just do Capture() and pass that
and then use your view2world
you want to have a reference to the Capture() object, and look at its .t
and that's all i need to do to get world coordinates?
you'll probably need a second Capture() object which is at the outermost level of the model; its .t will reflect the transformation from model to view before any other transformations are applied
read the gymnastics that vismach.py:O.redraw() does to make the 'backplot'
there are a lot of steps and I'm having trouble articulating them ..
not also the comment on the invert() function that it does not work for matrices which include scaling; I think you added scaling classes?
yeah i noticed that.. i might just remove the scaling stuff
is there a better way to revert a cvs change than: check out old revision, copy to another name, delete old revision, check out new revision with no tags, copy old file to original name, commit
cvs up -p -r220.127.116.11 file > file
Roguish_ is now known as Roguish
stepper-gantry/stepper.hal:22: setp requires 2 arguments, 3 given
easily fixed, but i wonder when/why that happened
its INPUT_SCALE = 150.333 0
nevermind, i was just out of date
jmkasunich__ is now known as jmkasunich