Program with massive number of programmed motions/locations

That's a LOT of points. You're going to be at risk of exceeding the total memory limit of the /R1 tree, in addition to individual module-size limitations.

RSI... might do what you want, but it's more intended for realtime control of motion from sensor inputs. EIP would probably be a better choice, as long as your remote EIP source can keep up with the demand.

Reading from a massive external text file is an option, although you might need to put the Read commands into TRIGGER functions to ensure nothing breaks the advance run pointer.

The main issue here, whatever means you use, is that your input of point data must stay some number of points ahead of the motion pointer. For example, with the default $ADVANCE value of 3, to move smoothly from Point A to B to C to D, you would have to have D's value already set before the robot began the motion from A to B. You can reduce this by reducing $ADVANCE to 1, but even then you would still have to have C loaded before the robot reached the approximation radius of B, at minimum.
Bottom line, in order to perform approximate motion around a point, the robot must have all the points within range of the Advance pointer already known. IN the ABCD example, if D's position was still being loaded when the robot departed A, the robot would end up coming to a complete, though brief, halt at C, even if D's position had finished loading before the robot even reached B. The root of this is the way that the robot pre-calculates its path through the range of the Advance pointer (which can range from 0 to 5, but 0 is the same as turning approximation off entirely).

You might be able to establish a "ring buffer" of sorts where the points are loaded with minimal footprint in robot memory. Something vaguely like this:

; preload
FOR PointIndex = 1 TO PointArrayLimit
  ArrayIndex = PointIndex
  PointArray [ArrayIndex] = LoadRemotePoint (PointIndex) ; get point X data from remote source
ENDFOR
ArrayIndex = 1
REPEAT
  PTP PointArray[ArrayIndex] C_PTP
  ArrayIndex = ArrayIndex + 1
  IF (ArrayIndex > PointArrayLimit) THEN
    ArrayIndex = 1
  ENDIF
  CONTINUE
  PointArray[ArrayIndex] = LoadRemotePoint (PointIndex) ; get point X from remote source
  PointIndex = PointIndex + 1
UNTIL PointIndex = LastPoint

Something along those lines. I've probably botched something there, but it's just off-the-cuff concept code. Plus, the best way to get responses on this forum is to post bad code.

The LoadRemotePoint subroutine would be what needs to take place enough points "ahead" of the motion pointer to ensure that any expected time lags don't last long enough for the motion pointer to catch up. The preload of the array is just to ensure that the first few motions are smooth, rather than stop&go. In the robot, you might declare an E6AXIS or E6POS array of 5, or 10, or even 100, and the robot would just keep running through that array, with the remote-load staying some number of points ahead of the motion pointer, and both of them rolling over from the top of the array to the bottom. The remote-load could be an EIP I/O exchange, a read from a text file, or any of quite a few other options.

First off, Spline motions are... odd. I can't say for certain how they'll interact with the Advance pointer, as their behavior has been changed substantially since I last used them.
Also, pretty sure you can't use C_DIS with them, it needs to be... C_SPL?

Speaking more generally, the Advance pointer looks ahead by a number of motions. Hence, you could have:

LIN P1 C_DIS
LIN P2 C_DIS
LIN P3 C_DIS
LIN P4 C_DIS
FOR I = 1 TO 1000000000
  Counter = Counter + 1
ENDFOR
LIN P5

And that (ridiculous) 1-million count FOR loop would execute on-the-fly, beginning when the TCP passed point P2 (assuming factory-default $ADVANCE value of 3). Assuming, of course, that there wasn't anything inside the FOR loop that would break the advance pointer (WAITs, $IN/$OUT commands, etc). I'm not... entirely certain what would happen if that FOR loop just took longer to execute than the travel time from P2 to P5, but since single-line KRL execution generally takes, IIRC, 50ns on a current-gen KRC4, it's unlikely to be an issue. At worst, you'd get an error message that "Motion could not be approximated" and the robot would probably perform a stop-and-go at P4. And if I was concerned about that, I'd use a TRIGGER-called subroutine or the SPS. This is a deliberately ridiculous example.

