[slimneill]

Hi Tom,

We have fabricated the 4th axis for our machine and are about to start programming it and testing it out. Both ends of the 4th axis (Motor/Part Chuck and the Tail stock) are tall and will make contact with the spindle/cutter at full Z height if they drive over top of them. Needless to say I’m very fearful of a crash occurring as I learn what I’m doing.

I was reading a bit and saw the soft limits, I understand how they work in the context of the overall working envelope, to manually get you back in a safe zone before hitting the hard limits. But I was wondering if you can apply 2 “no fly zones” in terms of X&Y rectangles placed on the X&Y coordinates so that if the machine were to drive into these areas it stops and waits for operator intervention to move it safely out of the way preventing a crash.

I was trying to think of how that could be executed, can there be something added to the initialization file that reads a table of the user inputted X&Y machine coordinates for the no fly zone and applies them as soft limits?

We will be moving the tail stock and head stock around the table based on 4th axis part size so having a table file we input would be the best way to keep the machine aware of where the obstacle are located on the table and when the 4th axis is not present we can remove the no fly zones from the program table and the machine operates like usual.

Any advice or suggestions would be greatly appreciated.
Thanks,
Dan

Attachment 381848

[mmurray70]

You could add a check to your forever loop that would look for X and Y position being in a certain range and if they both were you could get it to stop, E-stop or whatever you wanted. You would need to know the start and end of the two zones for each axis.

Might be more practical to just really watch things closely for the first part. I used to do alot of 4th axis stuff at my last job, its not too bad after a while. One good piece of advice i can give you is to take the 4th axis off when doing non 4th axis work. Even if you think you have enough room lol.

[CL_MotoTech]

Can you model the fixture in your CAM?

[slimneill]

Yeah i found some soft limits C code in the Kmotion folder, I've made some code that i will try. I'll see if my coding skills have gotten better.

And yes we have a small vacuum table that sits on the bed and it always seems to be in the way. We need to make more storage around the shop.

[slimneill]

Can you model the fixture in your CAM?

No I don't think so. I'll have to look into what fusion can do.

[TomKerekes]

Hi Dan,

I think a simple test for an invalid region should be pretty simple. Just a few "if" conditions. But if your machine requires a significant distance to stop, and you can't simply increase your invalid regions to accommodate this, then it may be more complicated.

Regards

[slimneill]

Hi Dan,

I think a simple test for an invalid region should be pretty simple. Just a few "if" conditions. But if your machine requires a significant distance to stop, and you can't simply increase your invalid regions to accommodate this, then it may be more complicated.

Regards

Ok thanks Tom, the only thing I'm a little fuzzy on right now is making sure the coordinate system is correct. All c code is based off of counts right? So I will have to multiply my distances (in inches) by the counts/inch for that axis correct? Also I think that since I'll be using machine coordinates and not part zero coordinate system I don't have any trickery there to deal with right?

[TomKerekes]

Hi Dan,

That all sounds correct. Although it might be better to divide by the resolution in counts/inch to convert the current position to inches, then do all the checks in inches.

Regards

[slimneill]

Hi Tom,

I got the soft limits to work in principle. Every time i enter the 2 zones from any direction all 3 axis get disabled which is good.

I'd like to make it so that i can back off of the limit and keep going without having to re-initialise and home and start from the beginning. I read your Rev2 for soft limits which i think dose this but im not sure how to apply the function when im dealing with 4 conditions that need to be met.

I've attached my code below for you to see. I made 2 arbitrary box sizes for testing. Called "Head" for Head stock and "Tail" for Tail stock

Thanks Dan

[TomKerekes]

Hi Dan,

You would need to come up with some strategy for what you want to do?

The simplest would be to add an override button that you might use to disable the no-fly zones. Of course the Operator could then still crash the spindle.

Otherwise you might determine the direction that would move out of the limits in the shortest direction and disallow motion in any other direction.

Or save the direction of motion that each axis was moving in when "Inlimit" was first detected. Then only allow motion for any axis in the opposite direction.

