Issue with M6 execution

Hi Tom,

I am another member of the team that posted a bug question here:

Problem Bug found on SnampAmp

We are now having issues executing an M6 command while running gcode.

First let me begin by outlying our goal, we want the machine to move to Machine Coordinate 0 upon reaching M6 and to wait for a manual tool change. At this point the operator presses a button which initiates a program that checks the tool size on a plate, adjusts DROs, returns to Working Coordinate 0, and syncs.

Our M6 command runs on exec/wait/sync.
We've tried the M6 execution using variables 8, 86, and 87.

Here is our M6 program:

Code:

---

#include "CustomDef.h" //this is our def file that includes KMotionDef.h
 
enum {T_IDLE,T_START,T_WAIT_UNCLAMP,T_WAIT_MOVE,T_WAIT_CLAMP};
 
void main()
{
 while(!CheckDone(z_axis) && !CheckDone(y_axis) && !CheckDone(x_axis)); //CheckDoneXYZABC()
 
 *ChangerState = T_START;  //*ChangerState points to persist.UserData[87]
 
  printf("%d","Tool Change Initiated\n");
  gotoZero();
 
//our manually executed Tool Change Code sets *ChangerState to T_IDLE once completed
  while (*ChangerState != T_IDLE) 
  {
  WaitNextTimeSlice();
  }
}

---

Our gotoZero() function merely contains a Move(axis,0) with a while(!CheckDone(axis)) operation between each move.

The problem we are having seems to be with the 3 second Look Ahead buffering, it executes our M6 code 3 seconds too soon which causes follow errors and disables the axis.

This only happens during the first run:
Attachment 257701

If we return the machine to Working Coordinate 0 and restart the cut it will successfuly run our M6 command with no issue the second time through:
Attachment 257703

After running through the Gcode a second time we are able to complete the tool change, sync, and continue cutting.

We've tried placing the M6 code inside of an IF statement (see below) which does not allow it to execute unless a button is pushed, however kmotioncnc produces a generic gcode error during the Look Ahead Buffering when it reads the file under these conditions.

Code:

---

#include "CustomDef.h" //this is our def file that includes KMotionDef.h
 
enum {T_IDLE,T_START,T_WAIT_UNCLAMP,T_WAIT_MOVE,T_WAIT_CLAMP};
 
void main()
{
 while(!CheckDone(z_axis) && !CheckDone(y_axis) && !CheckDone(x_axis));
 
 if(CheckBit(137))
 {
  *ChangerState = T_START; 
 
  printf("%d","Tool Change Initiated\n");
  gotoZero();
 }
 while (*ChangerState != T_IDLE) 
 {
  WaitNextTimeSlice();
 }
}

---

We've tried placing a 3 second delay in the M6 code to allow the machine to catch up and this allows the M6 code to execute, the machine will go to 0, however kmotionCNC is unable to sync after the tool change.

Lastly we've tried running M6 as a blank file containing only a printf statement and we receive a generic Gcode error from kmotioncnc during the Look Ahead buffering which stops the execution of the code.

We’ve tried various gcode formats with similar results.

I'm assuming we have done something wrong and would appreciate any help to point us in the right direction.

Thanks in advance for you time,

David.

Hi David,

The Interpreter should wait until Motion is finished before calling the M6 C Program. So I'm not sure why you are having the issue. What Version are you running?

I can't access your cnczone Attachments for some reason.

I believe you are getting the "Generic GCode Errors" because you have syntax errors in your C Programs. There is no CheckBit function (unless you have created one). Maybe you wished to use ReadBit ?

I'd try the blank program with just the printf statement. You didn't include that for us to check it for syntax. You might try compiling the C programs within KMotion.exe to check for errors before you try to run GCode.

Regards

Sorry Tom for my inaccuracy, that second snippet of code wasn't actually used I was trying to give you an idea what we tried and I made an error retyping it. There were no syntax errors in the c program they were all compiled and tested individually. The first cope snippet I included runs during the Look Ahead 3 seconds before the gcode interpreter arrives at that line, then on the second run it waits until the interpreter actually arrives at M6 before running... as shown in the images below. We are using version 4.33d.

Here is the photo of the initial run:
Attachment 257717
Y Axis is disabled in this photo a result of the follow error due to the M6 script running simultaneously with the Gcode.

Here is the second run after restarting at 0:
Attachment 257719

Alternate URLs for photos:
http://s48.photobucket.com/user/Davi...tml?sort=3&o=1
http://s48.photobucket.com/user/Davi...tml?sort=3&o=0

Hi David,

Thanks for the Alternate URLs as the first Attachments are invalid for some reason.

In the screen shot that shows the problem the Y axis DRO is displayed Yellow indicating the Y axis is disabled.

I think we might have an issue with our code where is the Interpreter is waiting for motion to finish in order to execute a C Program and a disable error occurs then the C Program is incorrectly executed instead of properly aborting. Is there a message on the KMotion Console indicating the reason the Y axis is disabled? Or I could be wrong and the M6 program executing too early might be the cause of the Y axis Disable.

