typical pcscan time

    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.

    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!

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

Advertising from our partners