3rd party software

  • Hey everybody,


    I had a general question about the different types of software you’ve used on all the major robot brands, I’m a computer engineering student with a focus in intelligent systems; seeing as I work with robots, I think building some-type of third-party software to integrate on a fanuc or something would be cool for a project.


    It can be any type of software vision/process monitoring, frame calibration, etc. I’m already familiar with the different OLP softwares, I’m thinking more application focused.


    Also, I’ve heard a lot about this thing called “car 0,” I know this has something to do with frames, but I was wondering if somebody could explain to me better what it is.

  • Place your Ad here!
  • I had a general question about the different types of software you’ve used on all the major robot brands

    "On" is a bit vague. Most robots can only execute code in their own programming language, or option packages built and sold by the robot manufacturer. There are a few 3rd-party tools out there, but they're usually either from the robot manufacturer's technology partners, or are "no warranty, use at own risk" types of thing.

    OrangeApps.de sells 3rd-party software that executes on KUKA robots, but I suspect they have some sort of business relationship with KUKA. Then there's OpenShowVar, which falls into the "use at own risk" category. Without massive resources, it's impossible to achieve the level of testing and certification that manufacturers like KUKA put into their option packages.


    Since KUKAbots give you access to the Windows environment, it's possible to write Windows programs that will run in the Windows half of the robot's brain. But it would be easy to write a program that created some sort of resource conflict with the KUKA user interface, or even the realtime VxWorks side of the robot's brain (again, "use at your own risk").


    I once wrote a Windows script that would run on a KRC4, emulate the user's fingers pushing buttons to trigger a backup of the robot, then locate the new backup on the robot's hard drive and rename it with the date and time. It worked pretty well, but it was small and didn't try doing anything resource-intensive.


    Now, if we're talking about software that executes outside the robot, but connects to the robot in some fashion, there's a lot out there. Since most Windows/Mac/Linux environments don't support industrial Fieldbusses (Ethernet/IP, ProfiNet, EtherCat, etc) without buying expensive licensed drivers (there are some open-source implementations of some of them), this 3rd-party software will often use ModBus/TCP, OPC-UA, or plain old TCP/IP socket communications, depending on what the robot can support, because those protocols are better supported on the "IT side".

    Also, I’ve heard a lot about this thing called “car 0,” I know this has something to do with frames, but I was wondering if somebody could explain to me better what it is.

    Robots move to positions in space that are defined relative to a reference frame. The default reference frame (variously World, Base 0, UFrame 0, Work Object 0, etc) is usually located in or near the center of the robot base. But it's possible to define additional reference frames in the robot, as offsets from the robot's World frame.


    Imagine a situation where two robots are on opposite side of a car, spot-welding it. With the two robots facing each other, their respective World frames are 180deg opposed. This means that to move a weld towards the front of the car, one robot would have to shift in it's World Y+ direction, but the other robot would have to shift in Y-. If one robot is mounted to the floor and another to the ceiling, or if they're mounted at odd angles to each other, the problem gets even worse.


    But if you create a reference frame, "Car 0", on each robot, located at the same point and in the same orientation, then program the spot-welds relative to Car 0 instead of World, then the reference frame being used by both robots are aligned.


    This is especially helpful because quality control inspections on these spot welds will usually take place in a completely different department, that does everything in the Car 0 coordinate system. So if they issue a directive that a particular weld is off position by 5.3mm in X+ and 2.1mm in Z-, those numbers are going to be in the Car 0 coordinate system. So if the robot was originally set up to use Car 0, that makes it much easier on the robot technician to fix the weld position, without having to sit down and try doing 6DOF conversions with Cartesian coordinate and Euler rotations. Setting up Car 0 in the robot does all that math for you implicitly, "under the hood."

  • "On" is a bit vague. Most robots can only execute code in their own programming language, or option packages built and sold by the robot manufacturer. There are a few 3rd-party tools out there, but they're usually either from the robot manufacturer's technology partners, or are "no warranty, use at own risk" types of thing.

    OrangeApps.de sells 3rd-party software that executes on KUKA robots, but I suspect they have some sort of business relationship with KUKA. Then there's OpenShowVar, which falls into the "use at own risk" category. Without massive resources, it's impossible to achieve the level of testing and certification that manufacturers like KUKA put into their option packages.

    First of all, thank you for taking the time to give a thoughtful reply; I should have clarified better, I’m more interested in building like application specific software such as coherix, perceptron, and things of that nature, or even like building the ArcTool and DispenseTool sort of software. I’d really to get into vision work as well, unfortunately my company only does lasers, since I’m the robot guy I do all the robotic applications, mainly remote laser welding but also Brazing and cutting. I think vision would really be a good stamp on my resume, both being able to build the software and integrating it into a system. I’m doing my bachelors in computer engineering right now, I really love computer programming, but I also love programming/engineering applications in automation. I’m trying to find a way to mesh these.

  • Thank you once again for explaining this so in depthly, as I mentioned above, I only do robotic laser applications; my boss is an expert in laser technology, mainly the laser side of it, from high-power fiber, disk, Nd:Yag, and so on and so forth. Being that he focuses on the physical side of the laser, I handle all the robot as well as scanner programming. We’re doing a on-the-fly remote laser welding job for Mercedes, from what I understand they use this car 0 frame and he wasn’t able to explain it to me; that makes sense though, I’ve seen roboguide simulations that use this frame and it’s always right at the corner of the drivers side headlight I think. This should really help with scanner welding, keeping the optic nominal with your part is crucial for not reflecting the beam, with this it should be easy to get tight seams.

  • I’m more interested in building like application specific software such as coherix, perceptron, and things of that nature, or even like building the ArcTool and DispenseTool sort of software.

    Ah. Okay, that's more like building a "library" for a robot. That's entirely doable. The trick is, you'd have to write it for each brand of robot you want to port it for, because (so far) no one has written a generic cross-platform robot programming language.


    Then there's the question of library structure. You could try building a program package for Perceptron, say, but then you start getting into the weeds: which interface? Which type of Perceptron? Robot-carried sensor or fixed sensor? Do you write each of these as a separate set of programs that have to be selected and installed for specific applications, or do you want to try creating a single "covers all Percetron models and use cases" software package?


    Then there's installation. Importing program files into most robots is pretty easy, but making an "interactive" installer program that gives the user menus to click through to set their various selections is harder. And what if your program package somehow conflicts with some other package someone else wants to also have on a particular robot?


    If you are creating this for use in a single company, you can (hopefully) create a standard template (reserved I/O ranges, register resources, etc) that prevent conflicts and overlaps, and avoid the hassle of writing a piece of software that tries to be all possible things to all possible users in all possible use cases, which is serious pain. Don't ask me how I know this.


    Interfacing and bulletproofing are a Big Deal when creating even simple "library" packages. You want to think from the beginning about how other people's programs will interact with yours -- how they will ask your Perceptron library (for example) to take a specific measurement, and how the results are passed back up the chain. Also, what happens if someone's program sends completely random data to your library -- a library needs to fail safely, hopefully gracefully and without crashing/stopping, and pass back an indication of the issue so that the higher-level programs can react appropriately (even if the appropriate reaction is just "go Home and yell for help"). In my experience, 25-30% of my code is actually getting the job done, and the remainder is error handling, error proofing, and user-interaction code.


    And documentation. The most boring and aggravating part of writing any standard code library. But absolutely vital, if you want your code to usable by people other than yourself. Heavily commented code is good, but you need documentation that includes "quickstart" checklists (follow these steps, push these buttons, and your install and setup will work), reference details (each variable in this library, what they do, what their allowable limits are, what each subroutine does), and "philosophy" (this is how this code works in general, why it's written the way it is, and this is the general software design pattern adhered to throughout).

  • I’ve seen roboguide simulations that use this frame and it’s always right at the corner of the drivers side headlight I think.

    It depends on the manufacturer. Ford, GM, and Chrysler, IIRC, locate Car 0 in the center of the front structural member of the engine compartment. Boeing, OTOH, usually locates it at the nosewheel of the landing gear. And the orientation isn't universally standard either, although most I've seen have X+ along the length of the vehicle, and Z+ pointing "up" when the vehicle is resting on its wheels.


    The critical thing is to know where Car 0 is relative to your robot's World frame, in 6DOF (XYZRxRyRz). Setting it up in simulation (like RoboGuide) is a very good start, but often the real-world build of the station is never quite exact to the 3D model. So having some kind of measurable reference points on the car body in your station, that you can use to fine-tune the relationship between Robot World and Car 0, is an important item in the design stage of a station. Especially for stations that may only have part of the car -- if all you have is the rear structure, Car 0 is probably 3-4 meters away, and there's no physical point you can "touch off".


    This is where indirect referencing is useful (on Fanuc, it's the 4-point method). Let's say your station hardware has several high-precision locator pins that hold the car part in place. Your 3D model should be able to produce precise coordinates for the tip of each pin, relative to Car 0. By using 4 of these reference points, and touching off on them with a pointer tool on the robot, the robot can reverse-engineer where Car 0 is from the relationship between where each of those points is relative to World, and where they are relative to Car 0 (which you need to type in during the frame setup process).

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now

Advertising from our partners