BlockRequest in motor status

[khalil-yazji]

Hi all

 

I have a C app that receives a set of target positions from an HMI over UDP connection and make them into a motion program. at the end of the motion program it sets a global variable flag that triggers a response in the rticplc and/or plc to kill all motors.

Most of the time this method works fine but I noticed sometimes the motion program will finish the move but the motion program will keep running with the motors still enabled but not moving and the global flag doesn't get set to kill the motors, when this happens the BlockRequest bit in the running motors status is true.

I looked into the manuals and the software reference for information on BlockRequest but couldn't find anything conclusive about it.

What is the BlockRequest bit and why is it stopping the motion program to terminate and how to prevent this issue from happening in the first place?

 

Thanks in advance.

[Omron Forums Support]

Does anything in your coordinate system status screen look off when this happens? What value does Coord[x].ErrorStatus have? It sounds like your motor is just saying the motion program died without telling it how to do it's next move.

[khalil-yazji]

Does anything in your coordinate system status screen look off when this happens? What value does Coord[x].ErrorStatus have? It sounds like your motor is just saying the motion program died without telling it how to do it's next move.

 

Thanks for your reply.

I can't see anything else looking off in the coordinate system and I checked the errorstatus and it's 0.

one thing I noticed that when this happens Coord[1].Ldata.Status is 112 and when the motion program works fine it's 96.

by looking at the manuals this is related to single step mode. but I'm not using that.

[Omron Forums Support]

That global variable flag may be taking affect too early, while the program is still technically running. You might try adding a small delay to the PLC before the motors are killed to test this theory.

 

Does the code being inserted into the rotary buffer have a synchronous assignment like below? (double equal) so the flag is not set early?

MyVar==1
DWELL 0
CLOSE

[khalil-yazji]

when this happens the global variable doesn't change at all. it feels like the motion program gets stuck at the move line and doesn't continue even though in task manager it's still running and the motors are still enabled.

 

I tried the synchronous assignment and it doesn't seem to make any difference.

 

Here's an example of the motion programs created by the C app:

 

linear
abs
ta0
ts5000
frax(bb,cc)
F0.000054
BB446.704468CC500.401489dwell0P8204++
dwell5000
P8212==1dwell0
P8428==1dwell0

 

most of the motion programs created in this app are similar to this example as they are usually a single move on 1-4 motors.

 

ps. when the program get stuck even the P8204++ at the end of the move line is not executed.

[Omron Forums Support]

Can you try making the code add a space after the dwell0? That seemed to make the issue go away when I got it to show up.

[khalil-yazji]

when creating the motion program the app adds a space but when reading the motion program in the terminal using list prog it shows no spaces.

I even removed the dwell 0 completely and I'm still getting the same issue.

[Omron Forums Support]

I am not able to replicate the issue. I thought I had it at one point, but that was just because BB wasn't in my frax and was moving VERY slowly.

 

Do you know if you are using lookahead? What are Coord[1].LHSize and Coord[1].SegMoveTime?

[khalil-yazji]

I don't think I'm using lookahead.

Coord[1].LHsize =0, Coord[1].SegMoveTime =10.

 

is the lookahead enabled or disabled by default? and how to make sure it's disabled?

[Omron Forums Support]

By default PMAC looks ahead a limited number of segments. With Coord[1].SegMoveTime at a non-zero value lookahead is disabled.

If you want lookahead with SegMoveTime you have to define a gather buffer and then set Coord[1].LHsize above 0.

 

Can you replicate the issue without the C App?

[khalil-yazji]

I couldn't replicate the issue by running the same motion program from the terminal.

[Omron Forums Support]

Can you replicate the issue without the HMI if you make the C App dumb the program into the buffer?

[khalil-yazji]

It only seems to happen when starting the motion program from the HMI. I'm using the same commands both in the terminal and the C app to start the program

error_code += Command("&1 enable");
error_code += Command("&1b2r");

[Omron Forums Support]

Commanding the motion program to run through C doesn't help me replicate the problem. Can you make a C program that just has the Motion program already in quotes and builds then runs it to see if it can replicate the issue?