After seeing micges HM2 stepgen problems I took another look at the firmware, and there is yet another bug in the HM2 stepgen firmware :-(
The bug will show up as occasional dir setup time violations (a single step generated right at DIR output line change) when the step rate
is less than the DIR hold time period.
(I hadn't noticed the problem as I always tested DIR changes with a step rate higher than the DIR hold time)
I apologize for missing this error, have fixed it and will be making new bitfiles in the next day or so
EMC: 03jmkasunich 07TRUNK * 10emc2/src/emc/motion/teleop-notes: some further thoughts on joint constraints
PCW: thanks for the update
PCW: Depending on other things, I think the earliest I'll make a new release is June 13/14
OK, I can send bitfile to people that are having trouble if I know which config they need.
This doesn't explain the dir flapping around problem micges had but does explain the lost counts...
PCW: i think i fixed the "dir flapping around problem" at Fest
it was a pair of errors in my understanding of the interface that hm2 stepgen was supposed to implement
the big one was that stepgen.position-fb need to have sub-count resolution
all that's been fixed and i'm eagerly awaiting micges' report :-)
Great! maybe that addresses all of micges issues
(If i knew what config he is using I could build that first
PCW: he's using 5i20/SVST8_4.BIT, but probably should be using 5i20/SVST8_4IM2.BIT
in what situation would one use encoder index without encoder index mask?
PCW: oops, that's roguish using SVST8_4.BIT, i dont know what micges is using
Its useable but the limit switch needs to be polled to determine when to set index_enable (or whatever its called)
i see - the limit switch would be netted to the index-enable pin on the encoder
index mask up on the PC instead of in the firmware
yep, home switch input used to arm index enable
I guess I need to bump the stepgen rev to 2
again so the driver can warn of old bit files?
i guess the driver should limit step rate of v0 and v1 stepgens to the dirhold time?
shouldnt be a problem most of the time
I think its would be painful to limit the _minimum_ step rate, it really need fixing :-(
ok, i'll stand by for a mongo BIT-file email ;-)
and then we'll ply Jeff with cookies until he releases 2.3.2 ;-)
Cool, Frank Tkalcevic reports on emc-users that he's using SVST8_4.BIT to do encoder home-on-index without index mask
so at least someone has it working
I thought that was the normal setup?
cradek: heh, i bet you're right
the only time i've worked with home-on-index was on your machine, and you requested index masking right away so i thought *that* was the normal way to do it ;-)
I think my machine is the only "special child" that needs index mask
Theres also a race condition that I cant easily fix (Ive known about this for awhile but didnt think it was likely to run into)
So it should probably go in the manual:
The servo thread period - jitter cannot be less than the sum of dirsetup and dirhold times
for modern step drives this this would be hard to violate, for old parker drives with 300 usec times
it may be an issue
(with servo rate > ~1.6KHz)
PCW, wait a sec
dog needs to be fed, nibbling on my ankles...
do you mean the jitter of the servo period cannot be less than (dirsetup+dirhold)? or (ServoPeriod-jitter) cannot be less?
(the setpgen doesn't expect its direction (rate MSB) to change when its doing a wait-for dir hold/setup cycle
so the minimum time between updates is dirsetup+dirhold
only the crazies of systems would violate that
yeah that would be pretty nuts
jmk's fear of BIT files clogging the history is coming true!
alex_joni: when I have to home machine I have few things to do before it
what do you think about aproach like tool change is done: home request out pin, and home allowed in pin in motion?
(just for thinking)
hmm.. not a bad idea (at first glance)
but I think we should think about it some more ;)
maybe have an home allowed which is by default 1, and external can set it to 0
what do you have to do before the first homing motion may begin?
make sure that thc is in safe place for first
make sure that z axis when not homing is in safe position
in your homing sequence couldn't you just home the Z first?
yeah, I'm wavering between "I do that on my mill by having a homing sequence and trusting the operator (me)" and "you know, it wouldn't be terrible if the machine would automatically move to top of Z before homing X or Y"
(but then you have to enforce X and Y *can't* be homed before Z as well, and it's turning into a huge complicated mess that I'm not sure how to specfy in the inifile)
otoh having a prevent homing HAL pin won't be such a problem
kind of a safety interlock
and it's up to the integrator to hook anything up to it
do you want me to add it to the docs first or do you want to program it first :)
in this two-pin-handshake model, what do you do if you request to home X, but Z isn't homed? There's not a "nope, won't work, don't bother waiting" pin in to to the motion controller, so you just sit there forever..
or abort the homing attempt
seems like having the machine just sit there will be pretty confusing. I'd like the design to be able to produce an operator message and abort the homing attempt.
and throw up an error "Homing Failed!"
what, by being hooked to the 'halui.abort' pin?
and how will it be able to move Z all the way up? It can't MDI it, since you're in manual mode at this point..
I don't think this design fits what I am talking about at all
anyway, really, bbl
maybe it should be a pin / axis, and if the motion controller wants to home that axis, and the pin is disabled it just reports an error
can't do homing on axis * while external home-validation is not active
then you can use the axis.2.is-homed connected to the home-validation for X&Y
or something like that
I don't think we need 2 pins.. the home-validation pin should be enough (as an input to the motion controller)
the point is there is no axis.2, there are XY and Z is linked only in hal
the THC has complete control of Z?
after while I think only home validation for homing-all will be usable
above idea was just for thinking
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-05-27.txt
jepler: morning. Still at the fest?
skunkworks350 is now known as skunkworks_
skunkworks_: yep, leaving later this morning
john k will leave in about 10 minutes to drive to kc for his flight
not sure when swp or lerman will head out
there isn't enough time :)
lerman will head out Thursday morning for a 7AM flight.
jepler: did you get a chance to look over stuarts kins?
skunkworks_: not exactly
skunkworks_: we started to look at them, but then he realized that the current version was on a machine that they stole the power supply from to get the dah lih running again
skunkworks_: but I showed him a graphical debugger, because his real frustration is that his function was getting too big to handle comfortably in the text-mode debugger
micges: I am looking at your tolerance patch, and I wonder whether G61 has to now set the naivecam tolerance to 0 .. otherwise, you can get in exact path/exact stop mode with the naive cam detector active, which I don't think is intended.
or is every use of the tolerance value garded by a test of CANON_CONTINUOUS
linkable function: if(canonMotionMode != CANON_CONTINUOUS || canonMotionTolerance == 0)
so you had thought about this
EMC: 03jepler 07TRUNK * 10emc2/src/emc/nml_intf/canon.hh: accept G61 P- Q- to specify separate motion and naive cam tolerances
EMC: 03jepler 07TRUNK * 10emc2/src/emc/rs274ngc/ (gcodemodule.cc interp_check.cc interp_convert.cc rs274ngc.hh): accept G61 P- Q- to specify separate motion and naive cam tolerances
EMC: 03jepler 07TRUNK * 10emc2/src/emc/task/emccanon.cc: accept G61 P- Q- to specify separate motion and naive cam tolerances
EMC: 03jepler 07TRUNK * 10emc2/src/emc/sai/saicanon.cc: accept G61 P- Q- to specify separate motion and naive cam tolerances
EMC: 03jepler 07TRUNK * 10emc2/tests/ccomp/lathe-comp/expected: accept G61 P- Q- to specify separate motion and naive cam tolerances
EMC: 03jepler 07TRUNK * 10emc2/tests/interp/g6164/ (.cvsignore expected test.ngc test.sh test.tbl test.var): accept G61 P- Q- to specify separate motion and naive cam tolerances
EMC: 03jepler 07TRUNK * 10emc2/tests/interp/inside-corners/expected: accept G61 P- Q- to specify separate motion and naive cam tolerances
jepler: I think that should be accept G64 P- Q-
so the commit message is wrong
commit once again to emccanon to point that last commit massage was wrong, to remember
you can edit it...
cradek: john and kim are looking for you to say goodbye
I can't be bothered to 'cvs admin' enough files to fix that commit message
odds are I'd destroy another commit message by mistake anyway
anyway that's not the documentation, the documentation is the documentation
so any confusion is bjt's fault
did BJT make it to fest?
no, he didn't
hmph, why are the runtests failing? they worked here!
EMC: 03jepler 07TRUNK * 10emc2/tests/ccomp/lathe-comp/expected: update expected results for g64 change
EMC: 03jepler 07TRUNK * 10emc2/tests/interp/inside-corners/expected: update expected results for g64 change
* jepler packs up
jepler: safe trip
Roguish: did you check out Frank's home-on-index configs?
yay, I'm home
wow - that was quick
the trip was fine