Let's get the dummy M6 code that just prints a message working first. Can you post the program that just prints the line to the KMotion Console? The program can not just contain the printf statement. It still needs to include the KMotionDef.h header and the main() body.

Regards

Hi Tom,

Thanks for responding so soon. The message in the console indicates that it has disabled due exceeding Max Follow Error. This is not typical of our Y axis, only in this scenario do we see it disable due to Max Follow Error. You might notice in the first picture that the Z axis DRO reads exactly 3 inches which corresponds to the Gcode command G00Z3.00000 directly before the M6 command (which I partially covered in a red circle).

So in the case of the first picture, (where the gcode interpreter indicates it's on line G01X2.7773Y-0.6579) 3 seconds before the M6 command is reached, the following happens:
1) The Y Axis is disabled due to Max Follow Error
2) The Z Axis goes to 3 inches
3) The X Axis jogs straight to machine coordinate zero (as per the M6 function we are using).

I will run various tests scenarios with a blank M6 and attempt to printf to console and I will post the results by the weekend.

Until then, thanks again for your help,
David.

Ok so I ran several tests using a blank M6 file (containing only a printf)

Each time kmotioncnc gave an error stating an axis was disabled however no axis was disabled (they remain green) and the printf appeares in console long before the gcode reached the M6 command. The two images below will show you what I mean. I cleared the console between tests.

I ran the test several times with the "blank" M6 file, I tried rebooting the kflop between tests, restarting kmotioncnc between tests, and restarting the PC between tests... all with the same result.

Lastly when I removed the M6 command from the gcode the machine consistently completed the gcode without error. This only occurs with the M6 command in the gcode.

Example 1: Example 1 Photo by David_Piccolo | Photobucket
Example 2: Example 2 Photo by David_Piccolo | Photobucket

Just to remind you when the M6 command contains the code as per the first snippet in my first post, it causes an error the first time running through the gcode and works fine if the gcode is restart. In the case of the blank M6 file it doesn't run on the first attempt OR after restarting the gcode.

Thanks,
David.

Hi David,

Sorry I'm having a hard time reproducing the problem.

Could you send me the GCode you are using? Or still better could you test if the example spiral.ngc with M6 inserted at line 50 also has the problem for you.

Please post all your settings: Trajectory Planner Screen and your C Initialization program. Anything else "special" about your configuration that you can think of?

Have you Flashed any programs into KFLOP? Flashing "New Version" will eliminate this possibility.

Please try the latest Test Version:
http://www.dynomotion.com/Software/KMotion433j.exe

Regards

Hi Tom,

I'm pleased to say that after installing 4.33j our problem is resolved! Thank you very much!

Saving the creation of a new thread I've found a potential issue with 4.33j, my cprograms that use pointers no longer seem to work. I have declared several pointers as shown below and they've always worked but now they do not. The c code compiles without error but the pointers simply do not reference the memory location specified (see second example below). For now I've replaced all of my pointers by referencing the persist.UserData variable directly which is ok for the time being, however is there something you can do about this on your end?

Code:

---

double *y_offset = &persist.UserData[75];
double *a_offset = &persist.UserData[77];
double *z_offset = &persist.UserData[79];
double *x_offset = &persist.UserData[81];


double *tool_new = &persist.UserData[83];
double *tool_old = &persist.UserData[85];

---

Test Code:

Code:

---

double *y_offset = &persist.UserData[75];

*y_offset=2.0;

printf("%d\n",*y_offset);  //prints 0 to console
printf("%d\n",persist.UserData[75]); //prints 0 to console

persist.UserData[75]=2.0;

printf("%d\n",*y_offset); //prints 0 to console
printf("%d\n",persist.UserData[75]); //prints 2.0 to console

---

Thanks,
David.

Hi David,

I think the issue is that pointers to doubles must have 64-bit alignments (must be a multiple of 8 bytes). The persist data structure contains 32 bit entities so it does not necessarily have 64-bit alignment. We made a mistake in our earlier examples where we assumed that pairs of UserData variables could be accessed with a double pointer. That worked until one version happened to have an odd offset and broke many older examples. I think your code happened to work with the version with the odd offset that broke our examples. The later Versions now force even alignment with a linker Pragma. So if you change your variables to even Variable numbers it may work. But we also have added example functions in KflopToKMotionCNCFunctions.c that we prefer you to use :

Code:

---

double GetUserDataDouble(int i)
{
        double d;
       
        ((int*)(&d))[0] = persist.UserData[i*2];
        ((int*)(&d))[1] = persist.UserData[i*2+1];
        return d;
}

void SetUserDataDouble(int i, double v)
{
        double d=v;
        persist.UserData[i*2]  = ((int*)(&d))[0];
        persist.UserData[i*2+1] = ((int*)(&d))[1] ;
}

---

These will work regardless of alignment.

HTH
Regards