Non-blocking check of OriginOffsets and AxisOffsets

Moderators: TomKerekes, dynomotion

Post Reply
HowHardCanItBe
Posts: 21
Joined: Tue Nov 20, 2018 5:39 pm
Location: Sharonville, Ohio

Non-blocking check of OriginOffsets and AxisOffsets

Post by HowHardCanItBe » Fri Nov 06, 2020 2:13 am

Tom,
Two years ago you provided code for non-blocking service of a G43 G49 status LED, which worked great for me (thanks!);
https://www.cnczone.com/forums/dynomoti ... ost2231526

Code: Select all

#include "KMotionDef.h"

#define TMP 10                    // which spare persist to use to transfer data
#include "KflopToKMotionCNCFunctions.c"

void ServiceToolOffsetMode(void);

main(){
    for (;;){                    // forever loop
        ServiceToolOffsetMode();
    }
}

#define STATUSBIT 46

// periodically set Virtual Bit based on Tool Table Index
// keeps track of state of sequence to always return immediately
void ServiceToolOffsetMode(void){
    static BOOL WaitingForResponse = FALSE;
    static double LastTime = 0;
    int HWORD;

    if (WaitingForResponse){        // Waiting for a response from the PC?
        if (persist.UserData[PC_COMM_PERSIST] <= 0){    // Has PC Responded??
            HWORD = persist.UserData[TMP + 2];    // Get Tool H Word
            SetStateBit(STATUSBIT, HWORD != -1);    // -1 indicates no active offset 
            LastTime = Time_sec();
            WaitingForResponse = FALSE;
        }
    }
    else{
        if (Time_sec() > LastTime + 0.3){    // only request periodically
            DoPCIntNoWait(PC_COMM_GET_MISC_SETTINGS, TMP);    // Request settings from PC
            WaitingForResponse = TRUE;    // Remember we are waiting for a response
        }
    }
}
Is there a similar way to do this for the fixture offset and the global offset? I couldn't find an equivalent to
DoPCIntNoWait(PC_COMM_GET_MISC_SETTINGS, TMP);
for either of them. My goal is a non-blocking way to service the first two (left-to-right) of these three LEDs;
Offset LEDs.png
Offset LEDs.png (2.11 KiB) Viewed 881 times
I have three axes (X, Y, & Z), so calling both GetOriginOffset and GetAxisOffset, to check for reasonable non-zero values in all three axes, takes almost 1 second (or about 840,000 micro seconds - your non-blocking code only needs 2 micro seconds!).

If there is no way to use DoPCIntNoWait to get these answers, are there values on the KFLOP which could be checked (instead of calling KMotionCNC)? E.g. for the latter (AxisOffset), is there a way to get Vars[5211] (for X, and 5212 and 5213 for Y & Z) directly, and could they be tested to determine if a global offset is in effect (I think not, since after a G92.2, when the Internal Offset != Internal Var, a test would still return a yes, when the DRO was not being shifted.)?

Is there something similar for the former (Vars[?] for the OriginOffset values)?

I'm hoping to avoid adding a thread to continually service these two function calls.

Note; I've edited this post several times in an attempt to clarify my question and disclose my assumptions.

User avatar
TomKerekes
Posts: 2559
Joined: Mon Dec 04, 2017 1:49 am

Re: Non-blocking check of OriginOffsets and AxisOffsets

Post by TomKerekes » Sun Nov 08, 2020 1:32 am

Hi,

Are you saying GetOriginOffset and GetAxisOffset works for you correctly but is just slow? Because if you look at those functions in KflopToKMotionCNCFunctions.c they just read the corresponding GCode Vars.

You can use the GetGCodeVars approach to read a bunch of GCode Vars at once using the same approach. But it needs to send 2 more parameters to tell KMotionCNC which Var to start with and how many to get. So code something like:

Code: Select all

			persist.UserData[PC_COMM_PERSIST+2] = n;       // number of elements
			persist.UserData[PC_COMM_PERSIST+3] = poff;    // persist offset (doubles)
			DoPCIntNoWait(PC_COMM_GET_VARS, TMP);    // Request settings from PC

Then after the PC responds use:

Code: Select all

	V1 = GetUserDataDouble(TMP);
	V2 = GetUserDataDouble(TMP+1);
	.
	.
to get the variables.

Note KMotionCNC can't be sent two commands at the same time so if you need to do multiple things in a sequence you will need an integer state variable in stead of just true/false for 2 states of WaitingForResponse or not WaitingForResponse.

Like you said its not clear how G92.2 would work for this. I don't really understand the purpose of G92.2. I suppose the other approach would be to read the DROs, the Machine Coordinates, the Tool Offsets, and fixture offset and then figure out if there is a G92 offset. That might not work when things are moving.

Let me know if this makes sense.
Regards,

Tom Kerekes
Dynomotion, Inc.

Post Reply