@tomleslie I think the problem is in ellip where he tries to solve [a,b,c,d,e] (5 unknowns) passing [eq1,eq2,eq3,eq4,eq5,eq6] (6 equations) thus obtaining an overdetermined system.

Changing the line from

sol := op(solve([eq1, eq2, eq3, eq4, eq5, eq6], [a, b, c, d, e]));

to

sol := op(solve([eq1, eq2, eq3, eq4, eq5], [a, b, c, d, e]));

seems to make Explore work as expected.

Thanks @tomleslie; On my system (64-bit Win7)  it hangs on "Evaluating" indefinitely using as much memory as it can. I ultimately stop the execution before it starts swapping memory to disk.

@Preben Alsholm Thank you Preben, I've recently switched to Maple 2018 and never noticed that it has been added such useful feature!

Do you know how does (or if) it affect procedures evaluation performace? (I will test later)

@acer I know, but if I correctly understand what he wrote, he is asking a sort of "debugging" environment for when he is implementing the module; then having a complete set of functioning procedures etc., he can for sure create a library with march('create') or LibraryTools

@one man Yes, I'm pretty confident I've understood everything you wrote. Forgive me, maybe I wasn't enough clear in my previous comment. I wasn't criticizing the method or approach you used to solve the inverse problem and its outcomes, which from an academic and mathematical stand point is quite interesting and I really appreciate the fact that you shared your work, instead I was commenting on (and only) the specific sentence: The use of manipulators as multi-axis CNC machines. 

In my examples (which have nothing to do with the theoretical angles determination), since you were making some hypotheses on how good and flexible it would be using a manipulator as a machine tool, I just wanted to emphasize the fact that in a real life implementation, the uncertainities linked to the positioning of the end effector of a manipulator could lead to very disastrous results if not taken into account. In machining accuracy and precision are fundamental concepts; from my examples you can clearly see that these two are pose dependent (this was the main message of my comment). On top of that I assume you are familiar with force and velocity manipulability ellipses and what that could mean in a machining operation. Moreover manipulators are usually slender objects and other kind of problems can raise.

Hope I've made my statements more clear. I just wanted to warn you that, if you ever want to apply these concepts to a real manipulator, to make sure to model also the errors.

Maple is an incredibly powerful tool for direct and inverse kinematics of simple and very complex mechanisms as well for their equations of motion derivation. I'm using it for these purposes for many years and it never let me down.

Regarding the use of a manipulators as machine tool, from a practical point of view, you may encounter some drawbacks related to uncertainty. Generally, any sensor or any manipulator part is affected by some amount of uncertainity (in its reading/real length/sensor mounting and positioning etc.)  and as consequence the final position of the end effector cannot be determined exactly. On top of that, the error in positioning may change a lot accordingly to the "way" you reach a certain point in space.

As example (maple worksheet attached), let us assume that the angular readings of a simple planar robot ( and ) and its arms lenghts ( and ) are affected by some amount error (that can be modeled with a normal distribution). The position of the end effector, using recursive kinematics, is given by:

error ->  (the same for ,  and )

As you can see (a bit exaggerate to be visible), the uncertainity in positioning changes a lot in shape as function of the arms angle.

Here you reach the same point in space but using different arms angles. As you can see the end effector position uncertainity cloud shape and orientation changes.

Maple worksheet -> manipulator.mw

@Carl Love yes sorry, you are right, implicit=true slipped in by mistake when I was writing the PS in my question. However I've tried to remove all the options and still Maple 2018 does not want to work with that specific worksheet. 

The stragest thing is that in some other old worksheets, in which dsolve is called, work perfectly. Therefore I'm not able to reproduce the error. It seems to be related to the particular worksheet but, unfortunately, I cannot share with you it because it contains confidential informations and make use of a set of custom built libraries (these were made in Maple 18 as well).

I will try my best to reproduce or solve the problem and if I have some news I will post in here.

Thanks

@Pascal4QM That's exactly what I was looking for! I was reading the overload documentation moments ago when the proverbial light bulb went off. I came here to suggest this way but... you just posted the answer!

Thank you very much, you saved me some time.

@Christopher2222 well... yes this is a basic solution, but it's not what I'm looking for; as stated in the original question I would like to use an infix operator , something like list operator list (like when you use the addition operator)