If you're executing motions inside a FOR loop, the same rule still holds. Assuming $ADVANCE==3, then:

Counter = 0
FOR I = 1 TO 100
  LIN PointArray[I] C_DIS
  Counter = Counter + 1
ENDFOR

When the robot is physically executing the motion to PointArray-1, the value of Counter will already be 2, because the Advance pointer will have pre-loaded 3 motions in advance (1, 2, and 3), and pre-executed any logic in between them. The Advance pointer will get "hung" on PointArray-3 (thus not reaching the line that would increment Counter to 3) until the motion pointer reaches its transition point between PointArray-1 and PointArray-2 (generally the point of closest approach to PointArray-1). As soon as the motion pointer transitions from PointArray-1 to -2, the Advance pointer will increment Counter to 3 and get "hung" pre-loading the motion for PointArray-4.

Note: in general, depending on an exact relationship between the Motion and Advance pointers is a bad idea -- that's why, in my original example, I pre-loaded enough of the array to guarantee that, unless a very long delay in the Remote-Load subroutine occurred, there would always be a very comfortable margin between the two pointers.

This might work with SLIN but SLIN stops the motion at the end of move anyway. And its not going to work with a spline block, as that has to be preplanned completely(and in my experience maximum 800-1000 points or crashes entire controller). Interesting ideas though, would love to hear if they work.

You mentioned EIP, I always thought of this as simply a communication protocol, versus say the native ethercat. Would the same approach be possible with ethercat, or does the EIP option package have some other advantages? If FeedRate can be declared in the Config.Dat, maybe there is a way to simply update that variable via Submit. For example we have a FRAME mapped where we can change the base via PLC (you could do this with RSI). Of course to make it active it has to be assigned in the SRC, but you are already doing that in the WITH $VEL.CP = FEEDRATEARRAY. The key would be making sure its updated fast enough in the SPS. Not to mention syncing with the PLC to make sure its on the right feed value.

Hm. Interesting. The manual seems to suggest that at least some of the SPL type motions can be used outside of a predefined SPLINE block, but I've never had occasion to try this. I'll have to see if I have an opportunity in the near future.

You can definitely use SLIN outside a spline block. Sucessive SLIN blocks stops at the end of the move in my experience(SLIN-SPL-SLIN will move continuous though); the C_DIS command is only relevant when the next move after SLIN is LIN/CIRC such that it will approximate the last SLIN. But to be honest, I am not sure if I ever tried two successive SLIN moves with C_DIS set on both, so maybe I will need to give that a try.

Hello everyone,

I am sorry to revive this old topic. I am trying to do exactly the same as the OP: Use EthernetKRL or RSI (our robot has both, KRC 4 v8.3) to "stream" millions of points to the robot. My idea was to read the points from an external computer using the submit interpreter and write them into an array to store a fixed maximum number of points (maybe 100). Then in the KRL interpreter I would read the points from the array in a loop. By sending the current position ID to external computer the external program would know which positions have been processed. I would then continuously overwrite already processed points from the array and read in new ones, essentially creating a "ring buffer" of some sort.

Pseudo code:

Submit Interpreter:
;read operation
;Read message from external computer
ReadEthernetKRL(positions_from_ext)
ReadEthernetKRL(lastpositiontreached)
;Store positions in array: 
IF lastpositiontreached = FALSE
  FOR N = 1 TO "number of positions received"
    ID = positions_from_array[N].ID
    positions_array[ID] = positions_from_ext[N].position
  ENDFOR
ENDIF
;send operation
;Send current position ID to external computer
SendEthernetKRL(current_position_ID)


KRL:
WHILE lastpositionreached = FALSE
  FOR ID = 1 TO SIZE(positions_array)
    current_position_ID = ID
    LIN positions_array[ID].position C_DIS
  ENDFOR
ENDWHILE

Would something like this be possible (without breaking the advance run)?

I'm fairly certain that the EKI commands break the Advance Run Pointer, so doing this in the level 1 interpreter wouldn't be easy. You might have better luck doing the communications portion from the SPS.