I have a similar setup... Mach4... ESS... closed loop servos... that is actually not a real closed loop system, since neither the controller or Mach4 actually know the axis position.. they just assume it. I actually added a prox so i could make sure my 'z' axis was clear.. because if it wasn't I was going to rip the fixture apart, or rip the spindle off the machine... or both... not a good thing. But I don't do anything as complex as what you are stating... that's top notch stuff... but I don't believe an RTOS would resolve your problem. What actually is the issue? Kinematics or Reverse Kinematics (never heard of that) Do you mean 'Inverse Kinematics'? 

Hi,

Subscription nearly forces you to upgrade continuously and also costs you a lot more.

I was always adamantly against subscription software, but since getting Fusion I've had to reconsider that stance. Firstly I pay about $500USD/year for Fusion Basic.
The closest competitors that have the same features are $1500USD to $2500USD and with optional annual fees of $250 or so on top of that.

By my reckoning I pay (in subscription fees) the same as buying a perpetual license every four years. I consider that fair value......not cheap.....not expensive, but fair.
Were I to buy RhinoCAM (Expert) (for $2500USD plus $400 annual) for instance, then I'd almost be a fool not to get annual updates, otherwise I'd find in five or eight
years time that my software had slipped that far behind that I'd have to buy anew. Not very appealing.

So, no, I disagree with your contention that a subscription 'costs a lot more', over a medium term I think they are cost competitive with a perpetual licensed software

I, for a couple of years, also bought Fusion Machining Extensions, at a cost of about $1500USD/year. This adds full simultaneous five axis, collision avoidance and tool path editing.
BobCad, RhinoCAM (Premium) ($10,000USD plus $600USD annual)  and other are all $10,00USD for a perpetual license plus $500-$1500USD  optional annual fees.
Simply I don't have the cash to buy a perpetual license outright, and so Fusions Machining Extensions subscription gave me capability that I could not otherwise afford.
I'm 100% convinced that Autodesk know this and price their products accordingly.

I still don't much like subscriptions, but it does mean I can have capabilities that would otherwise be out of reach for me. The final thing which swings me in favour of Fusion is that it has
an Electronics module, and I use it daily for business. Additionally it can do FEA simulation, thermal simulation and generative design. I make only limited use (read hobby level) use of these later
capabilities but I do use all of them. It is these extra capabilities all in the one platform that appeals.

I do well believe bet that Autodesk know and understand all of this , and this is how they are trying to maximize their profit, and I am, in part, providing it.....but in return I get to use a very good,
perhaps to the best or first-in-class software but pretty damned good, in a manner I can afford.

Craig

Hi,

What actually is the issue? Kinematics or Reverse Kinematics (never heard of that) Do you mean 'Inverse Kinematics'?

They go by different names but they all refer to the same thing.

Imagine a three axis machine. You touch of to a corner of your part and start the Gcode. If later you repeat the task but with fresh material and you clamp in in the vice
but not in the same location as previously. No trouble, touch off to the corner and start the Gcode running. The displacement of the material does not require any special handling
by Mach or your machine as the Gcode now runs about your newly aquired work zero.

With a five axis machine however if the material is displaced then you need to calculate not only the X, Y, Z axes anew but also the fourth and fifth rotational axes as well. If you rotate the fourth axis
by 10 degrees then that will affect the X,Y,Z,C axes as well. This is called kinematics. If you displace the material you can use kinematics or more correctly 'reverse kinematics'
to re-calculate the Gcode so that the part is still made correctly. The kinematic equations are not just linear translation as in the three axis case but contain sines and cosines of the rotational
axes as well. Sines and cosines occurr in forward kinematics, while arc-sine and arc-cosine occur in revers kinematics.

One of the quirks is that the sine of 45 degrees for instance is 0.7071, but then again the sine of 135 degrees is also 0.7071 and the sine of 225 degrees and 315 degrees is -0.7071
Thus with reverse kinematics you can get two (or more in certain circumstances) solutions, only one of which is likely to be correct for your machine. To call it a 'mind-f*******k'
is an understatement. Doable.....but definitely challenging.......ergo I want someone (MachMotion) to do it for me!!!! I have not lost my hobbyist credentials entirely!

There was a Aussie guy whom did this with Mach4, and I'll try to find the link. He did spend many months writing the code, but it was a module that 'processed' Mach's regular trajectory according
to the reverse kinematic equations. He also resolved the 'inflection point dilemma', which is the name for the phenomonon above.

Craig

yes its normally referred to as Inverse Kinematics because of the way you specify the final position and the methods (calculations) required to get the individual axis' in position. Since in many cases the 'final' position can be achieved with the axis' in different states. Determining what the best state should be is a relatively difficult process. Yes, I am familiar and I would presume this would blow away most users. I'm glad I don't require. Does your CAM cover this or are you forced to do some of the calc's manually (sheesh!!!) 

and that is a common issue with defining the end point.. a point is a definitive position, but a true 5 axis machine (robot) can achieve lets say for example with the tool pointing up or down, and either to the left or right. Determining the best state also requires knowing where you are and determining not just the best way to move to the next state, but also how you expect to get to the following state. It can be a very very complex set of calculations and possibly rules that need to be applied. Again, glad I don't go there... 

but your problem isn't the lack of an RTOS... a five axis g-code program probably requires many truly minimal movements... the problem is one of computing power... given that the cpu might take a significant amount of time to compute the next movement.... so instead of a smooth transition from point to point you could have a more 'jerky' type of actual path. I would expect that most, if not all, standard pc cpu's would not be capable of meeting the requirements (that would still need to be determined)