Reading non-trivial joint values

I have non-trivial x-y axes, on a 3 axes machine.
j0 and j1 machine joints are displayed in Manual Control mode (M3).
When a log file is created after (LOGOPEN,filename.txt), is it possible to capture and write those j0 and j1 values. I’m probing the outside edge of a circular disc on the work table to calibrate the machine dimensions.

Subtractive

I'm working with Andy (Subtractive) on this problem.

We are probing an object whose dimensions are known (it's a disk made on a lathe), and we want to use the actual joint positions (as reported by the encoder when the probe makes contact) to help to calibrate the fixed constants that go in to our kinematicsInverse()/kinematicsForward() functions to drive our non-trivial kinematics machine.

Having looked in the source code where these functions are called in relation to a probing cycle, it seems that encoder (joint position) is read when the probe is tripped, and the kinematics function is called to convert these values to cartesian coordinates which are saved into the following object:

EmcPose emcmot_status_t::probedPos

See:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...4985043e8415368#l610

Unfortunately, since struct EmcPose contains only cartesian XYZ coordinates (as well as the 5-axis rotations ABC, which do not apply to our machine), these joint positions are not recorded and so cannot possibly be logged by the probing cycles without reprogramming the EmcPose class.

Does this sound right?

(Yep. Caver based in Liverpool, though I'm trying to do more hang-gliding this year, so far without much success.)

These external hardware hacks (as I read them) would be unnecessary if the EmcPose class simply had the joint values copied into it.

The class definition has three extra values (u,v,w) that don't seem to be of any use:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...24cdb4985043e8415368

Would it be an unreasonable hack to reuse these to transmit the joint positions back to the place where probing is done?


I'm not very familiar with actual machines (I've only done CAM software from a theoretical perspective), but it appears to me as a limitation of this probing feature if you don't get the joint values. If I am using probing of points to debug/improve the parameters of the kinematicsInverse() function, then it makes sense to have access to the raw input and output values of this function.

The idea is to automatically calibrate/check the machine on the day by probing a known object. Put this test piece on the table in the morning, let the machine poke/probe it about a bit, then it automatically sends a file of raw joint measurements through a python script (using scipy.optimize.minimize() on all the different over-constrained measurements), which spits out a new version of kinematicsInverse() on the day, compiles it and links it back in.

I've not been in a precision shop, but don't they go through some kind of process like this with their machines every day to keep them up to spec?

Just as a follow up for completeness sake, the runes which we worked out were added to some kind of hal file were:

Then we needed to run halsampler outputsamplefile.txt

"depth" sets the buffer in terms of record length, but there's a second limit to the buffer size in bytes, so we were not able to uncomment the "net j3" line until we reduced the value of depth.

I can't right now remember the further "net" command we used for the contact pin, but when we put it in it was possible to see how far it over-shot. It seems to pull back further than the first point of contact before contact is broken, which is a mystery, because we don't know if this is due to backlash, or the motor position following behind its commands. It would be better if we could get the direct encoding of the rotors rather than the commands, but this info doesn't make it back into linuxcnc from the motor drivers, so this will have to do for now.

Thanks all for the help. I am beginning to get the underlying picture of the system, which seems pretty good so far -- however I wish that the realtime component could be broken out into a separate microcontroller that straightened out the pulses so they didn't need to be exact.