Am 10.12.2013 um 00:54 schrieb Frank Tkalcevic <[email protected]>:
> Is it possible to issue MDI or equivalent commands in joint mode? For > example, on my robot arm, I want to move joint 2 to 45 degrees. > > > > I'm guessing no, because you have to be in MDI mode to issue MDI commands > and you can only be in MDI mode when in world mode. > > > > If this is the case, are there low level commands (nml?) that can be used to > move to an exact position? I dont think that is currently possible. I thought about that too already - it's quite an irregularity since with jogging both modes are already partially possible. It struck me as one of those limitations which I found no good explanation for. The same problem already appears with the NML jog commands - the old ones implicitly assume joint mode, and that doesnt hold any more. I think there are several issues: - the interpreter has no notion of joint versus cartesian coordinate context. Making that switchable in the interpreter has far reaching consequences in the context of a running program, but I see no fundamental reason why this could not be done at least for MDI, or during interpreter idle. One question is if the same set of coordinates (X...W) would be used which would be confusing, but I guess RS274 is out of words. Maybe some syntactic trick could help to disambiguate. - a switch of the interpreter joint/cartesian context would need an immediate sync() if the same set of coord words is used; this would cause a jump for non-trivkins, which I think is undesirable, also suggesting not to overlay joint/coord mode coordinates onto X-W. - the downstream path from interp towards motion deals with joint/coord mode switches in a quite heavy-handed way - flushing the motion queue, aborting motion etc etc. I never understood why - for me the coordinate interpretation context is an attribute of a move, and there is no good reason why there cant be a sequence of moves with different contexts. The interpreter might need kins too for position prediction. - canon will need to support null values to indicate the set of affected joints/axes besides the kins context. This would be a valuable exercise to think through towards a more future-proof solution; getting rid of NML will be an opportunity to get it right. This will impact posemath functions too. IMO there is no need for separate jog commands if the move representation is sufficiently general. Unfortunately the current pose representation is rather inflexible and irregular, and jog is handled separate from moves. This wont have a quick fix, but I think dual-mode piecemeal migration is possible in principle. I also dont see a strong reason for separate planners for coord and joint mode - joint mode moves are sufficiently close to trivkins applied to a move, so switchable multiple kins in motion (really two - trivkins for joint mode, and the machine's kins for coord mode) should do the trick. - Michael > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