Regards

[slimneill]

Hi Tom,

I think the first approach is fine. (Button to disable the no fly zone) How do I include that into the C code?

I see that there are 2 Soft Limit files in the example C code Folder. Does the Rev 2 file include the back up approach for a simple soft limit working envelope?

I also realised that this soft limits code doesn't work when i'm doing a tool change (M6 C Program) or when homing the machine (Homing C Program). How do I keep this program active when other C programs are being initiated?

Sorry lots of questions all at once. I've included a picture of the new 4th axis set up we built. We were making a Christmas tree out of a 4" cedar post and when we went to run the finishing 3d tool path the spindle went up in the Z and crashed. It took out the Viper drive and needs to be shipped away for repair. So i found another application for soft limits i didn't think i needed

That's an 8" Chuck btw. Coke can for scale.

[m_c]

That V2 file should let you back out of limits, however it's still disabling things.

What I think you're wanting to do, is activate a feedhold when you enter your no-fly zones.
Then as Tom has said, you want some way to track/test how you ended up in the no fly zone, then only allow movement in the safest direction.

However, I suspect that provided things stop when you hit a no-fly zone, you'd be happy enough to simply disable the no-fly zones, move to a safe point, then re-enable the no-fly zones?

[slimneill]

That V2 file should let you back out of limits, however it's still disabling things.

What I think you're wanting to do, is activate a feedhold when you enter your no-fly zones.
Then as Tom has said, you want some way to track/test how you ended up in the no fly zone, then only allow movement in the safest direction.

However, I suspect that provided things stop when you hit a no-fly zone, you'd be happy enough to simply disable the no-fly zones, move to a safe point, then re-enable the no-fly zones?

Yeah, when it breaches a no fly zone it stops instantly, there is no drift. A feedhold is all im looking for.

[m_c]

In that case, instead of disabling all the axes, you want to use this line-

StopCoordinatedMotion();  //feedhold

Then the easiest way to enable/disable things, is to have a button that simply toggles a virtual, so you should end up with something like this-

#include "KMotionDef.h"

#define XRes 19190.2062692 //Counts/inch
#define YRes 22854.4476 //Counts/inch
#define ZRes 28853.846 //Counts/inch

#define XMIN_Head 	40
#define YMIN_Head	15
#define XMAX_Head 	54
#define YMAX_Head	34

#define XMIN_Tail 	60
#define YMIN_Tail	20
#define XMAX_Tail 	70
#define YMAX_Tail	34

#define NoFlyEnabled 1020 // 1020 picked at random!!! Change to something unused
 
int X1=XMIN_Head*XRes;
int X2=XMAX_Head*XRes;
int X3=XMIN_Tail*XRes;
int X4=XMAX_Tail*XRes;


int Y1=YMIN_Head*YRes;
int Y2=YMAX_Head*YRes;
int Y3=YMIN_Tail*YRes;
int Y4=YMAX_Tail*YRes;

 
main()
{
	for (;;)  // loop forever
	{
		if (ReadBit(NoFlyEnabled) && InLimit())  // If our no fly zones are enabled, and we're in one
		{
			StopCoordinatedMotion();  // activate feedhold
		}
	}
}

int InLimit()
{
	WaitNextTimeSlice();
	
return ((ch0->Dest >X1 && ch0->Dest <X2) && (ch1->Dest >Y1 && ch1->Dest<Y2)) || ((ch0->Dest >X3 && ch0->Dest<X4) && (ch1->Dest > Y3 && ch1->Dest<Y4));

}

You'll need to add some way to toggle the virtual bit, but all that loop should do now, is if your no fly zones are enabled, and you're within one, it will activate a feedhold.
Once you disable the no fly zones, you'll be able to jog around with no limitations.

[TomKerekes]

Hi Dan,

I also realised that this soft limits code doesn't work when i'm doing a tool change (M6 C Program) or when homing the machine (Homing C Program). How do I keep this program active when other C programs are being initiated?

