On Mon, Mar 19, 2007 at 10:54:04AM -0400, John Kasunich wrote: > Stuart Stevenson wrote: > > Gentlemen, > > In my limited experience with the handwheel control on this machine I see > > what I consider over run. I know it is the accumulated pulses the machine > > has not completed. When the handwheel is turned faster than the machine is > > able to respond the actual position lags behind the commanded position. > > At the moment there is a good discussion of this topic going on in the > emc developers IRC channel (#emc-devel at irc.freenode.net). You can > see the archives here (the discussion starts at about 13:40): > > http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-03-19.txt > > There are lots of good points to be made both for and against what > Stuart wants. > > Basically, the jogwheel tried to behave like a manual machine's > handwheel. That includes having a dial with numbers on it, that > accurately represents where the machine is. Unfortunately, unlike a > manual handle, you CAN spin a jogwheel faster than the machine can > follow. So the question is, now what? > > The existing code believes that it is important to keep the dial on the > jogwheel reading correctly - so if you spin it faster than the machine > can keep up, it "winds up a spring" between the machine and the wheel, > and when you stop spinning the wheel, the spring unwinds until the > machine matches the wheel position. Lots of people (me included) > strongly believe that is the right behavior. > > Other people don't like that "unwinding", and would rather have the > wheel "slip" when you spin it too fast. If we make the wheel slip, you > don't have to worry about overrun, but you also can't trust the dial > on the wheel anymore. > > Take a look at the discussion logs, and/or join the discussion. When > we reach a concensus, we'll go from there. > > Regards, > > John Kasunich >...
I'm at a trade show now, so can't fully participate in the discussion, but I have some comments. 1 -- There has been some discussion of keyboard vs. handwheel jogs. IMHO, there should be no difference. Handwheels, keys, (whether one of each, or multiples), should feed into HAL (or CL or combination) and be handled. 2 -- The same is true for homing. A comment was made that for lathes, X must be homed before Z should be an integrator issue. An argument could be made that Z should be homed on mills before X or Y (so that the tool doesn't hit the work or fixtures). These are integrator issues. IMHO, integrators should deal in configuration files, not C code. (Well, if you need a new Kins, that might be an exception.) Homing sequences could be done nicely at the HAL/CL level. Instead of writing C code that handles various cases (a single limit switch chain, multiple limit switches, separate home and limit switches, etc) the code should have a clean implementation with all the different cases at the HAL level. Then, some baseline HAL implementations of the major cases could be distributed. Each one could be a clean implementation -- instead of having all the cases in an (almost) unreadable C module. I'm off to the show. Regards, Ken ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
