Get BullsEye TCP deviation magnitudes after QuickCheck successful

Daper

Hello,

I am trying to get the deviation x,y,z of the TCP after the BullsEye successfully made a quickcheck (aka BECheckTcp, e.g. no critical deviation hence no update of the TCP !).
I can visually read them from the event log and from the file BE_Oper_T_ROB1.log in the controller folder HOME\BullsEye but I can't find how to manipulate these values through RAPID variables.

Does anyone know how can I assign these deviations to RAPID variables ?

Thank you for any input

matti

Hallo, there is a variable type be_device, usually declared in BE_User. It is a record where "repeatability" can be used as a value for an update/accept.

Daper

Thanks matti,
I've actually been able to set this variable according to my needs, and that works well.
I initially thought that the measurment of a variation below this threshold would not lead to a TCP update. However, it seems like the CheckTCP routine indeed updates the TCP in this case.
So, the best way to extract the differences between the old TCP and the new one must be to compare their components separately.

matti

In my installation, for values below the treshold I got a message that no changes were made to the TCP.

For values above, the controller shows old and new values and asks for confirmation.

Daper

I have the same behaviour actually. Yet a different need.

The BullsEye logs give at QuickCheck end:

12:41:48 BECheckTcp: TCP is within limits.

            Measured=[[-138.6,9.31,476.55],[0.02,0.59,0,-0.81]]

            Current =[[-138.55,9.28,476.55],[0.02,0.59,0,-0.81]]


And does not update the TCP, naturally.

But I would like to get these "Measured" values though, and I don't know how to. They are only stored in the log file as far as I know.

Do you know how I can catch them and store them in RAPID ?

Daper

The BE documentation on the QuickCheck functionning is a bit confusing. On the one hand it claims:
"[...] if the preliminary measurement shows a deviation, the robot will continue to make a complete measurement of the tool. Otherwise, the robot returns to the calling routine and no change is made to the TCP. [...]"

On the second hand is states:
"[...] If the measurement indicates that the tool TCP has moved, BullsEye will do a complete evaluation to get the new TCP. If the change is found to be less than the maximum allowed change, the TCP will be updated"

matti

Hallo, in fact, if the routine encounters some problems ("beam has moved"), it starts over with a full measurement instead of a CheckUp. Also with some arrangements where the robot is moved by an external kinematic, I never get a result from CheckUp in the first place - the robot performes full measurement.

To get the current values, I suppose you have to open and read BE_Oper_TRobx.log in HOME\BullsEye.

matti

Daper

Ok thank you very much for your input.
Well, I wish there was different way from accessing the log file directly..
Nevermind, I'll try it out.

Thanks once more