unless someone has very huge units/counts, but then the jump is still small
alex: you are confusing me
counts are irrelevant
suppose the home position is at the left end of the table
and someone shut the machine down when it was at the right, 500mm away
when you turn on, it will treat that as 0
when you do the home, the position command and feedback will both be at -500 when you hit the index
suddenly both are reset to zero
the craptacular maxnc software would save the position when you exit, and it would be there next time
why don't we do that?
cradek: different topic
can't argue with that
but I thought about that too ;)
that could be nice, but if the machine has cranks, somebody could still move it while off
some other time
so you still need to home
sure, it doesn't make home unnecessary.
jmkasunich: if you don't have brakes
on robots we check the index pulse against the stored position
but for steppers without home switches, it would be pretty nice
if it matches we assume machine is ok
if it doesn't .. then you need to home
of course this is with brakes applied while machine is off..
sorry, I'll bring this up some other time (or I'll just write it)
back to topic ;)
cradek: if "just writing it" is gonna require the ability for emc to stuff a value into the encoder counter, then it will affect the "canonical encoder interface" that we are discussing, and is appropriate
if it can be done without stuffing a value, thats much better
jmkasunich: it will probably write the value to a file, and reload on startup
reload where though...
into the encoder counter, or into something inside the motion module
motion I'd say.. but rather in task or higher
back to homing
today the axis encoders never change (except when the shaft moves) and we home and offset and everything else by adding offsets inside the motion controller
now we're talking about having the encoder counters change
if rotary are used, several absolute positions with several 'near home' dogs can be used, eleminating very long homing traverses
always less than 1 rev
tom, please don;t make things any more compilcated than they already are
tomp: that may or may not be what you want, depending on the app
jmkasunich: sorry, can't stay up longer & be usefull at the same time :(
I'm replying to Jon again
let me know if you have any more on this
maybe I can convince cradek to brainstorm with me on this
good luck ;)
anyone here ?
Well hi Matt.
hey ray, I got on here to see if you were awake yet
rayh: your phone's busy...
Yes it is. Ma's talking to the kinds in Germany.
She's off the phone now.
just thought i'd catch up with you, been busy but i figured we should get our heads together re fest & hnc
can't type at all.
mshaver: everything ok lately?
mshaver: nice to hear that.. same here, just busy
ok, going away for a ahile
steves_logging is now known as steve_stallings
morning all, quick look in before going off to re-roof my shed
Matt - we have room reservations Wed to Sat nite, same place
talking to ray on the phone
Gotta run in 5 min, see you later.....
steve_stallings is now known as steves_logging
won't be here long today, we're leaving for a baseball game when my wife gets home from church
I was talking with matt this morning. We plan to bring a couple of modbus devices to fest.
One is simple PLC, the other a spindle drive.
no such thing as a simple PLC
How about cheap.
spindle drive, now that can be simple
a few digital pins for start/stop, a few analogs for spd cmd, feedback
I'll put together an ac motor and encoder.
Matt already has the AC drive.
my project for the next few days (driven by jon's attempts to get his stuff to do threading) is to define a canonical encoder, make homing work with it, and redo all the HAL encoder drivers to match
I'll try to assemble complete info on them.
That sounds like a great plan.
so hopefully when we get to fest, we can make the mazak home in index, not just switch like it is now
home _on_ index
That would be a good step forward.
yeah, index is nasty enough that we've been avoiding it
Matt says that he is working on FredP to attend.
jmkasunich: in your canon encoder, will the motion controller still be able to tell it whether or not it should be resetting on index pulses?
yes, the canon encoder will probably be identical to (or very similar to) the existing software encoder counter
as you already know, that's how threading works right now
the work at hand is to fix the homing code to work with the "reset on index" behavior
right, threading _needs_ reset on index
ok great, having a simulated encoder that does everything right is vital for testing
homing (so far) doesn't like that
and giving us a reference implementation to point to when someone wants to add an encoder driver is nice too
ok, I understand now, thanks
just added limit and home switches to my more complete simulation (which will be used to test homing to index)
gonna commit that if you want to play with it, its time for me to leave for baseball
back in about 4-5 hours
I've got a date too
ok later then
sounds like jmk is making progress
this will be lots of thinking before it's right, though
Yes it will. Years ago I argued for a third axis type in emc itself.
we have linear and angular which is wrapped linear.
what was the 3rd one?
Oh. the rotary now is named angular
yeah, it's the same..
so you'd have linear/angular/rotary
I can see very limited usage of angular vs. rotary
at least at the current state of emc
I don't at all
IF it were a bit smarter you could define some run-time kinematics, based on that
but that's far from trivial ;)
wrapped linear is the normal way to operate stuff like z,b,c
A B C
Rotary is stuff like spindles.
RPW might be handled different than ABC though
ABC is workpiece turntables
RPW is tilting/rotating the head/spindle
Right. That is why angular is different from rotary.
but then again you'd still need kins to do RPW properly..
You would for stacked A/B also
I think that Graham-Sperry guy in England was working on the stacked thing.
never heard of him
Paul met with him a time or two. He's a college prof. Planned on his students building the 4'th and 5'th setup and then writing the kins and tool tip feedrate.
yeah, that's a nice thing to do ;)
not many users though:D
* alex_joni is thinking of building a Z axis for that sherline slides
I've often thought that a little gantry with z would be the ticket
gantry might be too much ;)
or you mean a fixed gantry?
oh, so only a support for the Z axis?
is that needed for those small sizes?
Not to much. The stock Sherline Z mount is really pretty solid.
Does your Y base have an extension and 4 mounting holes opposite the motor side?
hmm.. not sure
don't think so
That is where the standard z base bolts down.
but you can build a plate below the xy table and bolt z to it.
yeah, that's my plan
hiya folks. how're things?
that's good :)
* alex_joni installed cvs3
arggh - this wireless network is a bit unreliable
SWPadnos_ is now known as SWPadnos
"The CVS3 is a contour vision sensor that can be taught in via a keypad and a ..." <-- this cvs3?
for us, cvs3 is a backup cvs server
just like cvs2
did someone remove simio?
cradek: I did a while ago.. a few weeks/months?
cradek: any reason to still have it?
I'm just still sorting out all the changes
ok..you scared me ;)
I think all the needed packages are installed ont his freebsd
you know what I don't see in that list? /pkgs ?
or is that part of cvs ?
I don't use cvsd
wth is going on in #emc?
asciiart 4 dummies 101
maybe trying to get bo's questions to scroll off, I dunno
maybe I'll have new packages done tonight
cradek: cool.. you can add a newsflash to www.linuxcnc.org if you like
or I'll do it tomorrow ;)
ok maybe I'll try to figure it out