RobotStudio event

Need urgently help about reltool

Dear Friends,

We made a project about guiding the ABB IRC5 6640 robot with a vision camera system.

We are sending the Y Z variable values from Vision Camera to WinCC to PLC to ABB.

With this value we are changing the Tool offset with this following inputs and rapid code.

 

EIO.cfg

-Name "zPos" -SignalType "AI" -Unit "PBusSlave_PLC" -UnitMap "112-119"\ -Access "Default" -MaxPhys 63 -MaxPhysLimit 10 -MaxBitVal 63 -MinPhys -63\ -MinPhysLimit -10 -MinBitVal -63 -Name "yPos" -SignalType "AI" -Unit "PBusSlave_PLC" -UnitMap "104-111"\ -Access "Default" -MaxPhys 63 -MaxPhysLimit 10 -MaxBitVal 63 -MinPhys -63\ -MinPhysLimit -10 -MinBitVal -63

 

PROGMOD

DispL RelTool (CNT_10, 0, yPos, zPos), v100, b50, z10, tool_1\WObj:=Wobj_3;
DispL RelTool (CNT_20, 0, yPos, zPos), v100, b50, z10, tool_1\WObj:=Wobj_3;
DispL RelTool (CNT_30, 0, yPos, zPos), v100, b50, z10, tool_1\WObj:=Wobj_3;
DispL RelTool (CNT_40, 0, yPos, zPos), v100, b50, z10, tool_1\WObj:=Wobj_3;
                            "                                                                      "

                            "                                                                      "

We need to change the tool ofset in Y Z online!! thats mean real time and guide the robot in Y Z coordinate and guide it. With this above codes its seem to be working in robot manuel mode (point to point) but in automatic mode we dont get the succes result. Expl, the Y and Z values comming to robot AI in 100 ms. and its allways variable, but the robot is not responsing on time to move with this value in Z Y axis. Do we make a mistake! should we put the "zPos" and "yPos" variables to each point like above or directly to the MainModule.mod on the tooldata,

PERS tooldata tool_1 := [TRUE,[[0,0,584],[1,0,0,0]],[5,[0,0,195],[1,0,0,0],0,0,0]];

Note: Our robot is supporting also the multitasking future.

We need urgently help!!!.

Thank you in advance for your help.

Alen. 

Comments

  • Hi alen29

    The vision part etc is not really my area of expertise nor is this a forum I usually visit hence the late reply. But I run support for the robotics SDKs in the Developer Center where we have the PC SDK and there I have seen similar behavior to this, maybe this could be the same thing?

    You see looking at your RAPID you are running with a Zone value. If so then you might be running into the old calculating zones issue. If I do this:

    MoveL Target_10,v1000,z100,tool0\WObj:=wobj0;
    Set do1 := 1;
    MoveL Target_20,v1000,z100,tool0\WObj:=wobj0;

    Then the set do will execute 100mm *BEFORE* Target_10. This because the motion planner needs to calculate the next motion going to Target_20.

    You solve this by using fine points, that tells the motion planner to finish the current move before executing the next. Like this

    MoveL Target_10,v1000,fine,tool0\WObj:=wobj0;
    Set do1 := 1;
    MoveL Target_20,v1000,z100,tool0\WObj:=wobj0;

    In this case the motion will first go to Target_10, then *STOP* in the fine point, and then Set do1, and then start moving to Target_20.

     

    Now what this means for your RAPID is that since they are all zone motions, then the motion planner could be 3-4 rows ahead of the motion pointer. (Depending on how far between those targets really are. What could then be happening is that the motion planner is calculating the next target based on the old data in the new point.

    You can easily test if this is your issue by setting all of those DispL to zone-fine instead, run it and see if it syncs better to your input. If so you need to rethink your zone strategy and the update of the data strategy.

     

    Now when we have PC SDK apps running things like this I also usually recommend to have some sort of checks and balances to see if you are really processing the correct target as updated from the external data. For instance if someone tripped over the network cable - what would happen in your RAPID? The way it looks it seems that it would continue on headlessly ignoring that it no longer is recieving the external data. Now if you had some sort of counter then the execution could make a check and wait if the external data isn't up to par. You can do this with a set of bool handshakes going back and forth or maybe using a num that is increased with the input and you only execute X nr rows, etc etc. But some checks or balances is needed.