Back
[00:54:56] <PCW> After seeing micges HM2 stepgen problems I took another look at the firmware, and there is yet another bug in the HM2 stepgen firmware :-(
[00:54:58] <PCW> 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
[00:55:00] <PCW> is less than the DIR hold time period.
[00:55:02] <PCW> (I hadn't noticed the problem as I always tested DIR changes with a step rate higher than the DIR hold time)
[00:55:03] <PCW> I apologize for missing this error, have fixed it and will be making new bitfiles in the next day or so
[02:47:17] <CIA-48> EMC: 03jmkasunich 07TRUNK * 10emc2/src/emc/motion/teleop-notes: some further thoughts on joint constraints
[02:48:12] <jepler> PCW: thanks for the update
[02:48:58] <jepler> PCW: Depending on other things, I think the earliest I'll make a new release is June 13/14
[03:08:36] <PCW> OK, I can send bitfile to people that are having trouble if I know which config they need.
[03:08:37] <PCW> This doesn't explain the dir flapping around problem micges had but does explain the lost counts...
[03:14:58] <seb_kuzminsky> PCW: i think i fixed the "dir flapping around problem" at Fest
[03:15:25] <seb_kuzminsky> it was a pair of errors in my understanding of the interface that hm2 stepgen was supposed to implement
[03:15:46] <seb_kuzminsky> the big one was that stepgen.position-fb need to have sub-count resolution
[03:16:29] <seb_kuzminsky> all that's been fixed and i'm eagerly awaiting micges' report :-)
[03:17:25] <PCW> Great! maybe that addresses all of micges issues
[03:17:26] <PCW> (If i knew what config he is using I could build that first
[03:17:49] <seb_kuzminsky> PCW: he's using 5i20/SVST8_4.BIT, but probably should be using 5i20/SVST8_4IM2.BIT
[03:19:11] <seb_kuzminsky> in what situation would one use encoder index without encoder index mask?
[03:19:53] <seb_kuzminsky> PCW: oops, that's roguish using SVST8_4.BIT, i dont know what micges is using
[03:20:22] <PCW> Its useable but the limit switch needs to be polled to determine when to set index_enable (or whatever its called)
[03:21:20] <seb_kuzminsky> i see - the limit switch would be netted to the index-enable pin on the encoder
[03:21:27] <seb_kuzminsky> index mask up on the PC instead of in the firmware
[03:22:21] <PCW> yep, home switch input used to arm index enable
[03:22:23] <PCW> I guess I need to bump the stepgen rev to 2
[03:24:03] <seb_kuzminsky> again so the driver can warn of old bit files?
[03:24:13] <PCW> Yep
[03:24:52] <seb_kuzminsky> i guess the driver should limit step rate of v0 and v1 stepgens to the dirhold time?
[03:25:16] <seb_kuzminsky> shouldnt be a problem most of the time
[03:26:45] <PCW> I think its would be painful to limit the _minimum_ step rate, it really need fixing :-(
[03:27:17] <PCW> (needs)
[03:30:18] <seb_kuzminsky> ok, i'll stand by for a mongo BIT-file email ;-)
[03:30:34] <seb_kuzminsky> and then we'll ply Jeff with cookies until he releases 2.3.2 ;-)
[03:31:33] <seb_kuzminsky> Cool, Frank Tkalcevic reports on emc-users that he's using SVST8_4.BIT to do encoder home-on-index without index mask
[03:31:39] <seb_kuzminsky> so at least someone has it working
[03:31:54] <cradek> I thought that was the normal setup?
[03:32:31] <seb_kuzminsky> cradek: heh, i bet you're right
[03:32:59] <seb_kuzminsky> 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 ;-)
[03:33:02] <cradek> I think my machine is the only "special child" that needs index mask
[03:33:08] <seb_kuzminsky> lol
[03:33:15] <PCW> 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)
[03:33:16] <PCW> So it should probably go in the manual:
[03:33:18] <PCW> The servo thread period - jitter cannot be less than the sum of dirsetup and dirhold times
[03:33:20] <PCW> for modern step drives this this would be hard to violate, for old parker drives with 300 usec times
[03:33:22] <PCW> it may be an issue
[03:34:14] <PCW> (with servo rate > ~1.6KHz)
[03:36:03] <PCW> BBL
[03:36:08] <seb_kuzminsky> PCW, wait a sec
[03:36:35] <PCW> dog needs to be fed, nibbling on my ankles...
[03:36:41] <seb_kuzminsky> do you mean the jitter of the servo period cannot be less than (dirsetup+dirhold)? or (ServoPeriod-jitter) cannot be less?
[03:38:49] <PCW> servo-jitter
[03:38:51] <PCW> (the setpgen doesn't expect its direction (rate MSB) to change when its doing a wait-for dir hold/setup cycle
[03:39:39] <PCW> so the minimum time between updates is dirsetup+dirhold
[03:40:37] <seb_kuzminsky> ok thanks
[03:41:07] <PCW> bbl
[03:41:18] <jepler> only the crazies of systems would violate that
[03:41:36] <seb_kuzminsky> yeah that would be pretty nuts
[03:42:02] <seb_kuzminsky> jmk's fear of BIT files clogging the history is coming true!
[03:45:06] <seb_kuzminsky> goodnight folks
[11:25:42] <micges> alex_joni: when I have to home machine I have few things to do before it
[11:26:51] <micges> what do you think about aproach like tool change is done: home request out pin, and home allowed in pin in motion?
[11:28:11] <micges> (just for thinking)
[11:37:31] <alex_joni> hmm.. not a bad idea (at first glance)
[11:37:55] <alex_joni> but I think we should think about it some more ;)
[11:38:20] <alex_joni> maybe have an home allowed which is by default 1, and external can set it to 0
[11:44:16] <jepler> what do you have to do before the first homing motion may begin?
[11:49:08] <micges> make sure that thc is in safe place for first
[11:51:43] <micges> make sure that z axis when not homing is in safe position
[11:52:29] <BigJohnT> in your homing sequence couldn't you just home the Z first?
[12:04:58] <jepler> 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"
[12:05:52] <jepler> (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)
[12:06:33] <jepler> bb
[12:06:33] <jepler> l
[12:07:22] <alex_joni> otoh having a prevent homing HAL pin won't be such a problem
[12:07:39] <BigJohnT> kind of a safety interlock
[12:07:46] <alex_joni> right
[12:07:57] <alex_joni> and it's up to the integrator to hook anything up to it
[12:09:03] <BigJohnT> do you want me to add it to the docs first or do you want to program it first :)
[12:09:45] <jepler> 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..
[12:12:04] <BigJohnT> or abort the homing attempt
[12:12:59] <jepler> 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.
[12:13:06] <BigJohnT> and throw up an error "Homing Failed!"
[12:14:05] <jepler> what, by being hooked to the 'halui.abort' pin?
[12:14:10] <jepler> yuck
[12:15:39] <jepler> 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..
[12:16:02] <jepler> I don't think this design fits what I am talking about at all
[12:16:27] <jepler> anyway, really, bbl
[12:16:37] <BigJohnT> me too
[12:26:53] <alex_joni> 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
[12:27:11] <alex_joni> can't do homing on axis * while external home-validation is not active
[12:27:40] <alex_joni> then you can use the axis.2.is-homed connected to the home-validation for X&Y
[12:27:45] <alex_joni> or something like that
[12:28:18] <alex_joni> I don't think we need 2 pins.. the home-validation pin should be enough (as an input to the motion controller)
[12:53:01] <micges> the point is there is no axis.2, there are XY and Z is linked only in hal
[12:53:51] <BigJohnT> the THC has complete control of Z?
[12:53:55] <micges> after while I think only home validation for homing-all will be usable
[12:53:58] <micges> yes
[12:54:19] <BigJohnT> bbl
[13:19:42] <micges> above idea was just for thinking
[13:21:29] <skunkworks350> logger_dev: bookmark
[13:21:29] <skunkworks350> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-05-27.txt
[13:22:06] <jepler> hi skunkworks350
[13:26:42] <skunkworks350> jepler: morning. Still at the fest?
[13:27:07] <alex_joni> bbl
[13:27:49] <skunkworks350> skunkworks350 is now known as skunkworks_
[13:56:11] <micges> bbl
[14:40:32] <jepler> skunkworks_: yep, leaving later this morning
[14:41:04] <jepler> john k will leave in about 10 minutes to drive to kc for his flight
[14:41:18] <jepler> not sure when swp or lerman will head out
[14:43:12] <skunkworks_> there isn't enough time :)
[14:43:17] <skunkworks_> very fun.
[14:49:05] <Lerman__> lerman will head out Thursday morning for a 7AM flight.
[15:07:26] <skunkworks_> jepler: did you get a chance to look over stuarts kins?
[15:11:49] <jepler> skunkworks_: not exactly
[15:12:19] <jepler> 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
[15:13:01] <jepler> 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
[15:14:14] <jepler> 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.
[15:16:12] <jepler> or is every use of the tolerance value garded by a test of CANON_CONTINUOUS
[15:16:33] <micges> wfm
[15:18:36] <micges> linkable function: if(canonMotionMode != CANON_CONTINUOUS || canonMotionTolerance == 0)
[15:18:37] <micges> return false;
[15:19:00] <jepler> so you had thought about this
[15:20:38] <micges> ?
[15:21:32] <CIA-48> EMC: 03jepler 07TRUNK * 10emc2/src/emc/nml_intf/canon.hh: accept G61 P- Q- to specify separate motion and naive cam tolerances
[15:21:33] <CIA-48> 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
[15:21:34] <CIA-48> EMC: 03jepler 07TRUNK * 10emc2/src/emc/task/emccanon.cc: accept G61 P- Q- to specify separate motion and naive cam tolerances
[15:21:34] <CIA-48> EMC: 03jepler 07TRUNK * 10emc2/src/emc/sai/saicanon.cc: accept G61 P- Q- to specify separate motion and naive cam tolerances
[15:21:37] <CIA-48> EMC: 03jepler 07TRUNK * 10emc2/tests/ccomp/lathe-comp/expected: accept G61 P- Q- to specify separate motion and naive cam tolerances
[15:21:40] <CIA-48> 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
[15:21:43] <CIA-48> EMC: 03jepler 07TRUNK * 10emc2/tests/interp/inside-corners/expected: accept G61 P- Q- to specify separate motion and naive cam tolerances
[15:22:06] <micges> ah ok
[15:23:19] <micges> jepler: I think that should be accept G64 P- Q-
[15:25:47] <jepler> er, whtaever
[15:25:51] <jepler> so the commit message is wrong
[15:25:53] <jepler> :-/
[15:26:59] <micges> commit once again to emccanon to point that last commit massage was wrong, to remember
[15:27:55] <cradek> you can edit it...
[15:29:12] <jepler> cradek: john and kim are looking for you to say goodbye
[15:29:24] <micges> oh :P
[15:29:25] <cradek> brt
[15:29:41] <jepler> I can't be bothered to 'cvs admin' enough files to fix that commit message
[15:30:04] <jepler> odds are I'd destroy another commit message by mistake anyway
[15:31:53] <jepler> anyway that's not the documentation, the documentation is the documentation
[15:31:57] <jepler> so any confusion is bjt's fault
[15:31:57] <jepler> !
[15:32:14] <alex_joni> heh
[15:32:27] <alex_joni> did BJT make it to fest?
[15:33:36] <jepler> no, he didn't
[15:33:43] <alex_joni> too bad
[15:33:49] <jepler> hmph, why are the runtests failing? they worked here!
[15:35:06] <CIA-48> EMC: 03jepler 07TRUNK * 10emc2/tests/ccomp/lathe-comp/expected: update expected results for g64 change
[15:35:07] <CIA-48> EMC: 03jepler 07TRUNK * 10emc2/tests/interp/inside-corners/expected: update expected results for g64 change
[15:41:23] <jepler> * jepler packs up
[15:48:08] <alex_joni> jepler: safe trip
[15:49:48] <seb_kuzminsky> Roguish: did you check out Frank's home-on-index configs?
[21:16:15] <jepler> yay, I'm home
[21:16:42] <seb_kuzminsky> good trip?
[21:17:05] <skunkworks_> wow - that was quick
[21:18:52] <jepler> the trip was fine