Jump to content

Search the Community

Showing results for tags 'cobots'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Support

  • Technical Support Forums
    • Cognex
    • Collaborative Robots
    • Epson
    • Intelligent Actuator (IAI)
    • Mitsubishi Electric
    • SICK
    • Other Vendors

News & Blogs

  • News & Announcements
  • Products & Technology

Categories

  • Cognex
    • 3D Vision Systems
    • Dataman Barcode Readers
    • Deep Learning Systems
    • In-Sight Vision Sensors
    • In-Sight Vision Systems
  • Collaborative Robots
    • Kassow Robots
    • Mecademic
    • MiR Mobile Industrial Robots
    • OnRobot
    • Precise Automation
    • Robotiq
    • ROEQ
    • Schunk
    • Universal Robots (UR)
  • Epson
    • Robots
  • Intelligent Actuator (IAI)
    • Positioning Controllers
    • Programmable Controllers
    • Fieldbus Protocols
  • Mitsubishi
    • Controllers
    • Drive Products
    • Robots
    • Visualization
    • Other Mitsubishi Products
  • SICK
    • Identification & Vision
    • Measurement & Ranging
    • Safety
    • Sensors
    • Other Sick Products
  • Other Vendors
    • Advanced Illumination
    • Beijer Electronics
    • Captron
    • CCS America
    • Crevis
    • Ellitek (Data Commander)
    • Flexibowl
    • GAM
    • HMS (eWon/Anybus)
    • Moritex
    • Oriental Motor
    • Pepperl + Fuchs
    • RFID Inc.
    • Robotunits
    • ROLLON Corp
    • Schmalz
    • Schmersal
    • SHIMPO
    • Smart Vision Lights
    • Tri-Tronics
    • WAGO
    • Wittenstein (Alpha Gear)
    • Other

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me


Company Name

Found 1 result

  1. I've been supporting the implementation of a Kassow KR1410 collaborative robot for a pack out application, I wanted to provide some tips on integrating a collaborative robot based on my experiences. Fully understand the system requirements I cannot emphasize how important it is to understand the system requirements, or if there is a machine that already does a similar job it is very important to study that machine and fully understand the process. After I’m confident in the requirements, I try to come up with a plan or a sequence in my mind on how I should be programming the robot, which brings me to the second step. Make a sequence of operations document Write down the sequence of operations. This is different from how the machine is going to work, this is how components of the machine are going to communicate. Take a look at the snippet below; This sequence can be tweaked when actually programming the machine. Often there are multiple programmers working on a machine so for example it is good to have a document where the PLC guy understands what the Robot guy is going to do in their program, and vice versa. As you can see in the snippet above, feel free to assign the I/O and registers on how the communications are going to work. Write pseudocode For those who don’t know what pseudocode is, it’s just a simplified program. This step cuts down the time that’s spent on the machine by a lot. I usually have most of the program already written out before I even start working with the cobot. Take a look at the code below, it’s mostly comments but now I know what exactly I need to program. Work with the cobot and machine After having the pseudocode, I go on the machine and start by setting up all my communications, Modbus, TCP/IP, check digital I/O, etc.. Next, I start teaching positions and building the sequence step by step. Test I am not going to call this the last step because you would be more successful if you have already been testing along with the rest of the above steps. Whenever I feel like a part of the program is done, I test to make sure that part works. This works well when you’ve written your code in a modular way. For example, the main program that I run on the robot will only consist of several lines. I usually have two loops, one that runs once, my initialization loop, and a loop that has my main program that always runs. In the initialization loop, I make sure all my variables are reset, I read all the sensors tied in and make sure I am aware of everything that is going on that the robot should know. This should happen only once in the program. My main loop is most often a “while (1) loop”. This is an infinite loop that never ends, unless I call a “break” from the loop. This break prevents me from getting stuck anywhere inside my program and I never leave the robot in a state that’s not great. For example, I always try to go back to a home or safe position when a task is complete. One situation where I make this loop to rely on a variable is if I have another controller, a PC or a PLC that tells the robots what to do. Going back to the testing, (it is really hard but) make sure to try to account for all cases that can happen. This could be safety related, operation related or even part related. Testing all the “what-if” scenarios can be the most time consuming but the more you test the lower your risk of unexpected problems later. I believe that everything seems very complicated until you break it down into pieces and tackle them one by one. With these 5 steps, hopefully it will be easier for you to implement a collaborative robot. If it still seems confusing or you need any help following these general steps, please reach us at https://www.gibsonengineering.com/ or leave a comment below!
×
×
  • Create New...