Analog Input Value from SPS loop

Quote from RoboMan3000

I get the error "Array name inadmissible" on the array entries... But the name is fine, P1_POS[1] = {X 0, Y 0, Z 0, A 0, B 0, C 0} for example... Not sure if there's something I'm missing here.

I would need to see the file where you are handling your arrays. Which line throws the error?

I will note that array DECLs and setting in .DAT files can be a bit picky -- if you want to DECL an array and then set its static values in the .DAT file, you must DECL first, then immediately put all the fill values.

;this works
DECL E6POS PosArray[1000]
PosArray[1]={X 0}
PosArray[2]={X 0}
; and so on to 1000

;this does NOT work
DECL E6POS PosArray1[1000]
DECL E6POS PosArray2[1000]
PosArray1[1] = {X 0}
PosArray1[2] = {X 0}
PosArray2[1] = {X 0}
PosArray2[2] = {X 0}

performance of reading file and parsing data depends on file structure and speed of the KPC. i did some tests about a decade ago and if i recall reading/parsing some 1000 lines took perhaps 1-2 seconds. on a new KRC PC is more powerful and that should reflect on performance.

as for using ring buffer, you can declare an array of some length... say 100 elements. then you need two integers to serve as array index. one would be index being used to populate array (index_fill) and the other would be index used by robot to use/consume data (index_use).

so when program starts, you would wait for array to be full... then you can start using the fetched data. while the program is running, index_use would increment. and as long as

((Index_fill-index_use)<array_len) and (index_fill<total_elements))

you can fetch more data to populate array (replace used data elements).

the only thing to keep in mind is that total_elements could reach huge values, such as 10000000 while array length is much smaller. so when fetching data you do not want to write to

ARRAY_NAME[index_fill]

you want to use

ARRAY_NAME[MOD(index_fill+1,array_len) ]

because that index will also keep incrementing until it reaches value of total_elements.

similarly, when reading array elements, instead of

IF index_fill>index_use THEN
LIN ARRAY_NAME[index_use]
ENDIF

you would use

IF index_fill>index_use THEN
ARRAY_NAME[MOD(index_use+1,array_len)]
ENDIF

as you can see size of array or ring buffer is pretty much irrelevant as long as fetching takes same or less time than using of data points. in KRL advance run pointer works similarly and max value for $ADVANCE is 5. so if you double buffer it, your buffer only needs 10 elements and your fetch only needs to get 5 of the elements at a time.

You are calling exact position in the FOR LOOP

Did you tried to run with C_DIS approximation parameter?

With $APO.CDIS before motion you set approximation distance in mm.

$VEL.CP = 0.01

FOR INDEX = 1 TO 114   

SLIN P1_POS[INDEX] C_DIS

 TRIGGER WHEN PATH = 2 ONSTART DELAY=0 DO SIGNAL_LOG (PASS, INDEX) PRIO=1

ENDFOR

Quote from RoboMan3000

Hey - just wondering if anyone has ever had a problem with the tool dipping ever so slightly around corners and when a path starts.

This is one of those things that can have a multitude of causes. And it's endemic to why "can I use a robot as a CNC?" is such a fraught question.

First off, the switch from brake holding to servo holding isn't perfect, which can have an effect on startup motions.

Then, turning "corners" on interpolated paths almost always involves reversing direction on at least one axis, which drives that axis' backlash directly into your real-world TCP motion. Even if no axis is reversing, just enough accel/decel can have a similar effect.

On top of backlash, robots flex, at the bearings and even in the "solid" segments of the arm. with serial kinematics, the effect can be pronounced.

No robot is perfect, physically, compared to the ideal kinematic model being used to do path planning. To a degree, this can be tuned out with Absolute Accuracy tuning or a 3rd-party tuning like NRK's SARCA.

Positioning tolerance is also looser on a robot vs a CNC, to accommodate the open serial kinematics of a robot vs the closed parallel kinematics of a CNC. If most robots tried to maintain path as tightly as a CNC does, they'd end up "hunting" badly. So while cornering, a robot will sacrifice some path accuracy in favor of speed/torque/jerk/other limits.

Quote from RoboMan3000

The robot I'm working with is a KR240, and I only have about 6kg of payload on it (lol).

