Refresh rate of system variables/bg logic loop

  • Hi.


    I am working with a cell with a robot + sensor that takes measures on a workpiece, but I am experiencing a problem:


    Connected to the plc there is a laser sensor that reports a distance reading all the time though profinet (robot is also connected through profinet), the robot grips a part, moves it to the sensor an start rotating the workpiece it while the PLC catches the data from the sensor and the robot current Z angle with the selected UFrame, the purpose is to detect a hole and get the Z angle in order to do some more operations.


    A little time before starting the rotation, there is a secondary task launched with a RUN that takes the value from the variable $SV_INFO[1].$CART_POS_UF[6], multiplies the angle x100 and sends the position though a GO, but I am taking a lot of readings on the plc side with the same angle repeated every scan cycle.


    It seems the sensor is providing data every 2ms, but the robot is executing the other task or the variable or GO is only updating on a 10 to 20ms interval (maybe the io board is limiting the data transfer?)


    Do you guys know if there is a way to give highter priority to a task? I know this can be done on bglogic but I don't know the diference betwheen Normal and High priority, if bglogic is faster than a task called from a run statement I can switch the method of data capture. The task only has like 8 instructions and no math other than a multiplication is done so it should be pretty fast to execute.


    PLC is taking readings with a cyclic interrupt to ensure all data is catched and saved every 2ms, I have recorded the data of all the process on a DB and as I've said, there are a lot of different readings on the sensor part, even from previous scan to next data varies slightly, but the data from the robot is repeated around 5/10 cycles of the cyclic interrupt.


    I think my problem is caused by the task not being executed fast ennough, so any advice will be appreciated. Thanks.

  • Place your Ad here!
  • The scan time of a BG Logic task in Normal-Level mode has no maximum. Running a BG Logic Task in High-Level mode has a guaranteed scan time of 8 ms (but there are some restrictions, e.g. number of items, etc.). See here and/or check the basic operation manual for detailed information.

  • The scan time of a BG Logic task in Normal-Level mode has no maximum. Running a BG Logic Task in High-Level mode has a guaranteed scan time of 8 ms (but there are some restrictions, e.g. number of items, etc.). See here and/or check the basic operation manual for detailed information.

    Thank you, I am used to do programs in bglogic, I use it on almost all of the applications.


    If the minimum loop time is 8ms on high priority I hope it will be ennough as it will reduce the repeated readings to 4/5 capture points, I will port the logic of that RUN call to a bglogic task as the only thing it does right now is checking for a DO and sending the current position the whole time that DO is true until that DO is false again, on that moment the loop ends and the function ends his execution until is called next time.


    I have read somewhere on this forum that on some controllers the execution time can be lower, like 4ms and even 2ms but I've not found any oficial documentation that says that...


    The better the refresh rate, the best, since I can speed up the rotation of the workpiece in order to get better cycletime if needed (that is not a priority right now, as I need to locate the angle preciselly, but giood to know), another problem I face is that I do not really know how fast communication can be over the profinet interface as it uses a siemens board to communicate with the PLC.


    I've done the best I can to ensure fast execution on the PLC side managing all data with a cyclic interrupt to ensure not to be affected by the current scan time of the PLC, a little delay betwheen the robot output position and the sensor readings is expected, but I need the maximum repeteability I can achieve.

  • I have read somewhere on this forum that on some controllers the execution time can be lower, like 4ms and even 2ms but I've not found any oficial documentation that says that...

    I've also read a thread discussing this topic. But unfortunately I can't find it anymore...


    As far as I know the IPO time of the controller generations differ. If I remember correctly the IPO time of the R-30iB Plus is 4 ms. R-30iB and even older generations are probably slower.


    But I'm not sure if the BG Logic scan time also improved. I don't believe so because when looking at the BG Logic menu the scan time is still 8 ms.

  • Also consider the IO cycle update time when using PROFINET.

    Regarding that matter, I don't know how to check this.

    I know for sure the sensor is providing me with new data on the PLC side every 2ms at minimum, as I've stored data readings every 2ms and every cycle I get a slightly different reading.


    But on the robot I have not clue... since I have repeating data values on various cycles, in theory running a cyclic interrupt on the PLC should make a I/O image of the Input/output areas I access, this seems to work with the data from the sensor but I have not clue if the PLC is not updating I/O received from the robot fast ennough, if the robot IO cycle update is not fast ennough, or if the problem is that the bglogic/parallel task is slow and cannot copy the values from SV_INFO fast ennough to the GO I use to transfer the data.


    Controller is almost new, so it should have the latest software version, or at least, a very few months old build.

  • Are you using a Siemens PLC? In TIA Portal open the hardware configuration and select the PROFINET interface of your robot. The update time can be found under Advanced options > Real time settings > IO cycle. The update time is often set to automatically calculated. But one can also set the Update time manually. Use the integrated help function of your engineering tool to get detailed information about the update time.


    It should be the same or at least very similar in STEP 7 Classic.


    Depending on the value set for the update time you could try again with smaller values.


    I assume what you see ist a combination of the BG Logic scan time, IO cycle update time and other (internal) processing as well as communication times/delays.

  • Yeah, its a siemens S1511, i/o cycle update time was already configured at 2ms on the robot gsd device and hardware configuration was uploaded a few days ago to plc, so problem probably is on the parallel task execution time, I will move the code to a BGtask with high priority and check if anything improves over the run call.


    Thanks for your help.

  • For anyone interested, I've not noticed any diference changing the routine logic to be executed with the RUN or the BGlogic, what seemed to make a diference was to handle all the calculations on the robot side, making the PLC a mere passtrought.


    I've handled the data on PLC side with a OB30 (cyclic interrupt) so the sensor data is transfered every 1ms to the robot. Robot still updates his I/O at a more slow rate but at least now data only comes with a fixed delay and I can ensure I am capturing the data at a fixed rate instead of adding all the random delays toguether caused by the PLC scan time and the tick rate from the bglogic + i/o communciation.


    The data capture is handled on the BGLogic program with high priority.

    The problem was not elliminated, but was reduced a lot.



    Now, I want to ask a question, this robot has a Siemens card, the ones where you need to create a PLC project and load the card configuration and then export the GSD to load into the PLC hardware... anyone knows if the card can be configured to be faster regarding I/O communication? Like enabling RT or IRT behaviour.

    I need to have the most accuracy I can get, but that will not be possible if the sensor refresh his values at 2ms and robot at 20ms... on 20ms robot already has turned the workpiece more than 0.5º, and with the tolerances I am working this is a problem... I think this can work correctly if at least the only bottleneck is the 8ms scan from the BGLogic.


    Thanks.

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