Optimizing my submit program

  • Hello,


    I am currently using a KR8 R1420HW (KRC4 with KSS 8.3.34) for a university project where I map $VEL_ACT to a Beckhoff Stepper Terminal's (EL7037) "Velocity" parameter. I have written a submit program that constantly updates the stepper motor speed based on $VEL_ACT. I would like to optimize my submit program to keep the cycle time as low as possible in order to get a more real time synchronization of the stepper with the robot. I do not have any "WAIT" commands or Interrupts in the program. I mainly use IF ELSE statements so that it only executes the code that I need, depending on the state of my end-effector at that instant.


    I have two questions regarding this:

    1. Is there a way to record and track submit cycle times? If so, how can I find any documentation on it?
    2. If I go by the default template of .sub, there is a "TORQUE_MONITORING()" function inside the loop. Can someone explain me its purpose and if its going to improve my submit cycle times drastically if I take it out?


    Any help is very appreciated as I am still an amateur when it comes to industrial robots and automation in general.

  • Place your Ad here!
  • 1. Not sure if there is an official way, but when I needed to look at average sps cycle times, I created a global bool and int variables, in program set int to 10000, started timer and interrupt when the int is <=0. In sps loop it's just: if boolv then intv=intv-1.


    2. I am pretty sure that's for collision detection. If you are in a lab setting, then maybe it's not that important, but I doubt that disabling it would reduce sub cycle times significantly. Don't know for sure, as I have never tried.


    If you are a programmer and capacity to use a different interface, then I heard something about legacy KRC Service library, which can provide read access to some system variables. Might be able to poll faster, but the additional overhead might make it even worse. An option to investigate.

  • 1. Not sure if there is an official way, but when I needed to look at average sps cycle times, I created a global bool and int variables, in program set int to 10000, started timer and interrupt when the int is <=0. In sps loop it's just: if boolv then intv=intv-1.


    2. I am pretty sure that's for collision detection. If you are in a lab setting, then maybe it's not that important, but I doubt that disabling it would reduce sub cycle times significantly. Don't know for sure, as I have never tried.


    If you are a programmer and capacity to use a different interface, then I heard something about legacy KRC Service library, which can provide read access to some system variables. Might be able to poll faster, but the additional overhead might make it even worse. An option to investigate.

    Thank you for the reply. Can you please elaborate on the cycle time point? I am not sure if I follow.


    I'll see if I can find something about the KRC Service Library. I recently found that the system variables update every 12ms. That is considerable latency in my case. So relying on $VEL_ACT might actually not work for higher robot speeds like 200 mm/s (I am currently running the machine at 50 mm/s)

  • In your Main program (the one that performs movement), declare a global int variable, let's say you name it MyCounter, assign 10000 to it,also start a timer. In sps.sub loop, add a line that would subtract 1 from the value of MyCounter. When the value of MyCounter reaches 0 or below, sps.sub loop will have repeated 10000 times. When that happens, stop the timer with an interrupt, divide the timer value by 10000 and that's more or less how many miliseconds each sps.sub cycle takes to run on average. This is less, "record and track" and more "get an approximate average".

  • do not remove TORQUE_MONITORING() from system submit.


    default template for submit contains code structure for system submit if you need to recreate it from scratch.


    if you need something done in the background, you can create new submit and delete everything in it or simply use Expert Submit. then you can add your code in there and call it from main submit or... run it as a separate task using MultiSubmit. MultiSubmit is a free option for KSS8.3.12+. In KSS8.5x it is included as standard feature.


    you can also put your code in SRC file. this allows easy testing because you can run it as robot task. when working ok, you can still link SRC file with Submit. Submit program must be file with extension SUB but it can call SRC files as subprograms.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • The KRC runs on a 12ms internal clock cycle. Which means that $VEL_ACT only updates every 12ms. So running your SPS faster than that won't do much. Also, every task in the robot gets a fixed "slice" of the 12ms "pie" -- the SPS gets about 2ms, IIRC.


    Ironically, with the current generation processors, the SPS executes at something like (IIRC) 50nanoseconds for each program line (including blank lines and comments). So even a long, complex SPS program can execute several times during a single 2ms "slice"


    If you're concerned about the time your SPS consumes, try using a $TIMER to check it. Set it to 0 at the start of the SPS loop, and save the value just before the ENDLOOP. The $TIMERs work in 12ms steps, so unless your $TIMER ever manages to reach 24ms, you're probably not taking more than one "slice" worth of time.

  • The KRC runs on a 12ms internal clock cycle. Which means that $VEL_ACT only updates every 12ms. So running your SPS faster than that won't do much. Also, every task in the robot gets a fixed "slice" of the 12ms "pie" -- the SPS gets about 2ms, IIRC.


    Ironically, with the current generation processors, the SPS executes at something like (IIRC) 50nanoseconds for each program line (including blank lines and comments). So even a long, complex SPS program can execute several times during a single 2ms "slice"


    If you're concerned about the time your SPS consumes, try using a $TIMER to check it. Set it to 0 at the start of the SPS loop, and save the value just before the ENDLOOP. The $TIMERs work in 12ms steps, so unless your $TIMER ever manages to reach 24ms, you're probably not taking more than one "slice" worth of time.

    Hello SkyeFire,

    I use a KRC4 - 8.6.4 - with profisafe + 254 bytes in & 254 bytes out.


    I figured out my SPS loop is currently running in average at ~100ms+ (using the same method you mentioned with timer to measure it).

    I also ran and measured just a part of my code, which will in theory execute about 1000 lines (including blank etc...).

    From start to end, it takes 36 to 48ms to complete! While, at 50ns per line, should require less than 0.05ms (so expected timer value of 0 to 12ms max).


    Anyway, I think my code is so simple that the problem must be coming from elsewhere.

    Is there anything that could explain that difference, or any method I could use to spot the root cause?

    Do you know where can I find a document which is describing this clock speed / task organisation?


    Just my SPS is running, no task, no TRIGGER etc.

  • not all lines of code are equal.... some may take longer to execute than others.


    programmer should always be able to determine actual time it takes to execute block of code.

    even if things are ultimately needed to run in Submit, i always put code in global subprograms.

    this gives me several things including portability and convenience when debugging:


    easy to comment out and if needed can also run it in a Robot interpreter (far more convenient to step through for example).

    maybe put it in a loop and run it 10 or 100 times and measure overall execution time,

    then divide result by number of times it looped to get more accurate answer.


    newer KSS have multisubmit - so why not use it?



    BTW. ... on a side note (just a note...), different KSS versions have resources allocated differently.

    on KRC, CPU time given to interpreters is divided in 63 slices (quota).

    robot interpreter quota is about half of them (30 or so). rest is split... (and some slices are reserved as safety buffers)

    on some KSS versions Submit gets 1 but lately the numbers are grown.

    for example on KSS8.5, each Aux submit still gets 1 slice, but main submit gets 4.

    yes, with Multisubmit, more interpreters are available but ... also more reserved slices/quota are used as a dead time (safety buffer).

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • Thank you panic mode, these are usefull ideas / infos.


    I made a test program accordingly and get "on field" values then.

    Basically, the average execution time per row, in best case, is ~0.02ms in SPS and 0.003ms in Global task ( I will rather be like 1.5x time more) .

    I attach this code of exectime analysis with comments for reference (in case the resulting values sounds invalid or for other use ...).


    In my project, most of the code in SPS is only meant to copy-convert I/O data from-to the PLC ( so I felt comfortable to have this in the SPS ).

    I will cut a part of it and stick it inside the global task as per your recommendation, I will have not too much to adapt for keeping data integrity safe (easier than using EX submits indeed).

  • My bad, using robot task for the I/O copy makes no sense of course..!


    So I will have to live with that incredibly slow SPS, (even I may improve a bit the process with the multisubmit, but so far, I could see it won't help much, probably because each EX get only one slice of the 63, and I don't have too much code that I can split...)


    I will optimize the code as much as possible also...


    No one is surprised by the values I measured aboved? 150ms for 3000 rows? I think I am still missing something, hope you can give me your appreciation with this time and maybe even run the SPS test on your kuka (just remove the line with SIMO_INPUT program).


    Is 3000 rows of SPS code already something "big" for a normal project?


    I assume the quotas are configured by Kuka and cannot or should not be modify at all right? (like giving 0 quota for the AUX submits (well disabled then...) and 12 for the SPS for example...)


    :neutral_face:

  • No one is surprised by the values I measured aboved? 150ms for 3000 rows? I think I am still missing something, hope you can give me your appreciation with this time and maybe even run the SPS test on your kuka (just remove the line with SIMO_INPUT program).

    not surprised since i understand result and have seen same results myself


    this is why i specifically asked to compare code execution in robot interpreter and submit interpreter.


    CPU executes instructions at the same rate, does not matter which interpreter is used.

    interpolation cycle is 12ms


    suppose entire 12ms is utilized for interpreters, then single quota is 12ms/64 = 0.1875ms

    robot tasks get 30 quotas or 5.625ms. anything longer than this will continue running during assigned quota in next interpolation cycle

    on KSS 8.3 SPS gets 1 quotas or 0.1875ms. anything longer than this will continue running during assigned quota in next interpolation cycle

    on KSS 8.5 SPS gets 4 quotas or 0.75ms. anything longer than this will continue running during assigned quota in next interpolation cycle


    suppose task you want done takes 3ms of CPU time

    if run in Robot interpreter, this could complete within one interpolation interval of 12ms

    if you run this in Submit on KSS 8.3, it would take at least 4 interpolation cycles (each is 12ms) since quota is only a fraction of that interval. so this will complete in 48ms (or 60ms if spillover).

    on KSS 8.5 this will take one interpolation cycle so it would complete in 12ms (or 24ms in case of spillover)


    suppose task takes 9ms of CPU time

    in the robot interpreter this would complete in 2 interpolation cycles or 24ms

    in submit on KSS8.3, it would take 48 interpolation cycles or 576ms. (compare that to 9ms of actual work)

    in submit on KSS8.5, it would take 12 interpolation cycles or 144ms. (compare that to 9ms of actual work)


    etc.


    i guess you realize by now that your math was not really good. it makes little sense to average results to get execution time per-instruction without considering quotas.


    Is 3000 rows of SPS code already something "big" for a normal project?

    that kinda depends on definition of normal....:winking_face:


    I assume the quotas are configured by Kuka and cannot or should not be modify at all right? (like giving 0 quota for the AUX submits (well disabled then...) and 12 for the SPS for example...)


    well, they sure are not meant to be modified by end user but if you really must, give it a try and keep in mind you are in an uncharted territory.

    according to tests it seem to behave as expected on KSS8.3 and 8.5. I would assume that it is more or less the same with 8.6 but - no guarantees, you are on your own.


    change is simple, just make backup then edit XML file then do a cold boot with reload files. of course to some long term tests for stability.

    and note that this is not persistent - it may be lost with any update, restoring image etc.


    check \Config\System\Common\KRC.xml


    and if you are thinking of not using Multisubmit, you will probably want to turn it off and not just zero the quotas. should be in the same file just below <Scheduling>

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

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