Tool Change Issue

[cwatson1982]

Randomly over the last couple of months my tool change procedure appears to have not been called.

T23 M6 just now continued without running my toolchange1.c program; no lift to Z machine 0, no spindle off, no message box for tool change request; it just continued on as if M6 was never called. It is not repeatable and just seems to happen at random.

I am using 4.35F, M6 is set to exec/wait/sync using thread 5 and variable 9 (nothing else is using either)

toolchange1.c is:

Code: Select all

#include "KMotionDef.h"
#define TMP 10
#include "KflopToKMotionCNCFunctions.c"

main()
{
	int slot = persist.UserData[9];  // value stored is an int 
	int id = persist.UserData[9+1];  // value stored is an int 

   char str[100];    //create an empty string to store number
   char toolNum[20];
   int Answer;
   
   
   sprintf(str,"Insert Tool Number: %i", id);   //make the number into string using sprintf function

   
   

	Answer = MsgBox(str,MB_OK|MB_ICONEXCLAMATION);
	if (Answer == IDYES)
			printf("Answer is Yes\n");
	else
			printf("Answer is No\n");
	
	printf("Tool Set to slot %d id %d\n",slot,id);  // print the slot and id
}

Any ideas? The other times this happened I thought maybe it was noise associated with a long USB cable for my touch screen but the message box never popped up and the machine never went to the tool change position this time (I was standing there for once)

[cwatson1982]

It did it again, I was wrong. It does seem that the machine is traveling to Z zero, spindle kicks off for a second then back on and continues machining. I did not see the dialog box pop up so seems maybe an issue with the toolchange1.c? The sprintf information in the C program is showing up in the console

[TomKerekes]

I assume the Z move to 0, spindle off, and such is in the GCode? I don't see this in the C Program.

Do you have any other programs running? And that are sending commands to KMotionCNC?

The communication to KMotionCNC is not Thread safe. That is if two Threads send a command at the same time then commands can be dropped or results mixed up.

[cwatson1982]

Yes, Z machine 0, spindle off, etc is in the G code.

The only other program that should be running is the main loop (attached).

Looking at the console output, all of the sprintf functions in the C code I posted are outputting correctly.

Is there a better way I could force a pause/halt within the toolchange code? I can do DoPC(PC_COMM_HALT) in the c program but unfortunately that has the effect of stopping execution on the M6 line, cycle start then just re-runs the tool change.

I just need to call m6, prompt for the correct tool and continue machining after manually changing. The way it works now (when it works) is machining is resumed after I hit the OK button from the dialog. I suppose I could edit the post and M0 after the tool change but would rather not if I don't have to

[cwatson1982]

I discovered PC_COMM_HALT_NEXT_LINE. Will see if that does the trick.

[TomKerekes]

The only other program that should be running is the main loop (attached).

Yes I see the forever loop sends FRO and SSO commands to KMotionCNC. Also potentially very frequently as these settings:

Code: Select all

#define CHANGE_TOL 0.02  // only update if change is more than this
#define CHANGE_TIME 0.05  // don't update more often then this time

Are quite small so commands can be sent with small changes due to noise and up to 20 per second.

You might consider increasing those. But regardless there would still be a potential lost command.

One solution could be to have your Tool Change Program tell Thread #1 to display the message for it. You might use a persist Variable to communicate between the Threads.

Is there a better way I could force a pause/halt within the toolchange code? I can do DoPC(PC_COMM_HALT) in the c program but unfortunately that has the effect of stopping execution on the M6 line, cycle start then just re-runs the tool change.

PC_COMM_HALT_NEXT_LINE can be used for this to halt on the line after the M6 so cycle start will then resume after it.

[cwatson1982]

The only other program that should be running is the main loop (attached).

Yes I see the forever loop sends FRO and SSO commands to KMotionCNC. Also potentially very frequently as these settings:

Code: Select all

#define CHANGE_TOL 0.02  // only update if change is more than this
#define CHANGE_TIME 0.05  // don't update more often then this time

Are quite small so commands can be sent with small changes due to noise and up to 20 per second.

You might consider increasing those. But regardless there would still be a potential lost command.

One solution could be to have your Tool Change Program tell Thread #1 to display the message for it. You might use a persist Variable to communicate between the Threads.

Is there a better way I could force a pause/halt within the toolchange code? I can do DoPC(PC_COMM_HALT) in the c program but unfortunately that has the effect of stopping execution on the M6 line, cycle start then just re-runs the tool change.

PC_COMM_HALT_NEXT_LINE can be used for this to halt on the line after the M6 so cycle start will then resume after it.

TY Tom. Those defines might also explain some other random issues I was having, I will change them tomorrow and see what I can figure out with the tool change code