1. Home
    1. Dashboard
    2. Search
  2. Forum
    1. Unresolved Threads
    2. Members
      1. Recent Activities
      2. Users Online
      3. Team Members
      4. Search Members
      5. Trophys
  3. Articles
  4. Blog
  5. Videos
  6. Jobs
  7. Shop
    1. Orders
  • Login or register
  • Search
This Thread
  • Everywhere
  • This Thread
  • This Forum
  • Articles
  • Pages
  • Forum
  • Blog Articles
  • Products
  • More Options
  1. Robotforum - Support and discussion community for industrial robots and cobots
  2. Forum
  3. Industrial Robot Support and Discussion Center
  4. ABB Robot Forum
Your browser does not support videos RoboDK Software for simulation and programming
Visit our Mainsponsor
IRBCAM
Robotics Channel
Robotics Training
Advertise in robotics
Sponsored Ads

ABB Integration Vision Rapid code issue

  • H.CHOI
  • August 8, 2024 at 11:11 PM
  • Thread is Resolved
  • H.CHOI
    Reactions Received
    3
    Trophies
    2
    Posts
    35
    • August 8, 2024 at 11:11 PM
    • #1

    Hi everyone,

    I posted ABB integration vision issue a week ago and got a lot of support here. I really appreciate it all

    Just have another question about the rapid code here.

    Basically, we have 2 different job one is LH job and the other one is RH job all vision inspection jobs. If you look at the attached if statement,

    If camjob and tempjob is not equal, we load the job otherwise (I guess same job) we don't load the job and just go to runmode.

    Our sequence is LH job inspection -> RH job inspection -> another RH job inspection

    so after robot loads RH job, we don't need to load same RH job for 3rd inspection.

    so instead of calling Camloadjob, it should go to Camsetrunmode right away

    but somehow robot keep loading the job evenif it is the same job

    Is my if statement wrong?? or any other method to make it work?

    Thanks

    Images

    • camjob.PNG
      • 12.39 kB
      • 460 × 306
      • 13
  • Go to Best Answer
  • Lemster68
    Reactions Received
    301
    Trophies
    9
    Posts
    2,493
    Blog Articles
    7
    • August 9, 2024 at 5:31 PM
    • #2

    Does this happen to be in a NOSTEPIN module? I would suggest if not, then you could single step through it so you could examine and compare the values yourself before the rapid code is executed. That might give you some insight as to what is going on. If it is NOSTEPIN, you could remove that attribute and do as I suggest.

  • bull_boxer454
    Reactions Received
    7
    Trophies
    2
    Posts
    14
    • August 9, 2024 at 5:44 PM
    • #3

    The CamGetLoadedJob function can leave the .job suffix in the string it returns. This will make the <> comparison not match. For example, the string "camjob" does not match a string of "camjob.job". For testing, you can use a TPWrite instruction to show each of the two variables before during testing and make sure the strings are in the same format.

  • ColoradoTaco
    Reactions Received
    16
    Trophies
    3
    Posts
    103
    • August 9, 2024 at 6:17 PM
    • #4
    Quote from bull_boxer454

    The CamGetLoadedJob function can leave the .job suffix in the string it returns. This will make the <> comparison not match. For example, the string "camjob" does not match a string of "camjob.job". For testing, you can use a TPWrite instruction to show each of the two variables before during testing and make sure the strings are in the same format.

    I discovered the exact same thing recently. Here's the routine I'm running in a no-stepin.

    H.CHOI Notice that the string pulled by CamGetLoadedJob does NOT include the .job suffix. I add that to the comparative IF statement to check if the requested job matches.

    Code
        PROC LoadVisionJob(string JobName)
            VAR string currentjob;
    
            currentjob:=CamGetLoadedJob(Cognex_8402);
            TPWrite "Current Cam Job: "+currentjob;
            IF currentjob=JobName+".job" THEN
                TPWrite "Current Job matches Requested Job.";
                RETURN ;
            ELSE
                CamFlush Cognex_8402;
                CamSetProgramMode Cognex_8402;
                TPWrite "Camera set to Program Mode";
                CamLoadJob Cognex_8402,JobName;
                TPWrite "Loaded Camera Job: "+JobName;
                CamSetRunMode Cognex_8402;
                TPWrite "Camera set to Run Mode";
            ENDIF
            RETURN ;
        ENDPROC
    Display More
  • H.CHOI
    Reactions Received
    3
    Trophies
    2
    Posts
    35
    • August 9, 2024 at 7:38 PM
    • #5

    Lemster68  bull_boxer454  ColoradoTaco

    Thank you so much for reply guys.

    Since I am very new to ABB rapid code and this whole script was written by integration company and they don't exist anymore.

    I noticed our original code has commented out "Camgetloadejob" so it actually did nothing.

    if you guys look at the main program, I wanted to run 3 lines

    GetCameraData_LH

    GetCameraData RH

    GetCameraData RH

    in this sequence, RH runs twice so our <> statement should work??

    I attatched GetCameraData_LH (RH is the same but different job name) here as well.

    It will go to InitCam(attached previous message) and read the lines.

    I skipped all Camera error or Camera requirement because we don't have part here.

    When I run in manual mode with flexPendant,

    Line went through CamSetprogrammode->Camloadjob->Camsetrunmode

    and it repeated this sequence 3rd time even if 2nd and 3rd job has the same name

    Is there anything I missed or code issue here?

    Again, thank you so much

    Images

    • main1.PNG
      • 4.56 kB
      • 430 × 71
      • 2
    • 2 4.PNG
      • 6.41 kB
      • 485 × 143
      • 2
  • ColoradoTaco
    Reactions Received
    16
    Trophies
    3
    Posts
    103
    • August 9, 2024 at 7:51 PM
    • #6

    I'm curious to see if you are either dropping or retaining the job name suffix. Also, the GetCamLoadedJob can take a second to process. Sometimes it helps to add just a tiny delay to allow registers to get updated.


    Try this after your GetCamLoadedJob instruction:

    Code
    WaitTime 0.1;
    TPWrite "Camjob:  "+CamJob;
    TPWrite "TempJob: "+TempJob;
    Stop;


    If those two lines don't print out exactly the same on the pendant, you'll have your answer.

  • H.CHOI
    Reactions Received
    3
    Trophies
    2
    Posts
    35
    • August 9, 2024 at 8:37 PM
    • #7
    Quote from ColoradoTaco

    I'm curious to see if you are either dropping or retaining the job name suffix. Also, the GetCamLoadedJob can take a second to process. Sometimes it helps to add just a tiny delay to allow registers to get updated.


    Try this after your GetCamLoadedJob instruction:

    Code
    WaitTime 0.1;
    TPWrite "Camjob:  "+CamJob;
    TPWrite "TempJob: "+TempJob;
    Stop;


    If those two lines don't print out exactly the same on the pendant, you'll have your answer.

    Thank you ColoradoTaco

    I did what you posted here

    Our inspection sequence: LH->RH->RH so after cycle is done, tempjob should be RH

    1st inspection

    camjob: EnvPanelLHEdge0208

    tempjob: EnvPanelRHEdge0208.job

    so it loaded the job

    2nd inspection

    camjob: EnvPanelRHEdge0208

    tempjob: EnvPanelLHEdge0208.job

    so it loaded the job

    3rd inspection

    camjob:EnvPanelRHEdge0208

    tempjob:EnvPanelRHEdge0208.job


    So 3rd inspection, it is same job name but it loaded job again

    Is it because of .job at the end of tempjob? like other guys mentioned above?

    If so, how to remove that .job?

    right now i have

    tempjob:=CamGetLoadedJob(Envelope_Camera);

    and camgetloadedjob and envelope_camera are blue colored

  • Lemster68
    Reactions Received
    301
    Trophies
    9
    Posts
    2,493
    Blog Articles
    7
    • August 9, 2024 at 8:54 PM
    • #8

    Yes, that is what is going on, they don't match. It was suggested that you add the .job to what you are comparing so they do match, not remove the .job from the other.

  • H.CHOI
    Reactions Received
    3
    Trophies
    2
    Posts
    35
    • August 9, 2024 at 9:07 PM
    • #9
    Quote from Lemster68

    Yes, that is what is going on, they don't match. It was suggested that you add the .job to what you are comparing so they do match, not remove the .job from the other.

    Thank you Lemster68

    should I add .job right next to the string camjob? like string camjob.job? it gives me an error

    sorry about stupid question

  • ColoradoTaco
    Reactions Received
    16
    Trophies
    3
    Posts
    103
    • August 9, 2024 at 9:18 PM
    • Best Answer
    • #10

    H.CHOI it is a LOT easier to add characters to a text string than to parse them out of an existing string.

    You can do it like this in your IF statement

    IF currentjob=JobName+".job" THEN

    For comparison, here is the vision load routine I run. It checks the existing job first, and only loads if the requested job is different.

    Code
        PROC LoadVisionJob(string JobName)
            VAR string currentjob;
    
            currentjob:=CamGetLoadedJob(Cognex_8402);
            TPWrite "Current Cam Job: "+currentjob;
            IF currentjob=JobName+".job" THEN
                TPWrite "Current Job matches Requested Job.";
                RETURN ;
            ELSE
                CamFlush Cognex_8402;
                CamSetProgramMode Cognex_8402;
                TPWrite "Camera set to Program Mode";
                CamLoadJob Cognex_8402,JobName;
                TPWrite "Loaded Camera Job: "+JobName;
                CamSetRunMode Cognex_8402;
                TPWrite "Camera set to Run Mode";
            ENDIF
            RETURN ;
        ENDPROC
    Display More
  • H.CHOI August 9, 2024 at 11:43 PM

    Selected a post as the best answer.
  • H.CHOI
    Reactions Received
    3
    Trophies
    2
    Posts
    35
    • August 9, 2024 at 11:44 PM
    • #11
    Quote from ColoradoTaco

    H.CHOI it is a LOT easier to add characters to a text string than to parse them out of an existing string.

    You can do it like this in your IF statement

    IF currentjob=JobName+".job" THEN

    For comparison, here is the vision load routine I run. It checks the existing job first, and only loads if the requested job is different.

    Code
        PROC LoadVisionJob(string JobName)
            VAR string currentjob;
    
            currentjob:=CamGetLoadedJob(Cognex_8402);
            TPWrite "Current Cam Job: "+currentjob;
            IF currentjob=JobName+".job" THEN
                TPWrite "Current Job matches Requested Job.";
                RETURN ;
            ELSE
                CamFlush Cognex_8402;
                CamSetProgramMode Cognex_8402;
                TPWrite "Camera set to Program Mode";
                CamLoadJob Cognex_8402,JobName;
                TPWrite "Loaded Camera Job: "+JobName;
                CamSetRunMode Cognex_8402;
                TPWrite "Camera set to Run Mode";
            ENDIF
            RETURN ;
        ENDPROC
    Display More

    Thanks everyone ColoradoTaco  bull_boxer454  Lemster68

    it is matching and robot skip the loading the job between 2nd and 3rd inspection

