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. Fanuc 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

Dynamic control of FANUC Robot in Run-Time

  • Gokul N A
  • July 3, 2019 at 10:39 AM
  • Thread is Resolved
  • Gokul N A
    Trophies
    3
    Posts
    4
    • July 3, 2019 at 10:39 AM
    • #1

    We are working on a vision system that enables industrial robots to understand orientations of complex geometry objects in 3D space and dynamically control a robot arm to be able to pick, orient and accurately place the objects, and adjust to variations while picking and placing in real-time as guided by the vision system.

    For our requirement, we will have a camera connector to a remote GPU based powerful PC which will also send the position commands to the FANUC robot. There will be no set manual configuration of the Robotic Arm and all the control will be done real-time & during runtime by the Machine Learning Code running on the Remote PC. So while we are developing the code, there are lot of possibilities for the Robot to go haywire due to bugs. White at the same time, we need that amount of freedom for an independent program to be able to take control of the robotic arm's movements.

    At some cases, this might require continuous streaming of robot coordinates (like placing the component into a die and its not getting placed properly and it needs to adjust, positioning screws, etc) and we want to understand the possibility of the same with FANUC robot. Especially the loop rate. Unfortunately, we are placed in India and we are not able to gather much of the needed data from FANUC india and they are unresponsive.

    Questions:
    1. What are the communication protocols available for us to communicate the Position and motion setpoints/co-ordinates to the FANUC controller?
    With PC communication through TCP/IP, what is the rate at which we can update coordinates to the robot controller?
    Ethernet-IP communication is feasible? If yes, is the speed of communication better than TCP-IP scanning rates for FANUC? What is the scanning Rate for TCP and Ethernet-IP?

    2. Are there the APIs/Methods available for us to programmatically control the FANUC robot by talking to the controller, remotely from our PC? (I understand that there is karel programming to be deployed into Controller but is there any lapse of movement functions that limit us from doing a particular type of movement using robot when giving dynamic commands vs when a TP based predetermined paths are executed?)

    3. What is the rate at which we can update the motion setpoints or co-ordinates? For eg: Lets say the Robot was asked to move from Point 1 to point 2 at 0.5 metres/second speed.. While it was moving, lets say, the code wants to change direction and wants to move to point3. Within how much time will the control change its path when a new setpoint is given? Otherwise what is the Robot’s Response time to Setpoints? Universal robots for example in its e-series says 120 Hz. Which means I can send 120 different setpoints within a second and robot will respond to it.

    4. The rate of response for queries on the FANUC robots coordinates and other internal & process data?
    If coordinate set-points cannot be updated in run-time, can we execute a stop command while the robot is in motion, rewrite the coordinates and then restart the motion with the new trajectory? How fast can this action be executed?
    After sending of commands from PC, what is the response time for the robot to begin executing the command?


    5. Can you share the possibility of obtaining training for Karel programming and advanced robot programming?

    Thanks in advance,
    - Gokul

  • Go to Best Answer
  • pdl
    Reactions Received
    266
    Trophies
    9
    Posts
    1,506
    • July 3, 2019 at 12:53 PM
    • #2

    You should talk to Fanuc about PCDK and DPM.

    PCDK is their API for communication with their robots.

    DPM, or Dynamic Path Modification, allows on the fly adjustment of the robot position.

    Again, you should probably contact Fanuc directly about this. Ask to speak to one of their technical guys, not just a sales guy.

    Best of luck,

    -Phil

  • scotty
    Reactions Received
    43
    Trophies
    5
    Posts
    497
    • July 3, 2019 at 3:22 PM
    • #3
    Quote from Gokul N A

    Questions:
    1. What are the communication protocols available for us to communicate the Position and motion setpoints/co-ordinates to the FANUC controller?
    With PC communication through TCP/IP, what is the rate at which we can update coordinates to the robot controller?
    Ethernet-IP communication is feasible? If yes, is the speed of communication better than TCP-IP scanning rates for FANUC? What is the scanning Rate for TCP and Ethernet-IP?

    5. Can you share the possibility of obtaining training for Karel programming and advanced robot programming?

    Thanks in advance,
    - Gokul

    First of all I totally agree with Phil. Next:
    1. Question is what is your speed requirements. As you know Ethernet/IP communication will keep communication alive and run data all the time. from TCP side - depends which way you will go PCDK or custom. I won't recommend do custom because you will waste a lot of time just on parsing. PCDK might be you best choice on TCP side. I you will select Ethernet/IP, as you may be aware you have enough libraries that you can use on PC side to implement Ethernet/IP communication.

    5. KAREL training usually useless. You can get everything by your self pretty quick if you good in programming (Java/C#/C++/C). Advanced programming classes will give you information how to use "advanced" commands in robot TP programs. TP is different from KAREL. TP program you can write from robot teach pendant. Almost always all motion side in TP program. People use KAREL for advance things (data collection/data transfering/ network communication/data parsing/ logging/ path adjustment/ etc.). If you don't have robotics skill, I would recommend to pass basic and advance classes. What about KAREL, read first KAREL manuals and try to implement something in Roboguide, then you can make decision do you need to take the Karel course or not.

  • Gokul N A
    Trophies
    3
    Posts
    4
    • July 10, 2019 at 9:55 AM
    • #4
    Quote from pdl


    You should talk to Fanuc about PCDK and DPM.

    Again, you should probably contact Fanuc directly about this. Ask to speak to one of their technical guys, not just a sales guy.


    Hi Phil!
    The issue is that I'm not getting much response in this front from the India Sales team & there is no tech team sitting in india. Do let me know if there are any means or ways to access the relevant tech guys beside the sales channel. (Calling the general contact for America or Japan team reroutes to India)
    Regards,
    N A GOKUL

  • Gokul N A
    Trophies
    3
    Posts
    4
    • July 10, 2019 at 10:05 AM
    • #5
    Quote from scotty


    First of all I totally agree with Phil. Next:
    1. Question is what is your speed requirements. As you know Ethernet/IP communication will keep communication alive and run data all the time. from TCP side - depends which way you will go PCDK or custom. I won't recommend do custom because you will waste a lot of time just on parsing. PCDK might be you best choice on TCP side. I you will select Ethernet/IP, as you may be aware you have enough libraries that you can use on PC side to implement Ethernet/IP communication.


    Hi Scotty,
    Thanks for the detailed inputs.
    The speed requirements for path update will be 13ms, Currently. Can tolerate upto 50ms.
    Regards,
    N A Gokul

  • pdl
    Reactions Received
    266
    Trophies
    9
    Posts
    1,506
    • July 10, 2019 at 2:13 PM
    • #6

    I've only dealt with Fanuc America, but I've heard that the European guys can be helpful.

    DPM should be able to update at the ITP scan time, which for the R30iB+ is now 4ms, on older robots it was 8ms.

  • 05032MendicantBias
    Reactions Received
    2
    Trophies
    3
    Posts
    7
    • July 10, 2019 at 6:37 PM
    • #7
    Quote from pdl


    DPM should be able to update at the ITP scan time, which for the R30iB+ is now 4ms, on older robots it was 8ms.


    I have an R30iB+ and I only get 8ms ITP. I only get 2ms on special things like the high speed input for line tracking option.

  • HawkME
    Reactions Received
    568
    Trophies
    10
    Posts
    3,268
    • July 10, 2019 at 7:26 PM
    • #8

    In addition to the ITP time you would have to consider the communication time. For example with EthernetIP I believe the minimum RPI is 8ms.

  • Online
    Lemster68
    Reactions Received
    295
    Trophies
    9
    Posts
    2,454
    Blog Articles
    7
    • July 10, 2019 at 8:09 PM
    • #9

    Have you checked out ROS?

  • rf103
    Reactions Received
    17
    Trophies
    4
    Posts
    264
    • July 10, 2019 at 8:56 PM
    • #10

    Are we discussing altering motions or completely externally controlling motions?

    The former can be done with DPM, the latter would need a different option.

    And latency is certainly something you would need to account for: I believe the DPM manual specifies a 5 * ITP delay.

  • arikrundquist
    Reactions Received
    7
    Trophies
    3
    Posts
    69
    • July 12, 2019 at 8:11 PM
    • Best Answer
    • #11
    Quote


    1. What are the communication protocols available for us to communicate the Position and motion setpoints/co-ordinates to the FANUC controller?
    With PC communication through TCP/IP, what is the rate at which we can update coordinates to the robot controller?
    Ethernet-IP communication is feasible? If yes, is the speed of communication better than TCP-IP scanning rates for FANUC? What is the scanning Rate for TCP and Ethernet-IP?


    You have three choices for sending positions to the robot: DPM (software package), Stream Motion (software package), and Socket Messaging (uses KAREL and TCP).
    If all of your pick and place operations are pretty much the same, DPM might be the way to go. It's designed to dynamically modify a previously taught path based on real time sensor data. However, if you want to give your machine learning algorithm more flexibility to create the path the robot follows, then you want either Stream Motion or Socket Messaging. Stream Motion is a fairly new package from Fanuc. I've used it a bit but haven't had much luck with it (frequent OS crashes, often complained about jerk or acceleration limits). Socket Messaging is essentially Fanuc's prototype of Stream Motion. It is essentially what you described -- the idea is to fill a buffer of positions using data from your controller, and then have a TP program loop through those positions. My company uses this approach for our own application -- I was doubtful that we would have the fine control we wanted over the robot, but it actually works really well. From our own experimentation, we found that using a circular buffer of three position registers with high speed and CNT values works really well. Fanuc has example programs for this, but they're more complex than they need to be and use unnecessary features that break compatibility on robots that do not have those options installed. All you really need to do is have a KAREL loop fill position registers and set an output indicating that that position is valid, and a TPP loop waiting for each position to become valid and then move there.
    The fastest you'll be able to update is every 8ms, that's a limit imposed by the controller itself. Someone mentioned a specialized software packate that ran every 2ms, but honestly you probably don't really need it that fast. Play around with the timing of your position streaming and how far apart each point is.

    Quote


    2. Are there the APIs/Methods available for us to programmatically control the FANUC robot by talking to the controller, remotely from our PC? (I understand that there is karel programming to be deployed into Controller but is there any lapse of movement functions that limit us from doing a particular type of movement using robot when giving dynamic commands vs when a TP based predetermined paths are executed?)


    Are you asking if streaming positions has all of the same capabilities as a TP program? The answer to that is probably not: since you are dynamically streaming positions, you are necessarily taking away Fanuc's ability to plan it's path. You will still have good motion, but you might not be able to do precise path planning -- for example, a TP program could move in a circle by using several Arc instructions. If you wanted to stream the same path, you might send several hundred points on that circle. However, there is no guaruntee that Fanuc will move in a perfectly circular motion (still, it would almost certainly be essentially the same path). That's the tradeoff you would be making, but I don't think you'll run into any issues because of it. As for other capabilities, it would be pretty easy to expand your system to be able to set IO, read and set system variables, etc, so in that sense you aren't losing anything.

    Quote


    3. What is the rate at which we can update the motion setpoints or co-ordinates? For eg: Lets say the Robot was asked to move from Point 1 to point 2 at 0.5 metres/second speed.. While it was moving, lets say, the code wants to change direction and wants to move to point3. Within how much time will the control change its path when a new setpoint is given? Otherwise what is the Robot’s Response time to Setpoints? Universal robots for example in its e-series says 120 Hz. Which means I can send 120 different setpoints within a second and robot will respond to it.


    The robot is pretty responsive, so if you're sending and consuming points that fast I don't anticipate you seeing significant lag. Do be aware, however, that if you're using the Socket Messaging approach, the robot may not always be right where you command it to be by the time you send your next point. It can be easy to plan a motion and stream points from that path, expecting the robot to move along the path at the same rate you sample from it -- get position feedback from the robot so that you can handle cases where you get a little ahead of it. This isn't a huge issue, but it is something you should be looking out for.

    Quote


    4. The rate of response for queries on the FANUC robots coordinates and other internal & process data?
    If coordinate set-points cannot be updated in run-time, can we execute a stop command while the robot is in motion, rewrite the coordinates and then restart the motion with the new trajectory? How fast can this action be executed?
    After sending of commands from PC, what is the response time for the robot to begin executing the command?


    This is not the way you want to go. This is going to be significantly slower and have higher latency than any other method.
    You could, however, generate TPP scripts and FTP those to the robot, though I would budget a couple extra seconds for this transfer. It might be interesting to do a combination of TPP and KAREL position streaming: you could have a general TPP program that abstractly performs the task you want (eg. move towards object until the object is reached, attempt to grab object until successful, move object, attept to place object until successful), then communicates, via KAREL, with your external system to determine where to move, whether an operation was successfully completed, etc. I haven't tried that myself but it would be pretty cool if you got it working.

    Quote


    5. Can you share the possibility of obtaining training for Karel programming and advanced robot programming?


    As some of the other posts have mentioned, KAREL training isn't really necessary as long as you have the KAREL manual (having the Programming Instructions manual (for TP programs) is also helpful). There are some weird KAREL quirks that you won't find in the manual, but I doubt you'd learn about them in a training; you just have to pinpoint the issue yourself and then be conscious of it going forward. For example, yesterday and today I was struggling with a stack overflow error, even though my call stack was only three routines deep. Turns out, it was an issue with KAREL trying to pass robot IO values by reference to my routine. I'm still not even sure what the robot thought it was doing, but forcing the IO to be passed by value fixed the issue. My point is, KAREL isn't that difficult of a langauge and can easily be learned without training, and any issues you run into would probably not even be in any training you take.
    Still, if you own a robot, it's pretty easy to get TP programming training from the customer portal.

  • Gokul N A
    Trophies
    3
    Posts
    4
    • July 19, 2019 at 5:43 PM
    • #12
    Quote from Lemster68


    Have you checked out ROS?


    Is there an advantage in terms of using the ROS with FANUC in relevance to the questions that I have asked and does FANUC officially support ROS?

  • Online
    Lemster68
    Reactions Received
    295
    Trophies
    9
    Posts
    2,454
    Blog Articles
    7
    • July 19, 2019 at 5:48 PM
    • #13

    Sorry, I don't have an answer for either question. I was just trying to throw that in there as a possible solution for what you are asking. You can look at their wiki or github to see what you think, get more information, or even query them with your questions.

  • sunbuny
    Trophies
    3
    Posts
    1
    • October 30, 2019 at 5:48 PM
    • #14
    Quote from just_learning_KRL


    You have three choices for sending positions to the robot: DPM (software package), Stream Motion (software package), and Socket Messaging (uses KAREL and TCP).
    If all of your pick and place operations are pretty much the same, DPM might be the way to go. It's designed to dynamically modify a previously taught path based on real time sensor data. However, if you want to give your machine learning algorithm more flexibility to create the path the robot follows, then you want either Stream Motion or Socket Messaging. Stream Motion is a fairly new package from Fanuc. I've used it a bit but haven't had much luck with it (frequent OS crashes, often complained about jerk or acceleration limits). Socket Messaging is essentially Fanuc's prototype of Stream Motion. It is essentially what you described -- the idea is to fill a buffer of positions using data from your controller, and then have a TP program loop through those positions. My company uses this approach for our own application -- I was doubtful that we would have the fine control we wanted over the robot, but it actually works really well. From our own experimentation, we found that using a circular buffer of three position registers with high speed and CNT values works really well. Fanuc has example programs for this, but they're more complex than they need to be and use unnecessary features that break compatibility on robots that do not have those options installed. All you really need to do is have a KAREL loop fill position registers and set an output indicating that that position is valid, and a TPP loop waiting for each position to become valid and then move there.
    The fastest you'll be able to update is every 8ms, that's a limit imposed by the controller itself. Someone mentioned a specialized software packate that ran every 2ms, but honestly you probably don't really need it that fast. Play around with the timing of your position streaming and how far apart each point is.


    Are you asking if streaming positions has all of the same capabilities as a TP program? The answer to that is probably not: since you are dynamically streaming positions, you are necessarily taking away Fanuc's ability to plan it's path. You will still have good motion, but you might not be able to do precise path planning -- for example, a TP program could move in a circle by using several Arc instructions. If you wanted to stream the same path, you might send several hundred points on that circle. However, there is no guaruntee that Fanuc will move in a perfectly circular motion (still, it would almost certainly be essentially the same path). That's the tradeoff you would be making, but I don't think you'll run into any issues because of it. As for other capabilities, it would be pretty easy to expand your system to be able to set IO, read and set system variables, etc, so in that sense you aren't losing anything.


    The robot is pretty responsive, so if you're sending and consuming points that fast I don't anticipate you seeing significant lag. Do be aware, however, that if you're using the Socket Messaging approach, the robot may not always be right where you command it to be by the time you send your next point. It can be easy to plan a motion and stream points from that path, expecting the robot to move along the path at the same rate you sample from it -- get position feedback from the robot so that you can handle cases where you get a little ahead of it. This isn't a huge issue, but it is something you should be looking out for.


    This is not the way you want to go. This is going to be significantly slower and have higher latency than any other method.
    You could, however, generate TPP scripts and FTP those to the robot, though I would budget a couple extra seconds for this transfer. It might be interesting to do a combination of TPP and KAREL position streaming: you could have a general TPP program that abstractly performs the task you want (eg. move towards object until the object is reached, attempt to grab object until successful, move object, attept to place object until successful), then communicates, via KAREL, with your external system to determine where to move, whether an operation was successfully completed, etc. I haven't tried that myself but it would be pretty cool if you got it working.


    As some of the other posts have mentioned, KAREL training isn't really necessary as long as you have the KAREL manual (having the Programming Instructions manual (for TP programs) is also helpful). There are some weird KAREL quirks that you won't find in the manual, but I doubt you'd learn about them in a training; you just have to pinpoint the issue yourself and then be conscious of it going forward. For example, yesterday and today I was struggling with a stack overflow error, even though my call stack was only three routines deep. Turns out, it was an issue with KAREL trying to pass robot IO values by reference to my routine. I'm still not even sure what the robot thought it was doing, but forcing the IO to be passed by value fixed the issue. My point is, KAREL isn't that difficult of a langauge and can easily be learned without training, and any issues you run into would probably not even be in any training you take.
    Still, if you own a robot, it's pretty easy to get TP programming training from the customer portal.

    Display More

    I am very curious about how to implement a ring buffer. Do you have sample code?

  • Jonson
    Reactions Received
    2
    Trophies
    4
    Posts
    211
    • November 12, 2019 at 1:40 AM
    • #15
    Quote from just_learning_KRL


    You have three choices for sending positions to the robot: DPM (software package), Stream Motion (software package), and Socket Messaging (uses KAREL and TCP).
    If all of your pick and place operations are pretty much the same, DPM might be the way to go. It's designed to dynamically modify a previously taught path based on real time sensor data. However, if you want to give your machine learning algorithm more flexibility to create the path the robot follows, then you want either Stream Motion or Socket Messaging. Stream Motion is a fairly new package from Fanuc. I've used it a bit but haven't had much luck with it (frequent OS crashes, often complained about jerk or acceleration limits). Socket Messaging is essentially Fanuc's prototype of Stream Motion. It is essentially what you described -- the idea is to fill a buffer of positions using data from your controller, and then have a TP program loop through those positions. My company uses this approach for our own application -- I was doubtful that we would have the fine control we wanted over the robot, but it actually works really well. From our own experimentation, we found that using a circular buffer of three position registers with high speed and CNT values works really well. Fanuc has example programs for this, but they're more complex than they need to be and use unnecessary features that break compatibility on robots that do not have those options installed. All you really need to do is have a KAREL loop fill position registers and set an output indicating that that position is valid, and a TPP loop waiting for each position to become valid and then move there.
    The fastest you'll be able to update is every 8ms, that's a limit imposed by the controller itself. Someone mentioned a specialized software packate that ran every 2ms, but honestly you probably don't really need it that fast. Play around with the timing of your position streaming and how far apart each point is.


    Are you asking if streaming positions has all of the same capabilities as a TP program? The answer to that is probably not: since you are dynamically streaming positions, you are necessarily taking away Fanuc's ability to plan it's path. You will still have good motion, but you might not be able to do precise path planning -- for example, a TP program could move in a circle by using several Arc instructions. If you wanted to stream the same path, you might send several hundred points on that circle. However, there is no guaruntee that Fanuc will move in a perfectly circular motion (still, it would almost certainly be essentially the same path). That's the tradeoff you would be making, but I don't think you'll run into any issues because of it. As for other capabilities, it would be pretty easy to expand your system to be able to set IO, read and set system variables, etc, so in that sense you aren't losing anything.


    The robot is pretty responsive, so if you're sending and consuming points that fast I don't anticipate you seeing significant lag. Do be aware, however, that if you're using the Socket Messaging approach, the robot may not always be right where you command it to be by the time you send your next point. It can be easy to plan a motion and stream points from that path, expecting the robot to move along the path at the same rate you sample from it -- get position feedback from the robot so that you can handle cases where you get a little ahead of it. This isn't a huge issue, but it is something you should be looking out for.


    This is not the way you want to go. This is going to be significantly slower and have higher latency than any other method.
    You could, however, generate TPP scripts and FTP those to the robot, though I would budget a couple extra seconds for this transfer. It might be interesting to do a combination of TPP and KAREL position streaming: you could have a general TPP program that abstractly performs the task you want (eg. move towards object until the object is reached, attempt to grab object until successful, move object, attept to place object until successful), then communicates, via KAREL, with your external system to determine where to move, whether an operation was successfully completed, etc. I haven't tried that myself but it would be pretty cool if you got it working.


    As some of the other posts have mentioned, KAREL training isn't really necessary as long as you have the KAREL manual (having the Programming Instructions manual (for TP programs) is also helpful). There are some weird KAREL quirks that you won't find in the manual, but I doubt you'd learn about them in a training; you just have to pinpoint the issue yourself and then be conscious of it going forward. For example, yesterday and today I was struggling with a stack overflow error, even though my call stack was only three routines deep. Turns out, it was an issue with KAREL trying to pass robot IO values by reference to my routine. I'm still not even sure what the robot thought it was doing, but forcing the IO to be passed by value fixed the issue. My point is, KAREL isn't that difficult of a langauge and can easily be learned without training, and any issues you run into would probably not even be in any training you take.
    Still, if you own a robot, it's pretty easy to get TP programming training from the customer portal.

    Display More

    Is there more detail about the stream motion software?

    Thank you.

  • lemon132
    Reactions Received
    2
    Trophies
    2
    Posts
    14
    • May 2, 2022 at 10:01 AM
    • #16
    Quote from arikrundquist


    You have three choices for sending positions to the robot: DPM (software package), Stream Motion (software package), and Socket Messaging (uses KAREL and TCP).
    If all of your pick and place operations are pretty much the same, DPM might be the way to go. It's designed to dynamically modify a previously taught path based on real time sensor data. However, if you want to give your machine learning algorithm more flexibility to create the path the robot follows, then you want either Stream Motion or Socket Messaging. Stream Motion is a fairly new package from Fanuc. I've used it a bit but haven't had much luck with it (frequent OS crashes, often complained about jerk or acceleration limits). Socket Messaging is essentially Fanuc's prototype of Stream Motion. It is essentially what you described -- the idea is to fill a buffer of positions using data from your controller, and then have a TP program loop through those positions. My company uses this approach for our own application -- I was doubtful that we would have the fine control we wanted over the robot, but it actually works really well. From our own experimentation, we found that using a circular buffer of three position registers with high speed and CNT values works really well. Fanuc has example programs for this, but they're more complex than they need to be and use unnecessary features that break compatibility on robots that do not have those options installed. All you really need to do is have a KAREL loop fill position registers and set an output indicating that that position is valid, and a TPP loop waiting for each position to become valid and then move there.
    The fastest you'll be able to update is every 8ms, that's a limit imposed by the controller itself. Someone mentioned a specialized software packate that ran every 2ms, but honestly you probably don't really need it that fast. Play around with the timing of your position streaming and how far apart each point is.


    Are you asking if streaming positions has all of the same capabilities as a TP program? The answer to that is probably not: since you are dynamically streaming positions, you are necessarily taking away Fanuc's ability to plan it's path. You will still have good motion, but you might not be able to do precise path planning -- for example, a TP program could move in a circle by using several Arc instructions. If you wanted to stream the same path, you might send several hundred points on that circle. However, there is no guaruntee that Fanuc will move in a perfectly circular motion (still, it would almost certainly be essentially the same path). That's the tradeoff you would be making, but I don't think you'll run into any issues because of it. As for other capabilities, it would be pretty easy to expand your system to be able to set IO, read and set system variables, etc, so in that sense you aren't losing anything.


    The robot is pretty responsive, so if you're sending and consuming points that fast I don't anticipate you seeing significant lag. Do be aware, however, that if you're using the Socket Messaging approach, the robot may not always be right where you command it to be by the time you send your next point. It can be easy to plan a motion and stream points from that path, expecting the robot to move along the path at the same rate you sample from it -- get position feedback from the robot so that you can handle cases where you get a little ahead of it. This isn't a huge issue, but it is something you should be looking out for.


    This is not the way you want to go. This is going to be significantly slower and have higher latency than any other method.
    You could, however, generate TPP scripts and FTP those to the robot, though I would budget a couple extra seconds for this transfer. It might be interesting to do a combination of TPP and KAREL position streaming: you could have a general TPP program that abstractly performs the task you want (eg. move towards object until the object is reached, attempt to grab object until successful, move object, attept to place object until successful), then communicates, via KAREL, with your external system to determine where to move, whether an operation was successfully completed, etc. I haven't tried that myself but it would be pretty cool if you got it working.


    As some of the other posts have mentioned, KAREL training isn't really necessary as long as you have the KAREL manual (having the Programming Instructions manual (for TP programs) is also helpful). There are some weird KAREL quirks that you won't find in the manual, but I doubt you'd learn about them in a training; you just have to pinpoint the issue yourself and then be conscious of it going forward. For example, yesterday and today I was struggling with a stack overflow error, even though my call stack was only three routines deep. Turns out, it was an issue with KAREL trying to pass robot IO values by reference to my routine. I'm still not even sure what the robot thought it was doing, but forcing the IO to be passed by value fixed the issue. My point is, KAREL isn't that difficult of a langauge and can easily be learned without training, and any issues you run into would probably not even be in any training you take.
    Still, if you own a robot, it's pretty easy to get TP programming training from the customer portal.

    Display More

    I'm currently implementing the same approach but i'm having problems with cnt. I have to simulate the cnt trajectories in advance so my algorithm can learn on them and check for collisions. The problem is that it's difficult to find out how exactly fanuc's cnt algorithm work so i can copy it. How did you solve this problem ? Currently i am only able to send "fine" trajectories.

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
  • KRL
  • KUKA
  • motoman
  • Offset
  • PLC
  • PROFINET
  • Program
  • Programming
  • RAPID
  • robodk
  • 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
  • KRL
  • KUKA
  • motoman
  • Offset
  • PLC
  • PROFINET
  • Program
  • Programming
  • RAPID
  • robodk
  • 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