coordinate accuracy in position and time

[maxsteak]

Hello Forum guys,

I'm wondering how to collect (log of t; x; y; z) the real time coordinates of my axis during a program.

Side question: what's the accuracy of this log of coordinates with timestamp compared to the real position? Any risk of delay and mis-position?

Final question: at which frequency I can log these coordinates?


Thank you in advance for your answers.

[maxsteak]

Any reply, even mentioning my questions are not relevant?

[Hood]

Dont think anyone knows what you are asking, maybe try and explain again?
Hood

[maxsteak]

Sure, here's a more detail explanation.

I'm using my CNC with a 3D acceleration captor to test (accuracy, reproductibility, ...). So the CNC is the consign and the captor measurements the results. Then I can compare the results to the consign. The CNC is much more accurate in position than the 3D captor, so from pure static position viewpoint, it sounds safe. However, when we try to analyze the dynamic behavior of this system, it's less obvious.

That's why I'm expecting to collect the path of the CNC head in a log file. My best wish would be to get the (time, X, Y, Z).
-> How?

(Then if possible), can I trust these logged coordinates, at which accuracy? For example, a lag from the real head position compared to the computer real time expected value? Can I quantify it?


I wish it is more clear, no?

[Hood]

If you are hoping to get that info from Mach then I think you would need to make a plugin to gather the info, it will however just be what Mach thinks it is and not where the actual axis is, so likely it would not be any use to you.
Hood

[maxsteak]

Hello Hood,
Thank you for your time checking this topic.

I'm not sure about your conclusion: if the data from Mach is accurate at a certain level (let say +/-0.1mm at a fixed timepoint), it's enough for my need. However, I have no idea how to do it by script and which accuracy I can get.

[Hood]

I can only think that a plugin would be needed to get that information, you could ask on the plugin forum to see if you get help there but to be honest I think you would have to pay someone to do it for you if you are not able to do it yourself.

If it is possible to do it then what you will get is the information Mach sends out but that may not actually be what your machine is doing, example if its a servo system and is not well tuned there will be differences, if you have backlash there will be difference, if your screws are not very precise there will be differences etc etc.
Hood

[maxsteak]

Thank you for the comments. I will look at plugin stuffs

[ftomazz]

Another possible approach for what you want (from I understood) is under your drives if the drives are able to do it.
Mt point of view:
Considering that you are using step direction control method (if you are using Mach then probably are):
If your drives are able to define its error limit, start with a big value and move your machine around, then you will know if you are between a error limit during travel or not. As you will want until what you can get, lower further your limits until your machine triggers the error on the drive. You must then do your calculations to find what is the size in travel of your error (how many mm correspond to the number of steps that you have).
This however does will not reflect time, but it is a starter.

[langosta39]

In my experience, when using the Mach Parallel Port driver, you can not capture position information any faster than about 12Hz (don't recall the exact number).  Mach is operating much faster than that, but AFAIK for motion it queues up move/trajectory commands in the PP driver and then checks it that ~12Hz rate, at which time the DROs are updated.  The only way to get Mach's position is to read the DROs, so that's the limiting factor.  When writing plugins you can give trajectory commands to the engine faster, but you can't read the trajectory data out of the engine.  

In my project where I needed to sync graphics to the position I worked on this for a very long time and finally gave up on getting faster data.  What I did is oversample Mach's DROs (say 50Hz) then I could reasonably calculate the exact update interval that Mach was using, then I used interpolation to calculate where the machine PROBABLY was in between DRO updates.  This gave me a decently smooth graphical system @ 24Hz. It has the occasional jump when the interpolation is wrong, but generally is good.  Interpolation is making up data, so it won't be perfect.  It is fairly CPU intensive to poll Mach at a high rate through the Mach4 Scripter interface, so that is a consideration, too.

If anyone has a solution I'd love to hear it, too!