Advertising from our partners

IRBCAM
Robotics Channel
Robotics Training
Advertise in robotics
Advertise in Robotics
Advertise in Robotics

Job Postings

  • Anyware Robotics is hiring!

    yzhou377 February 23, 2025 at 4:54 AM
  • How to see your Job Posting (search or recruit) here in Robot-Forum.com

    Werner Hampel November 18, 2021 at 3:44 PM
Your browser does not support videos RoboDK Software for simulation and programming

Tag Cloud

  • abb
  • Backup
  • calibration
  • Communication
  • CRX
  • DCS
  • dx100
  • dx200
  • error
  • Ethernet
  • Ethernet IP
  • external axis
  • Fanuc
  • help
  • hmi
  • I/O
  • irc5
  • IRVIsion
  • karel
  • kawasaki
  • KRC2
  • KRC4
  • KRC 4
  • krc5
  • KRL
  • KUKA
  • motoman
  • Offset
  • PLC
  • PROFINET
  • Program
  • Programming
  • RAPID
  • roboguide
  • robot
  • robotstudio
  • RSI
  • safety
  • Siemens
  • simulation
  • SPEED
  • staubli
  • tcp
  • TCP/IP
  • teach pendant
  • vision
  • Welding
  • workvisual
  • yaskawa
  • YRC1000

