Alex Joni wrote: > > Actually it's a really complex issue. > There are a couple of things which intervene at run-from-line, and I'm > not sure how one would solve them. > > There are a couple of modal things: > > - tool change in the program before the run-from-line > (say you have a machine with an automatic tool-changer). > what would run-from-line do? > I think it would do nothing, the user would have to MDI the right tool > before resuming a program. Well, if it knows what tool is in the spindle now, and scans to just before the run-from point to see what tool should be loaded at that point, then it should change tools if they differe, and do nothing if they match. But, that is a secondary issue, as many EMC2 machines do not have tool changers. > > - tool compensation > (given the right tool is loaded, the proper compensation should be > active) > I was under the impression that the run-from DID establish the correct length and comp settings, but I have not checked this in a long time. > - coolant > (should coolant get executed during the run-from-line skipping?) > the alternative is for the user to turn on coolant before run-from-line > The correct state of coolant should be made active just at the moment it begins to execute the active block. In this case, however, it would probably be fine to make the coolant follow the state at the active block as soon as the interpreter determines what it is. In other words, turning on the coolant early will not be a problem. > - lube: ditto > > - other modal codes (not sure what I forgot) > > - custom M-codes > These can cause real havoc: say I have custom M-codes for clamping and > unclamping workpieces, or some other non-coordinated motion. > Executing them could mean something breaks in the machine. Yes, this gets a bit more complicated. I think the best is to determine what these modeal settings are at the beginning of the active block and set them just before beginning the move if they are different. > On the other hand other people might expect them to be executed if for > example M03 is executed during run-from-line. > > - spindle control > (should it be started when there's a M03 in the program? how about > S-words?) > I would think it's better if the operator restores all the status needed > before run-from-line That's the POINT of this discussion, the operator is NOT ALLOWED to restore the status! If you start the spindle manually, select a block and use the "run from" menu item, it TURNS THE SPINDLE OFF! Try it. (including starting spindle, and setting the right > speed). > Atm, this is not possible, as emc2 stops the spindle when switching > modes from manual to mdi to auto. > > > I would say the change we want is to allow spindle to stay on, while > switching modes, and let the operator set up the machine as needed > before run-from-line. That would at least be a first work around to the problem. I think a better fix should be made, but we need to think through the implications. Always leaving the spindle in the current state when switching modes is probably not the best behavior, either. But, as it is now, unless you have a manual override that is completely outside EMC2, the run from line featire is totally useless. The only way to have the spindle under computer control is to edit out the intervening lines and reload the file. That is really cumbersome.
Jon ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
