khalil-yazji Posted August 4, 2020 Posted August 4, 2020 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 Posted August 4, 2020 Posted August 4, 2020 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 Posted August 5, 2020 Author Posted August 5, 2020 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 Posted August 6, 2020 Posted August 6, 2020 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 Posted August 14, 2020 Author Posted August 14, 2020 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 Posted August 14, 2020 Posted August 14, 2020 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 Posted August 17, 2020 Author Posted August 17, 2020 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 Posted August 17, 2020 Posted August 17, 2020 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 Posted August 19, 2020 Author Posted August 19, 2020 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 Posted August 19, 2020 Posted August 19, 2020 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 Posted August 20, 2020 Author Posted August 20, 2020 I couldn't replicate the issue by running the same motion program from the terminal.
Omron Forums Support Posted August 20, 2020 Posted August 20, 2020 Can you replicate the issue without the HMI if you make the C App dumb the program into the buffer?
khalil-yazji Posted August 27, 2020 Author Posted August 27, 2020 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 Posted September 17, 2020 Posted September 17, 2020 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?
Recommended Posts