Mark Pictor wrote: >> However, the basic principle of a jogwheel is that movement of >> the table is DIRECTLY proportional to movement of the wheel. >> Therefore there must always be some increment of motion per >> count of the jogwheel. > > I should have said velocity mode. Spin the wheel, it moves in one > direction until the wheel stops. If the wheel is moving faster, > the machine moves faster. That's close to what Stuart wants, right?
The key statement here "if the wheel is moving faster, the machine moves faster". That means you have not reached top speed! In that case, EMC already does the right thing: Move wheel, machine moves. Move wheel faster, machine moves faster. Stop wheel, machine stops. You don't get into trouble until you are moving the wheel faster than the machine can move. Then it becomes "move the wheel faster, machine does NOT move faster". That is the point where any operator with half-a-clue will slow down - he can see and/or hear that spinning the wheel faster it isn't making the machine go any faster. So why waste the effort spinning the thing like a madman? This entire discussion is about what to do when the operator insists on spinning that wheel faster than the machine can move. That is the only way that the wheel can get ahead of the machine, and the only time there is any disagreement about what is the right thing to do. If the operator manages to get ahead of the machine, we have two choices: 1) Go where the operator told us to go, even if that takes some extra time. If he dials in 14-1/2 turns of the wheel, then we move the table 14-1/2 turns of the wheel - no more, no less. Even if he cranked in those 14-1/2 turns in a blazing 1.3 seconds, and it actually takes us 15 seconds to make the move. We give him exactly what he asked for. That is the current implementation, and it seems perfectly reasonable. 2) Stop when the wheel stops. If the operator was cranking like a madman and has managed to crank 20 turns into the wheel, but stops cranking after the table has moved only 11-1/3 turns, stop the table anyway, and throw away the 8-2/3 remaining turns. At that point, wheel-to-table synchronization is out the window. The wheel is 20 turns from where it started, but the table is only 11-1/3 turns from where it started. If the operator can get significantly ahead of the machine without cranking madly, then the jog wheel scaling is configured wrong. The wonderful thing about a jogwheel is its wide dynamic range compared to most other controls. WIth a 100 click per revolution wheel, an operator can go from one click per second or less to several hundred clicks per second, or anywhere in between, very easily and naturally. Assume that an operator can turn a typical jogwheel with a spinner handle at 4-5 revs per second, or 240-300 revs/minute, and that the jogwheel has 100 clicks per revolution. Assume that you are setting up a machine with 400 ipm rapids. If you configure the maximum jog wheel increment as 0.1", that is 10 inches per turn of the wheel. Any wheel speed over 40 RPM is faster than the machine can follow. Instead of the operator being able to use his natural ability to turn the wheel at any speed from 0 to 300 or so RPM, he's stuck with a top speed of 40 RPM. (If he turns it faster, you are just gonna throw away the extra turns anyway.) But if you configure the machine with a maximum jog wheel increment of 0.010", that means one turn of the wheel is one inch, and 300 rpm is 300 ipm. The operator will really have to work at it to get ahead of the machine, and that means the wheel will do what it is supposed to do: turn slow, machine goes slow, turn fast, machine goes fast, stop turning, machine stops. In either case, for final touch off, the operator will have to switch to a lower scale, 0.001" or 0.0001" per click, but that is fine - a lower scale makes it even harder to get the wheel "ahead of" the machine. Summary: Any time the operator gets ahead of the machine, the natural and intuitive behavior of the jog-wheel breaks (you spin faster, but the machine doesn't go faster). if your operators are frequently and easily getting ahead of the machine, it means your scaling is wrong, and as a result, the wheel is spending a lot of time "broken". If the wheel is scaled right, the operator will rarely or never get ahead of the machine, the wheel will work the way it should, and this whole thing is pretty much a non-issue. Regards, John Kasunich ------------------------------------------------------------------------- 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
