kandauru Posted November 5, 2017 Share Posted November 5, 2017 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 More sharing options...
Omron Forums Support Posted November 6, 2017 Share Posted November 6, 2017 Are you saying only the motor you're moving stops or multiple motors are stopping? In either case, take a look at the motor status window and possibly coordinate status window. Link to comment Share on other sites More sharing options...
kandauru Posted November 7, 2017 Author Share Posted November 7, 2017 It was a hardware limit. I've just caught the moment when it stopped and found Coord[x].LimitStop flag signaled. The limit was damaged. Link to comment Share on other sites More sharing options...
kandauru Posted November 8, 2017 Author Share Posted November 8, 2017 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 More sharing options...
steve.milici Posted November 8, 2017 Share Posted November 8, 2017 How is the M-variable defined? Link to comment Share on other sites More sharing options...
kandauru Posted November 8, 2017 Author Share Posted November 8, 2017 M-variable defined as: M1->Gate3[0].Chan[0].EquWrite. There are about 900 lines starting with M1==1 or M1==3 and then positions of motors. In most cases it's running well, but there are couple of lines where it happens. Link to comment Share on other sites More sharing options...
steve.milici Posted November 8, 2017 Share Posted November 8, 2017 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 More sharing options...
kandauru Posted November 9, 2017 Author Share Posted November 9, 2017 Thanks for you help! Link to comment Share on other sites More sharing options...
kandauru Posted November 9, 2017 Author Share Posted November 9, 2017 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 More sharing options...
steve.milici Posted November 9, 2017 Share Posted November 9, 2017 What is the value of Coord[x].SyncOps? If you increase this does the problem clear up? See the section in the "Power PMAC Users Manual", " Power PMAC Special Lookahead Function" starting on page 736 for details on setup for this. Link to comment Share on other sites More sharing options...
kandauru Posted November 10, 2017 Author Share Posted November 10, 2017 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. Link to comment Share on other sites More sharing options...
kandauru Posted November 11, 2017 Author Share Posted November 11, 2017 Hi again, according to what I understand from the example above, we cannot run the system with block rate more than 1000 blocks/sec, because Coord[x].SegMoveTime will be 1 msec in this case and it is already very critical for CPU. Am I right? Link to comment Share on other sites More sharing options...
bradp Posted November 13, 2017 Share Posted November 13, 2017 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 More sharing options...
curtwilson Posted November 13, 2017 Share Posted November 13, 2017 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 More sharing options...
Recommended Posts