Jump to content
OMRON Forums

Trigger an event before reaching the end of a motion path


JTopp
 Share

Recommended Posts

I have code using Coord[X].NCalc and Coord[X].LookaheadFlush to determine when the end of the path is calculated.  Using the sys.time I trigger an event a certain amount of time before the machine physically reaches the end of the path.  I have used this code before and had no problems however with this machine it fails about 5% of the time.  This code is in a realtime routine that runs at a frequency of 2khz.  I can't seem to figure out what would cause this to not work sometimes.  I attached the motion program.

 

Coord[1].LHSize=2000

Coord[1].LHDistance=200

Coord[1].SegMoveTime=1

LHDtime = 200;

 

if (Coord[1].NCalc == 200 && Coord[1].LookAheadFlush == 1 && ShutoffOS == 0)

{

segToEnd = Sys.Time;

ShutoffOs = 1;

}

if (ShutoffOS)

{

vElapTime = Sys.Time - segToEnd;

if (vElapTime >= ((LHDtime - ValveOffTime)/1000))

{

doValve = 0;

ShutoffOS = 0;

}

 

PmacSyntax - Copy.txt

Link to comment
Share on other sites

  • Replies 6
  • Created
  • Last Reply

Top Posters In This Topic

I don’t know what “ShutoffOS” refers to but I suspect it makes the event asynchronous to the servo cycle. Even a user servo could miss this from time to time.

I would suggest using a synchronous variable assignment statement before the “end of path” of your program. Then put an “extra” DWELL0 after that.

The synchronous variable assignment statement calculates an expression value and uses it to assign a value to a variable but delays the assignment until the start of actual execution of the next move commanded from the program.

See the “Power PMAC User’s Manual” in the section “Synchronous Variable Value Assignment” for implementation details starting on page 558.

 

Link to comment
Share on other sites

Thank you for your response!

We are using the ShutoffOS so ensure that once the end of path is in the lookahead buffer we stop that code from executing.  That variable is only set high in the code shown above.  We are using the NCalc and LookaheadFlush to determine when the end of the path has been calculated and is in the lookahead buffer.  I have been able to figure out that the code with NCalc and Lookahead flush is just not being run sometimes.

 

I am looking into using Synchronous variables but it is difficult in our application because we run a lot of different paths, so it is better for us to use a time based shutoff from the end of the path.

Link to comment
Share on other sites

I updated my code to use synchronous variables shown in the attachment.  I put one at the beginning of the path, I trigger using this one, and one at the end of the path.  I am not seeing the same problem as I was, but I am seeing a problem with the trigger happening too late sometimes (about 5% of the time).  I put a timer on for the path time, using the two synchronous variables I added, and I found that the times we are turning off too late the path time is shorter by about 15ms.  

 

It appears that sometimes the path is running faster.  I thought maybe we were exiting the motion program early, but the entire path is being completed.

PmacSyntax.txt

Link to comment
Share on other sites

When the next move after the assignment executes, the value is assigned to the variable. This assignment is done at the real-time interrupt (RTI) priority level. For segmented moves (as in a circle move), the assignment is done at the beginning of the first segment to start within the new programmed move. This could differ by one RTI (or segmentation) cycle from time to time.

Since I don’t think you have your RTI period set that long (15ms) I might suspect this time difference is due to how you are triggering from it or your Coord[x].SegMoveTime is “large”. The same program would not have different execution times if the moves have not changed.

What is your servo frequency, Sys.RtIntPeriod and Coord[x].SegMoveTime

Link to comment
Share on other sites

My servo frequency is set to 8kHz, the sys.RtIntPeriod is 0, and the Coord[x].SegMoveTime is set to 1. 

We are running the same path every cycle however we are translating the path (X, Y and Theta) on a part to part basis.

Link to comment
Share on other sites

Your settings are relatively high frequencies and are probably not be the source of the “15ms” delay you see. I would suspect your “translation” as the culprit.

This would be a technical support issue.

Please contact ODT's direct technical support with your full issue details at:

ODT-Support@Omron.com

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share


×
×
  • Create New...