Posts by Mentat

Open the robot system integrator or programming manual to "Programming for user group "Expert"". Then read and learn how to program robot with Kuka Robot Language (KRL). Make sure to follow safety guidelines and don't run untested code at full speed.

It seems like you came upon a working robot cell. If you don't know what you are doing and you are not supposed to be there, don't muck about with it- the machine will kill or maim you if you get close enough.

If you don't need actual real time, but small latency (12 ms) is fine: either JOpenShowVar or Kuka Ethernet KRL. The latter is a paid option from Kuka.

Don't want to go into all the gory technical details and edge cases, so to keep it short: Yes.

For using text files- read CRead/CWrite manual (in the manuals section of the forum).

Specifically CWRITE function calls ($FCT_CALL) krl_fopen, krl_fgets, krl_fprintf and (obviously ) krl_fclose.

To avoid stopping, you simply have to have a buffer of movements that is bigger than your $advance value. Which means that either you have to either :

1. read movements from file in parallel (and ahead) of motion

2. Stop, stock the buffer, execute the movements.

From the manual:

Signal

SIGNAL OUTWORT $OUT[1] TO $OUT[8] ;//This line has to be in declaration section

OUTWORT = 8

Quote from dexterv

what is the benefit of converting them to XYZABC, wouldn't SPTP spline block suffice?

Would not have to rely on mimic's sample rate, as you could just calculate the distance between points instead of guessing, load them (without ABC) onto a CAD program for easier visualization, analysis and modification.

Then again if you only need to get this done once and then never again, SPTP spline block could be faster.

I suggest converting them to XYZABC, spacing out and then putting in a spline. Will make changing speed and acceleration easier too.

If you want to send current robot position while the robot is moving, you will need to use two separate "threads". Hence the submit interpreter suggestion.

If the robot can just send it's position at the end of the movement, then it's just a function to send data, an array of movements and a for cycle.

Another option would include RSI module, but it's quite pricey.

Not a solution, but:

1. Read up about subprograms and functions.

2. Read about submit interpreter (sps.sub). That's where I would put the "Send coordinates through Ethernet KRL" part of a program.

Quote from SkyeFire

The other option that might work... create an Interrupt in the Level 1 interpreter that does something like $TOOL=TOOL_DATA[1], and is triggered by the SPS (via a $FLAG or Global Boolean) after the SPS has triggered the pop-up and made the change to TOOL_DATA[1]. This wouldn't work while the robot was running a program, but while stationary in T1 it might work. Your interrupt subroutine might need to use BRAKE and RESUME to cancel any motion that's currently in process, maybe followed by a PTP $POS_ACT to fully set the new $TOOL and position.

But I have to admit, I'm guessing a bit. I've never tried something quite like this.

Because changes to $TOOL and $BASE in the interrupt program are only effective there

(command mode), you would have to return changes to $tool and/or $base via global variables and apply them after the interrupt.

Maybe I am alone in this, but your question is too vague. Which corner, if it's rectangle shaped, it has around 4? Also, rotate how? Finally, IMO using geometric operators is the easy way.

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

My guess is you have message auto confirmation in ext mode enabled. Try running on auto or t2 if able, see if you get an error message.

If you get something that sound like "reposition", try searching the forum for that.

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.

Yeah, I caught myself five minutes after I posted, then proceeded to delete the thread, but that doesn't seem to have worked

Sorry if this has been asked before, but I didn't find anything relevant.

KR4 KSS 8.3.422

How to initialise a structure, that has a non-char array, inside a .dat file?

With char array it's simple:

   struc StrucType char TestString[12]
   decl StrucType TestStruc ={TestString[] "Test"}

Is it possible with other types?

Some of what I tried (separately of course):

struc StrucType real TestReals[12]
decl StrucType TestStruc ={TestReals[1] {3.14}}

decl StrucType TestStruc ={TestReals[] {3.14,4,8}}

decl StrucType TestStruc
TestStruc.TestReals[1] =3.14

For now initialising using a separate procedure outside dat file will have to do, but maybe there is a better way...

I agree, turning interrupts off is as needed as turning them on at appropriate time. I should have known better than that when providing an example to someone, who is just starting to use them.

My comment about untested code, was more of a general idea Also, by "testing" I meant, more of running the code under different conditions to determine if it's fit for use not only in normal or perfect conditions. IMO in automation, 1 in 10000 is a "when", not "if".

Quote from panic mode

this is what result could be:

After reading the title, I expected an explosion. Feeling a little let down, but that's my own fault.

While we are at it, don't run untested code at speeds higher than you can react, folks.

Almost, like what you wrote, but needs some changes:

DEF PROG()

INI

...

INTERRUPT DECL 21 WHEN $IN[15] DO FOUND()

PTP HOME

...
INTERRUPT ON 21
PartFound = False
$advance = 0
SEARCH()
$advance = 3
if PartFound then
... ;The robot grips the found part.

...

END


DEF SEARCH()

SPLINE

SPL START_SEARCH

SPL IN_BETWEEN

SPL END_SEARCH

ENDSPLINE

END


DEF FOUND()

INTERRUPT OFF 21

BRAKE
FoundPartAt=$pos_int  ;// declared as a global pos/frame variable
PartFound=True ;// global bool variable
RESUME

END