Thread Tag Cloud

  • abb
  • Backup
  • calibration
  • Communication
  • CRX
  • DCS
  • dx100
  • dx200
  • error
  • Ethernet
  • Ethernet IP
  • external axis
  • Fanuc
  • help
  • hmi
  • I/O
  • irc5
  • IRVIsion
  • karel
  • kawasaki
  • KRC2
  • KRC4
  • KRC 4
  • krc5
  • KRL
  • KUKA
  • motoman
  • Offset
  • PLC
  • PROFINET
  • Program
  • Programming
  • RAPID
  • roboguide
  • robot
  • robotstudio
  • RSI
  • safety
  • Siemens
  • simulation
  • SPEED
  • staubli
  • tcp
  • TCP/IP
  • teach pendant
  • vision
  • Welding
  • workvisual
  • yaskawa
  • YRC1000
  1. Privacy Policy
  2. Legal Notice
Powered by WoltLab Suite™
As a registered Member:
* You will see no Google advertising
* You can translate posts into your local language
* You can ask questions or help the community with your knowledge
* You can thank the authors for their help
* You can receive notifications of replies or new topics on request
* We do not sell your data - we promise

JOIN OUR GREAT ROBOTICS COMMUNITY.
Don’t have an account yet? Register yourself now and be a part of our community!
Register Yourself Lost Password
Robotforum - Support and discussion community for industrial robots and cobots in the WSC-Connect App on Google Play
Robotforum - Support and discussion community for industrial robots and cobots in the WSC-Connect App on the App Store
Download