I'm not sure how you are running the code. If you are running it in some Thread and then run some other program (Tool change or home) in the same Thread then the new program will kill and overwrite the Limits program. Normally you would add the Limits checking to a forever loop at the end of your Initialization program.

I see that there are 2 Soft Limit files in the example C code Folder. Does the Rev 2 file include the back up approach for a simple soft limit working envelope?

Yes the idea is to only disable if in the Limit and also moving in the direction of the limit. That is an older example there is now a better variable available called ch->DirectionOfMotion

Here is a program that might work (untested ) It should only disable if moving inward within either of your zones. That should allow you to re-initialize and remain enabled even if you are within a zone as long as you don't move the wrong direction.

Actually I only now realize that this assumes the machine coordinates are still correct after a re-initialization. Is this true? Also before Homing we don't know where we are or where the zones are so we can't really do any protection. How are you handling this now?

#include "KMotionDef.h"

#define XRes 19190.2062692 //Counts/inch
#define YRes 22854.4476 //Counts/inch
#define ZRes 28853.846 //Counts/inch

#define XMIN_Head 	40
#define YMIN_Head	15
#define XMAX_Head 	54
#define YMAX_Head	34

#define XMIN_Tail 	60
#define YMIN_Tail	20
#define XMAX_Tail 	70
#define YMAX_Tail	34


int X1=XMIN_Head*XRes;
int X2=XMAX_Head*XRes;
int X3=XMIN_Tail*XRes;
int X4=XMAX_Tail*XRes;


int Y1=YMIN_Head*YRes;
int Y2=YMAX_Head*YRes;
int Y3=YMIN_Tail*YRes;
int Y4=YMAX_Tail*YRes;

void HandleZone(double minx, double maxx, double miny, double maxy);
BOOL CheckInRange(double x, double min, double max, int *dir);

main()
{
    for (;;)  // loop forever
    {
        WaitNextTimeSlice();
        HandleZone(X1,X2,Y1,Y2);  // disable if moving in a bad direction in Head Zone
        HandleZone(X3,X4,Y3,Y4);  // disable if moving in a bad direction in Tail Zone
    }
}

// Disable all if we are within a Zone and either x or y are moving in a bad direction 
void HandleZone(double minx, double maxx, double miny, double maxy)
{
    int dirx, diry;
    if (CheckInRange(ch0->Dest, minx, maxx, &dirx) &&
        CheckInRange(ch1->Dest, miny, maxy, &diry) &&
        (ch0->DirectionOfMotion == dirx || ch1->DirectionOfMotion == diry))
    {
        DisableAxis(0);
        DisableAxis(1);
        DisableAxis(2);
    }
}

// check if within range and if so return direction that 
// would move further inward from the closest edge
// returns true if within range 
BOOL CheckInRange(double x, double min, double max, int *dir)
{
    if (x>min && x<max)  // within range?
    {
        if (x-min < max-x) // closer to min?
            *dir = 1;  // yes, positive would go further inward
        else
            *dir = -1; // no, negative would move further inward

        return TRUE;
    }
    return FALSE;
}

[slimneill]

-Each C program is ran in a separate thread. Initialization, Homing, Soft Limit, etc. I didn't get to the point of adding the soft limits code to the Initialization file. I was just testing it out of the C program area in Kmotion.

-We damaged the Z Axis Viper drive during our initial test, so we are down to 3 axis for now. Once it gets fixed and I'm back in town I'll have another go at this little project.

-Before homing I manually make sure the spindle isn't going to crash into anything, I didn't really think about that issue either until you said that. At this point we are just trying to learn how to program the 4th axis and make that work. Tool changes are being done manually for now, but once i get into 4th axis with automatic tool changes i'll have to tweak my post processor or Tool change C code so that it moves the spindle clear of the rotary axis zone before retrieving a tool and then brings it back to the same location before continuing with that new tool so that it doesn't crash depending on the 4th axis direction (X or Y) configuration. It shouldn't be an issue when the 4th axis runs along the Y direction but it till be when it's run along the X.

Happy Holidays Tom