Jump to content
OMRON Forums

Unexpected stop


kandauru
 Share

Recommended Posts

Hi All,

 

there is system with 10 axes. When I try to move one axis or more in jog, rel or abs mode, sometimes the movement unexpectedly stops. Also it happens in automatic test

where I use rotary buffer and lookahead functionality. My question - is there any way to know what was the reason for unexpected stop?

I used to look at Coord[x].ErrorStatus value, but in my case it is not informative.

 

Please, advise.

Link to comment
Share on other sites

  • Replies 13
  • Created
  • Last Reply

Top Posters In This Topic

Hi,

 

Now it looks much better, but sometimes I am getting the following error message in PPMAC Error window:

CoordExecStatus[1] = Stopped on Illegal Synchronous Assignment: prog0:0:M1==3 X4281.42145216373 Y1709.91811048309 Z1126.69892968668 U-188.953080151833 V92.6215471326753 @ 11/8/2017 11:02:18 AM

 

Can somebody explain, please, what could be a reason for it?

This error leads to unexpected stop of the motors too.

Link to comment
Share on other sites

If you have multiple assignments per line with significantly deep lookahead the setting of “Coord[x].SyncOps” may not be large enough to accommodate the assignments under some executing circumstances. Try increasing this value.

 

If you change the value of Coord[x].SyncOps , you need to issue a save command and reset the Power PMAC before attempting to use any of the

synchronous assignment buffers.

Link to comment
Share on other sites

Hi,

Just let me know if am I right.

there are always two lines like the following - " M1==3 X4266.9636 XX5038.4409 Y1712.6760 YY-1584.7391 Z1295.9240 ZZ1390.4039 U-189.4451 UU-189.4451 V96.8888 VV-83.1111"

per resolution((for M1==3 and M1==1)). Our current and regular resolution is 2 mm.

The speed is 100 mm/sec and the distance, let it be 1000 mm. So, there will be distance/resolution*2 = 1000 lines

are ready to be loaded into rotary buffer.

To run it with the given speed, I need at least 100 blocks be ready at start position (loaded into rotary buffer).

Is it correct? What should be a size of lookahead buffer for this example?

What should be Coord[x].SegMoveTime (right now is 5)?

I am still facing the problem with unexpected stops.

Link to comment
Share on other sites

Hi,

 

I did it exactly according to the book, and it was working for long period of time successfully, but recently

the direction of the trajectory has been changed from Y to X and the problem started coming.

Coord[x].SyncOps=16384.

Could you explain, please, what does it mean - block rate to in attached example.

There are a speed and an acceleration in our system as desired parameters.

LookAHead.jpg.b1826c737bd4830969648797859d6474.jpg

Link to comment
Share on other sites

In general terms you are not correct. The segmentation time can be larger than the time for one move block. This is very common. If this is desired depends on the specifics of the trajectory and application you are doing. In this case you must think of two things. First, the segmentation will curve fit the trajectory with a cubic profile. So you will not see features in the trajectory smaller than the segmentation time. Second is that synchronous assignments are executed at the segment boundary. If you have multiple move blocks in one segment then all synchronous assignments will be triggered only at the boundary. What I understand from your application is that you need an output for every move and you are doing this by synchronous assignment. So unless a different method is used, you should not have move blocks smaller than segmentation time.
Link to comment
Share on other sites

In Power PMAC, Coord[x].SegMoveTime is a floating-point number that can be set less than 1.0 msec. (This is not true in the older PMAC and Turbo PMAC controllers.)

 

In my desktop test system, I have it set to 0.05 msec (50 microseconds). We have several customers that run 10,000 programmed move blocks per second for extended periods of time.

 

As Brad explained above, having programmed move block times shorter than the segmentation time does not cause failure, but the segmentation process will smooth over the trajectory, so you cannot expect the commanded trajectory to have the detail of such a short programmed move.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share


×
×
  • Create New...