On Fri, Aug 16, 2013 at 03:52:26PM +0100, andy pugh wrote: > On 16 August 2013 15:35, Chris Radek <ch...@timeguy.com> wrote: > > This means: just like you have > > to set AXIS LIMITS to be inside JOINT LIMITS, you must also set up > > your configuration so obeying AXIS CONSTRAINTS keeps you within your > > JOINT CONSTRAINTS. This can be tricky, but you must do it. I think > > your question is about this paragraph. > > Yes, I think it is. > Unfortunately in some situations this could be painful. You would have > to choose your rotary axis constraint such that for the very longest > tool at the worst possible angle the linear axes can keep up. Then > when the tool is very short and the angle very small you will end up > with much slower than necessary motion. And this super-conservative > limit will also apply in G-code which does actually know better.
Yes I understand fully why it's not great. Tool length really makes it worse in this particular case. But nevertheless that is the state of it currently, and I wanted to spell it out. In other cases like lineardelta , tool length doesn't bother anything and setting up the CONSTRAINTS is really pretty easy. You can just look at the picture of the machine and feel some things about it: a long tool doesn't make it worse or better, and things are probably going to be worst near a strut or maybe between two of them? With only a bit of study you can set it up properly: http://emergent.unpythonic.net/01373628488 > Would it be possible for the code to determine the instantaneous > relationship between current AXIS (trajectory?) velocity and the > associated JOINT velocities? Possible, sure... > I think in theory this is just two calls to the kins module of a > "now" and a "now + delta-t" point. The system could then > "throttle back" the trajectory velocity accordingly. It's not clear to me that this is enough. Any "throttling back" uses up some (or even all) of your acceleration constraint. You have to still finish your move at the correct end position without violating either velocity or acceleration constraint. I think this requires that you plan the ENTIRE move before you start. Once you're moving without yet having calculated what is required to stop in the right place, I think it's easy to be doomed. But in general I think you are right that you can use discrete derivative to find the approximate relationship between the axis and (worst?) joint constraints. Seb and I talked handwavedly about studying the move beforehand, by binary-searching along it, looking for the worst world/joint constraint ratio (perhaps binary search as much as possible until you run out of time for planning - some kins are much slower than others), and then scaling the world constraint accordingly. It would still be planned in world space, but scaled back, with one scale applying to the whole move. Similar analyses are done in emccanon.cc right now (even in trivkins a linear move has different world constraints depending on which way it points), and this could also be done in nonrealtime at that layer. You just have to make the kins available there too. I think conceptually this is all quite possible[1] even without any further trouble for kins writers (don't make them write derivative kins for instance). > I think that the relationships will always be continuous (as long > as the kins is continuous, and those kins with singularities are > already a problem). If the relationships are continuous then there > may not be any worries about simultaneously respecting accel > limits. I don't follow what you're saying here. Chris [1] http://catb.org/jargon/html/S/SMOP.html ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