Thats very unusual. And actually is worst and not best case for robots.

Usually load is closer to nominal load and machine paramters are tuned to perform best at or close to nominal load. Did you check all loads? There is not only TCP load mounted to flange but also additional loads for a1, a2, a3 to be considered. Load data determination only considers TCP load. The first two a1 and a2 additional load by default are zero but $load_a3 is not. Also load data determination is also best for higher loads. For such small loads precision is not very good. At best use some cad data for such small loads. This type of robot has no torque sensors so load data determination needs to estimate torques from current. For very small loads it quickly gets difficult to get precise torques since the load effects can not easily distinguished from expected estimated torques from the path.

Is the robot equipped with absolute accuracy? Whats the setting of $adap_acc and $opt_move for your robot. Does your robot type have elasticity compensation (any $eko_dat[] not zero in $robcor.dat).

What is the exact robot type kr240 has different variants. E.g. if its a quantec it could be e.g. extra ultra or prime. With prime being the best.

Quote from RoboMan3000

There was a considerable reduction in uncertainty (from 0.5mm max deviation to ~0.3, consistently) measured over the path after I performed load data determination

If you see it consistently along the path probably more in the direction of load data and overall accuracy. Backlash is a local phenomenon whenever an axis changes its direction.

Maybe adding some weights on the flange might help.😁

Quote from RoboMan3000

Is this something I can tighten up at all with gear jerk settings? It seems that as I lower $ACC.CP, the deviation is magnified. If this is backlash, we're taking about like 3-5mm observable on the tool... From what I've read, backlash for the KUKAs is only resultant in like +/-0.1mm?

Oh, no, it's FAR more complex than that. Backlash occurs at every joint, but the effect of one joint's backlash on TCP position depends on the current position, acceleration, rigidity, velocity, and backlash of all the other joints "upstream" of it. This makes it nearly impossible to "model out", which is why Abs-Acc and SARCA exist -- it boils down to tuning the robot in its working state and environment.

And don't get me started on the effects of thermal expansion, or even the light tugs of festooning....

Quote from RoboMan3000

The robot I'm working with is a KR240, and I only have about 6kg of payload on it (lol). I'd imagine it could execute this path very rigidly in that context! Especially with load data determination completed.

That's not optimal. The robot wants a certain % of its rated payload (remember, this includes mass and CG and inertias). Probably around 30-50% -- IIRC, Load Identification works poorly if the robot is less than 30% rated payload.

I've attached a KUKA accuracy spec document for a KR500, as an example. You can probably get the same document for your robot from KUKA tech support. But you can see that robots are built far more for repeatability than accuracy.

One other thing is that the wrist is the worst for accuracy. All the test results I've ever done, changing the TCP orientation drove accuracy errors much faster than changing position.

Quote from RoboMan3000

I've also contacted KUKA regarding absolute accuracy. Seems like it's only something the HA robots use but maybe I'm wrong.

No, any KUKAbot can have AA calibration done, as it's pure software. The HAs are built from more finely-tuned hardware that, in combination with AA, squeezes a bit more blood from the stone.

AA and HA are no panaceas, though. AA is normally done at the factory, with default loads and full working volume. And then tries to model out the effects of different payloads in actual production use. In my experience, the best performance from AA is to calibrate the robot in its working conditions (mounting, payload, festooning, etc) and limiting the calibration to the segment of the robot's motion volume where you actually need AA.

Quote from RoboMan3000

; Loop through the array and write each element
FOR i = 1 TO N
; Write the element with a newline (CRLF = 'H0D''H0A')
CWRITE($FCT_CALL, STAT, MODE, "krl_fputc", HANDLE, "%f'H0D''H0A'", Ln_ScDat [i])
ENDFOR

why dont you call writeScanDataToFile() everytime i increments and then use

CWRITE($FCT_CALL, STAT, MODE, "krl_fopen", "D:\NETWORK_DRIVE\Ln_Scandata.txt", "a", HANDLE)

instead of

CWRITE($FCT_CALL, STAT, MODE, "krl_fopen", "D:\NETWORK_DRIVE\Ln_Scandata.txt", "w", HANDLE)

Let me know how it goes

Quote from RoboMan3000

Mostly because I imagine that operation would take more time than logging to an array. Worth a shot I suppose