Optimizing my submit program

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.

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.

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.

At 200 mm/sec, the robot will only travel 2.4 mm. Is that unacceptable? You mentioned that it is currently 50.

Quote from SkyeFire

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

Quote from panic mode

(...) 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?

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

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

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

Quote from ComaWhite

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

I think most KUKA robots work with hardcoded motions during the same thing for 3+ years with little to no calculation in between motions. with such conditions there is no need to worry about execution of code lines over time

Quote from ComaWhite

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 simply 12ms/64 = 0.1875ms

robot tasks get 30 quotas or 5.625ms. anything longer than this will continue running during assigned quota in the 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 0.73ms of CPU time

if run in Robot interpreter, this could complete within one interpolation interval of 12ms (depending on when it started, maybe it was not the first thing interpreter had to do...)

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.

Quote from ComaWhite

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

that kinda depends on definition of normal....

Quote from ComaWhite

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>