New to .sps Programming

read pinned topic READ FIRST and check manuals list.

in KRL files have extensions DAT, SRC or SUB.

about file types... SRC and SUB are structurally identical, only extension is different since KUKA decided that main program in submit interpreter needs different extension (SUB). but once you get past that, both SRC and SUB are happy to call SRC files as subprograms. this is good to know and i highly recommend to create program module (SRC and optionally DAT file) for your Submit. then you can test logic conveniently by running it as a robot program. once everything is ok, just call it as a subprogram from your Submit.

about variables... normally Submit does not have own DAT file so common thing is to just declare them as globals... or call subprogram that has own DAT file. chances are you will want background task to use global variables anyway since monitoring them is simpler.

as with anything beware of nested loops. Submit normally has own endless loop so if subprogram or block of code also has own loop, this will slow down or completely block execution of main portion of the code in the submit. and some things rely on working Submit (such as tech options that use status keys).

if your system has multisubmit, consider running your own background code in one of the extended submits.

main submit is faster (or more precisely, it has allocated larger CPU quota) and main submit is the only Submit that can run motion but this is limited to asynchronous external axes. no submit can run robot motion, that is only possible from robot interpreter.

Quote from Dstamper10

I am starting to dive into .sps programming (New to KUKAs in general) and new to how to implement changes (Very Familiar w/ Fanuc BG_Logic) Looking to understand the do's and Don't's for implementing effective changes. Any Suggestions on to get a good understanding how it works?

What KSS version? KSS 8.4 or 8.5 introduced multi-Submit (which was previously a paid option) as a core part of the system.

Terminology: KRCs have two interpreters: The Level 0 (Submit) interpreter, and the Level 1 (Robot) Interpreter. Plus, with Multi-Submit, several additional parallel-executing Submit interpreters are provided for.

SPS does not have the strict timing guarantee of Fanuc BGL. Instead, SPS runs at the standard execution-per-line (including comments and blank lines!) of any KRL program. The internal clock cycle of a KRC is 12ms, and the SPS gets a fixed "slice" of that "pie". So a long SPS program that takes longer than that time slice to run will execute partway, then be suspended until the SPS-slice of the next 12ms cycle. On the other hand, a short "tight" SPS could easily execute its entire loop multiple times in a single "slice". And the KRL per-line execution time changes with every CPU upgrade, so there is no stable timing in an SPS program.

So, one of the most basic rules of SPS programming is, no WAIT commands. No internal loops that can get "stuck" and prevent other parts of the SPS from running. State machine programming is popular in SPS applications.

Another is, if you need timing control, use $TIMERs or the $ROB_TIMER variable. In one or two cases, many years ago, when I had an SPS that had to run some critical code every 12ms without fail, combined with other subroutines that could afford to run less often, I used timer control to run small chunks of the low-priority code every 36 or 48ms, while ensuring the high-priority code ran every 12ms.

Unlike BGL, SPS looping is not inherent -- you have to write it in. If you look at the default SPS.SUB program that comes with every KUKA, you'll see an INIT section that runs once on boot (or when someone Cancels and then re-Selects the SPS), followed by an eternal LOOP/ENDLOOP within which the cyclic code is contained. It's possible to write a .SUB program that only executes once, or a fixed number of times, although that's pretty rare.

SPS programming has fewer restrictions that BGL. Basically, an SPS program can run any "normal" KRL code, with the exception of motion commands, or commands that might affect motion, like changing $BASE, $TOOl, or other motion-critical values. The exceptions to this are that it's possible to have external axes that are controlled by the Submit instead of the Robot interpreter, and the SPS can control the $OV_PRO and $OV_APPL variables that can "dial" the robot's overall speed up and down, without changing the path trajectory.

Submit programs can call "regular" .SRC subroutines, barring motion-controlling subroutines. So if you have a special math subroutine that both the Robot and Submit interpreters need to make use of, you can call that subroutine in parallel. That subroutine should be stateless, though, since nothing stops the different programs from stomping on the shared variables.

Submit and Robot interpreters are completely asynchronous. This can lead to some strange issues. For example, the system variable $POS_ACT_MES contains the realtime Cartesian position of the robot. But it's under the custody of the Robot interpreter, and under some circumstances (like a program Reset or Cancel), can contain no data (State #DECLARED instead of #INITIALIZED). If the SPS is trying to read $POS_ACT_MES, it's guaranteed that, eventually, the SPS will try to read $POS_ACT_MES when it contains no valid data, even if the previous line of the SPS checked the state of $POS_ACT_MES. That's b/c there's nothing tying the two interpreters together. These days, it's possible to get around that using ON_ERR_PROCEED, but before KSS 5.(4? 6?) it was a real headache.