RSI QUESTIONS

you can modify ETHERNET object and add more inputs and outputs to it.

why don't you start with program example from manual? it has everything to get you going. play with it then incrementally add your modifications.

basically create RSI context graphically. This produces three files (i hope it is same on KSS8.5).
then you place those files on a controller in strategic locations. name of file is what you use in KRL program when using RSI_CREATE().

(note: my experience with RSI is v3.x, so some of my knowledge could be out of date)

What kind of transform do you need to do? I don't have my docs available ATM, but I'm certain the RSIVisual math library include a couple of 6DOF transform function blocks, both "general" and specialized for Tool/Base transforms.

If you absolutely must transfer data from the RSI context into either the Level 1 (regular) or Level 0 (SPS) interpreters, I can think of two ways: the $SEN_PREA system variables, or the I/O system. There's no other way that I can recall off the top of my head to cyclically transfer data between a KRL interpreter and the RSI container(s).

There's not much "bandwidth" between the RSI context and the KRL context -- they can both read and manipulate the I/O table, but IIRC there's no RSI objects to read $OUTs, only setting them (could be wrong). But the $SEN_PREA variables have read/write access from both contexts, unless I'm forgetting something.

Your program in the KRL interpreter would have to be able to keep up with the RSI container, which could potentially be an issue depending on your RSI cycle rate. The good news there is that a well-designed state machine in KRL should be easily able to do this -- the potential joker in the deck is the signal update timing. $OUTs are essentially interrupt-driven, but $INs are only read once every IPO cycle (12ms for the L1 and L0 interpreters, but RSI can run at higher rates in certain modes). The $SEN_PREAs... I'm not sure what controls their timing, it would be an interesting experiment. Safest bet would be to run your RSI on the same 12ms clock rate and avoid the issue entirely.

The KRL interpreters and the RSI containers are, effectively, separate contexts -- it wouldn't be too far off to consider them separate threads on the same processor, with certain shared resources. RSI operates much "closer to the metal," as it were, tying inputs almost directly to motion without many of the abstractions that exist between KRL and the motion planner. This is what makes RSI so powerful, but also potentially hazardous -- RSI is "working without a net," essentially "below" many of the protections KRL provides.

KRL has $TIMER...

The only way I can think of to test the refresh timing of the $SEN_PREAs would be to create an IPO_FAST RSI container and set it up to change the $SEN_PREA values at something faster than 12ms. Then create an .SRC program that would loop as quickly as possible and log the $SEN_PREA values every loop. In an unhibited loop, KRL code executes in something under 50ns/line, IIRC, but each interpreter only executes for 2-4ms out of every 12ms, (again IIRC).

I don't think the $TIMERs or WAITs can be reliably used in increments below 12ms, so I wouldn't rely on them for controlling program timing. Instead, create a very large STRUC array in the .DAT file, and pre-seed it with null values:

STRUC LogArrayStruc INT TimeVal, REAL SENPREA
DECL LogArrayStruc LogArray[1000]
LogArrayStruc[1] = {TimeVal 0}
LogArrayStruc[2] = {TimeVal 0}
; fill all 1000 entries -- this is easiest to do using Excel

Then, in your KRL program, once the RSI container is running:

$TIMER[1] = 0
$TIMER_STOP[1] = FALSE
FOR Index = 1 TO 1000
  LogArray[Index].TimeVal = $TIMER[1]
  LogArray[Index].SENPREA = $SEN_PREA[1]
ENDFOR

The idea here is to examine the "beat frequency" between the KRL and the RSI. If, for example, your RSI is changing $SEN_PREA every 4ms, what you should see in LogArray is 3 repeats of every TimeVal. If the Level 1 interpreter is "checking" the $SEN_PREA values only once every 12ms, then the SENPREA values will repeat along with the TimeVal values. OTOH, if the Level 1 interpreter isn't limited to the 12ms refresh of the $SEN_PREA variables, you should see something like:

LogArray[1] = {TimeVal 24, SENPREA 123.456}
LogArray[2] = {TimeVal 24, SENPREA 456.789}
LogArray[3] = {TimeVal 24, SENPREA 987.543}
LogArray[4] = {TimeVal 36, SENPREA 543.210}

Basically, if the logged values of $SEN_PREA only change when the logged $TIMER values do, then the Level 1 interpreter can't "see" any changes in $SEN_PREA that happen faster than once every 12ms. OTOH, if the logged $SEN_PREA values change faster than the $TIMER values, that's a very strong indicator that the L1 interpreter can see $SEN_PREA update as fast as the RSI container can make the changes.

Well, it's mostly historical. Robot programs have almost always been dominated by motion time, so the non-motion execution speed of program code was generally far less important than maintaining the timing relationship between the program code, motion commands, and the hardware.

So, KRCs have been running on a 12ms internal clock cycle for at least 25 years now (they've only recently started to provide higher rates in certain circumstances). And in that 12ms "pie", ever sub-task got a fixed "slice", usually 2-4ms. The L0 interpreter, the L1, the motion planner, the I/O refresh, each of them got that fixed slice of time, once every 12ms. And inside their "slice", each task was allowed to run as fast as it possibly could, except in regards to motion commands.

Over the years, the CPUs got faster and faster, but changing the 12ms clock cycle would have been expensive, risky, and frankly there wasn't much need or demand for it (until pretty recently). So keeping the 12ms cycle, and all the "slices", in their fixed relationship was the low-risk technical decision. But with faster CPUs, the execution time per line of non-motion code kept getting smaller. So people started writing fancier, more elaborate functions into robot code, slipping them in between motions or into the SPS.

Ironically, most of what a KRC needs to function would still fit into a 386DX class CPU. The bulk of the extra CPU horespower has been taken up running Windows for the user interface.

The RSI is something else completely. It is, essentially, a tool to bypass much of the robot's higher-level path planning abstractions (and safety nets) and connect sensor inputs directly to the motion planner in near-realtime. While it usually runs on the same 12ms cycle as the classic internal clock, it's not part of it, AIUI -- it doesn't get a "slice" of the 12ms pie that the rest of the robot runs on. Instead, it runs as a parallel process, essentially asynchronous from the rest of the robot, but running on a compatible frequency.

So, the strangeness you're seeing is mostly a result of "backwards compatibility barnacles," much like modern versions of Windows still have support for old 32bit (and even some DOS 16-bit) functions, because changing the OS would break too much mission-critical software that's still installed in production.
That, and the fact that automation software has to be conservative about changing stuff that already works. As my team used to joke, "when some Web Weenie makes a programming bug, he crashes someone's website for an hour. When we make a programming bug, we crash $50000 worth of hardware into another $50000 worth of hardware at 50mph+!"