Standard programmation VW with fanuc robot

  • Hello all ! :help:


    Soon on a project with fanuc or Kuka robot for Volkswagen , I would be glad if anyone has some information or written media for the programmation ( word, excel, ppt, pdf, … )



    The robots are new , for a new line.


    Anything would be nice. :guru:


    Thank you 😊 :merci:

  • HawkME

    Approved the thread.
  • Usually, car makers already have their standards for programming.

    They define program control, how tcp and frame are defined, etc….


    As i know, Fanuc is new to VW, usually they use Kuka, but since it’s no longer a German company, they look forward.


    What kind of information / tips you’re looking for ?

    If it starts well the first time, you have not checked all !

  • Exactly and each one are different. As I never work with VW car maker I don’t know what to expect.


    And I m looking for basic information about their standard with a handling robot (some .ls example, how to configure the gripper , some tips …) and gun welding point /arc welding robot ( .ls example , etc … )

    Anything that can be :smiling_face:


    Thank you

  • I found this in other threads (maybe you have seen too ?)


    By reading that, i am agree that VW must provide this information in their scope of work.

    If it starts well the first time, you have not checked all !

  • I found this in other threads (maybe you have seen too ?)


    By reading that, i am agree that VW must provide this information in their scope of work.

    Thank you


    Yes , I already saw that post. And I also agree that the VW project will provide those informations.


    But as the project didn’t start yet, I m doing quotes, I wish to have at least some information about standard (I know the fanuc robot from different project and standard)

    * Communication robot <->plc

    * Communication robot <->gripper

    or plc <->gripper

    * some example of programme *.ls to see the communication between the robot and plc ( cycle code, authorization from plc , … exchange during the trajectories

    * and so on


    Just to be little more confortable starting the project 😅

  • VW has a very strict programming standard, and (in my experience several years ago) are very bad at explaining it.


    As of 2012(?) VW was doing all their I/O by fiber-optic Interbus, and insisted that it be configured using 3rd-party software from Phoenix Contact. Running and terminating all that optical fiber was an extra pain and hassle.


    They used pneumatic servo weld guns, which I've never seen anywhere else. Hopefully they've moved away from that.


    The robot programs had pretty strict templating. Everything had be be named FolgeXXX, with XXX being a number defined by some set of rules related to the application. And every operation --zone entry, exit, close/open gripper, weld, start/end, etc-- was done by a call to a special VW macro that you often had no visibility into. There were also status "flags" that turned on background monitoring -- for example, if you picked up a part, you had to turn on a flag that monitored the part-present sensors constantly (and would fire an interrupt that halted the robot if the sensor "blipped" momentarily) until you used the part-release macro.


    Every motion program had to be programmed to a Base/User Frame that was defined by the car-body coordinate frame. This actually wasn't a bad idea, but could be a real hassle to set up. Especially with carried parts and fixed weld/adhesive/rivet tools.


    Maybe the biggest headache is VW itself -- in my experience, they've been consistently nit-picky, expect everyone to know what they want without bothering to explain anything, and entirely unreasonable. For example, the factory wasn't done -- no power, no roof, no bathrooms, but VW insisted that the machines run (at our expense) test metal by the date in the contract. After insisting that all the automation be shipped to the (unfinished!) factory as per the schedule. Apparently, in VW's universe, the fact that VW's building doesn't have roof, water, or power, is no excuse to not have the production lines running.

  • Every motion program had to be programmed to a Base/User Frame that was defined by the car-body coordinate frame. This actually wasn't a bad idea, but could be a real hassle to set up. Especially with carried parts and fixed weld/adhesive/rivet tools.

    This is very common on other car manufacturers if you are welding or gluing the whole car, it's very usseful to people who need to check the point location on the real car vs the 3d assembly.


    Problem with this is when they enforce you to have a TCP with the car coordinate frame that is used with a remote tcp and you are not allowed to change to any other tcp on normal motion (pick and place)... trust me, some enforce to do it this way.


    Robot runs slower due to the interpolation and if your tcp is at 3 metters from the flange it is really noticeable... changing the tcp you are using to a pilot of the gripper in this case make the robot move way faster.


    This is not only a fanuc issue as it also happens on abb, and you can notice it more if you run the robot at 25% speed, you will see that after the frame and tool are changed to normal ones robot motion will suddenly be accelerated.

    Another problem you have with this tcps is that reorientation speed is limited when in T1 and because it thinks the gripper is 3m long robot moves very slow and it's very frustrating.

Advertising from our partners