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

typical pcscan time

  • brian.b
  • October 21, 2020 at 8:02 PM
  • Thread is Unresolved
  • brian.b
    Reactions Received
    7
    Trophies
    4
    Posts
    49
    • October 21, 2020 at 8:02 PM
    • #1

    What is a typical/default pcscan time? Does it depend on the complexity of the pc program or the purpose behind the program?

    I'm receiving offset values from my PLC and putting them into variables for my material handling program to apply offsets at my pick position. Does a time of 0.2 seam reasonable, more/less?

    Thanks,

    Images

    • pasted-from-clipboard.png
      • 16.22 kB
      • 463 × 598
      • 9
  • kwakisaki
    Reactions Received
    694
    Trophies
    11
    Posts
    4,766
    • October 21, 2020 at 11:59 PM
    • Best Answer
    • #2

    Good question that.......???

    I cannot remember what the default scan time is and also I don't know just how long it takes to process, execute the non motion instruction.

    I do know many factors can influence it as I think as far as the CPU 'tick' rate is, the PC Tasking is the lowest priority.

    - ie in cases I have seen the IF Panel sometimes is 'slow' to update/refresh values due to the priority.

    The example in the manual just shows a simple IF/ELSE/END toggling an output ON/OFF every second without the requirement of using wait/utimers etc.

    With AS having a whole host of additional instructions though, the example could be accomplished by using these without using a scan time to control them and I think a lot of programmers may overlook scan times then.

    I know a lot of tasks I've done, I've just stuck a 0.5 value in for smarts and no other particular reason at all.

    I do however recommend using a value (as a good practice) as a PC Task can be:

    - Used as a one shot program.

    - Cyclic program.

    - If you are 'handshaking/echoing' between peripherals, then the scan time isn't really a necessity in my opinion.

    In cases where you are just 'listening/processing/executing and then listening again, then I would recommend a scan time value to prevent:

    - The task from running 'ahead' and end up getting the same results more than once.

    - The task from running 'behind' and you end up missing a result.

    So in cases where synchronizing with external peripherals is required then the only thing I could suggest is just what is the duty cycle requirement of the PC Task required to process the information before the next set of values are received - ie at what rate the information is coming in.

    If you cannot 'handshake', then a scan time is probably required.

    Personally, anything between 0.2 and 0.5 would be sufficient enough in most circumstances though.

    View my channel at Industrial Robotics Consultancy Limited - YouTube

  • brian.b
    Reactions Received
    7
    Trophies
    4
    Posts
    49
    • October 22, 2020 at 12:14 AM
    • #3

    We originally started at 0.2 and then changed it to 0.1 and then to 0.05 just to see if this would hurt or help us. We didn't have any issues at this point and I'm comfortable in saying that each robot is getting its information from the PLC when it needs to. So I plan on keeping it at 0.05 for the time being.

    Maybe I am 'handshaking/echoing and my scan time isn't a factor at this point.

    Thanks for your help!

  • kwakisaki
    Reactions Received
    694
    Trophies
    11
    Posts
    4,766
    • October 22, 2020 at 5:21 PM
    • #4

    I would only ever consider adjusting if it is causing a problem.

    It is similar to robot getting back in time to pick next part before it is automatically rejected as the robot is too slow (if application is setup like it).

    If you need to sync scan time with process, then do so, otherwise no need.

    If it isn't broke, don't fix it......

    View my channel at Industrial Robotics Consultancy Limited - YouTube

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