Posts by RoboticsMan

I know that a manual from the KRC1/KRC2 times is hardly up to date, but since the behavior described in the manual aligns with what I observed up until software version 8.3, I thought that it was fair to assume that the behavior would still be the same in 8.5. That it is no longer mentioned in the manual I find less important, since KUKA sometimes seems to omit some things in some manuals.

I have emailed my contact at KUKA asking whether they have change-logs, so let's see what that brings.

But anyways, I managed to solve my problem using an interrupt that is triggered by a cyclical flag that is defined like this:

$cycflag[4] = ($PRO_STATE1 == #P_ACTIVE) AND (STOP_REQUESTED == TRUE)

The STOP_REQUESTED variable is then set from the SPS.

Because we use $PRO_STATE1 (program state) in the cyclical flag, the rising edge that triggers the interrupt will never come while the program is stopped, only when it is started again. I have now implemented it and tested it multiple times, and it works!

I am pretty satisfied with that solution, unfortunately I didn't come up with it myself, one of my colleagues suggested it.

Quote from Fubini

After the resume of interrupt_handler.

Fubini

Oook? But I don't have any movements in the interrupt, so I am not sure how that will change anything. Especially since my problem is that the interrupt is triggered later than I want. But sure, I'll try it out.

Update: I tried it, didn't change anything.

Quote from panic mode

Program looks ok to me. I think the issue is with testing conditions. Do not stop program... Keep it running... do not pause to trigger the interrupt. And make sure input is off before each test.

Well, ok. But is should have worked, even if the program was paused. At least it used to in earlier versions (e.g. v8.3). I found the proof that it used to be the way I want in an old manual that you shared in another thread in this forum.

The document is :

"SOFTWARE

KR C1 / KR C2 / KR C3
Reference Guide
Release 4.1"

And in section 2.2.27.3 on page 84 it says:

"Each declared and activated interrupt can be detected once during an operator stop. After

restarting the system, the interrupts that have occurred are executed in order of their priority
(if they are enabled). The program is subsequently continued."

This is exactly the behavior I want have have observed in older versions, but don't see anymore in v8.5. So KUKA must have changed something related to that. This was why I was asking about change-logs.

I have a former colleague that now works at KUKA, so I think I'll give him a call to find out if the change in v8.5 is intended or not.

"Do not stop program... Keep it running... do not pause to trigger the interrupt."

This is unfortunately not realistic for use case we have. The user will be using the robot in T1 mode a lot of the time during setup and run in, and might release the stop button at any point.

The robot receives coordinates from a software that runs on the PC. At any point the user might decide to change the program flow on the PC and start over. When this happens, the PC sends a stop signal that tells the robot to stop the current movement and skip any other movements that have been queued up. This is handled by the SPS. The PC software will then ask the robot where it currently is, and take it from there. Unfortunately, the interrupt that is triggered by the SPS only works properly if the robot is moving when the stop signal comes. If the robot program was temporarily paused, then the interrupt handler will only be run AFTER the current movement.

Quote from Fubini

You should take care that the advance run pointer stays inside the Interrupt. This has been discussed multiple times in this forum and is a common programming error with Interrupts.

Fubini

Just to be sure, when you say "inside the Interrupt", do you mean that I should have an advance pointer stop before I disable the interrupt? Because I have that in line 38, in move_func().

Well, I cannot show you the original code, since that is part of a bigger system. So I have now boiled it down to a small example, and tested this on both robots. The test gave the same result as I mentioned earlier.

I had to redo the movements on the robot with KSS 8.3, (since it didn't understand the movements in the file from KSS 8.5) but otherwise the program is the same.

The code:

DEF interrupt_test( )
;FOLD INI;%{PE}
;FOLD BASISTECH INI
GLOBAL INTERRUPT DECL 3 WHEN $STOPMESS==TRUE DO IR_STOPM ( )
INTERRUPT ON 3
BAS (#INITMOV,0 )
;ENDFOLD (BASISTECH INI)
;FOLD USER INI
;Make your modifications here
;ENDFOLD (USER INI)
;ENDFOLD (INI)

;FOLD PTP HOME Vel=100 % DEFAULT;%{PE}
WAIT SEC 0.0

; Flag used to see if interrupt has been triggered
$FLAG[10] = FALSE

; input 3 can be triggered manually
INTERRUPT DECL 10 WHEN $in[3] DO interrupt_handler()
INTERRUPT ON 10

; Wait time to make sure interrupt is ready
WAIT SEC 0.1

move_func()

INTERRUPT OFF 10
;FOLD PTP HOME Vel=100 % PDAT1;%{PE}

END


def move_func()

;FOLD PTP P1 Vel=10 % PDAT2 Tool[1]:Tcp_Tool Base[0];%{PE}
;FOLD LIN P2 Vel=0.5 m/s CPDAT1 Tool[1]:Tcp_Tool Base[0] ;%{PE}
WAIT SEC 0

end


def interrupt_handler()
BRAKE
INTERRUPT OFF 10
$FLAG[10] = TRUE
RESUME
end

Hi,

I know this is an old topic, but have a similar problem as the original poster, so I can add some details. Maybe this can help other people that may encounter it.

I have made a test where I make a linear movement between two points. Lets call them P1 and P2. Before P1 I enable an interrupt. The interrupt handler calls BRAKE, so if the interrupt is triggered between P1 and P2, the robot will not finish the movement. So far, so good.

In our office we have two KRC4 robots. A KR6 running KSS 8.3.174 and a KR10 running KSS 8.5.385

During the test I release the run button while the program is between P1 and P2 (I am running in T1 mode) so that the program stops. I then manually trigger the interrupt condition (by pushing a piston back).

The behavior is not the same on the two robots. On the one running KSS 8.3, the interrupt routine will be activated as soon as I press the run button again (this is what I want!).

On the one running KSS 8.5, the interrupt routine will be triggered at the end of the movement, so in P2 - and it doesn't matter if the interrupt signal is switched on and off several times on the way from the "stop" point to P2.

However, if I on the KSS 8.5 robot release the run button, and press it again without triggering the interrupt, and then trigger the interrupt when the program is running again, then it works as it should (robot stops immediately).

As far as I remember, the behavior on our KRC2 robots is the same as on the KSS 8.3 robot (I haven't tested this recently).

I find this difference in behavior between KSS 8.3 and 8.5 pretty weird. Does KUKA release changelogs/ release notes for the KSS software, so that one can see what the differences are between the different versions?

/RoboticsMan

Ok, thanks!

Hi,

It is possible to pass arguments when calling a TP program from a TP program. It is also possible when calling a Karel program from a TP program. But what about when calling a TP program from a Karel program?

So far I have not been able to find a way (other than doing it indirectly via registers). Maybe it is not supported?

Thanks in advance!

/ RoboticsMan

No, unfortunately there was no backup. In the end I was able to write all of the code again in about 3 days. It sucks to have to do that, but at least it was not close to a deadline.

One of my colleagues accidentally did an I-Start on a robot running on a production line at a car factory. Fortunately they were able to get it back up and running with a backup, but it is really horrible user interface design, that there isn't more of a warning when doing I-Start. I think I will contact ABB and ask them to improve this.

Hi,

Ok, I know this is a long shot. I have been working on a robot program in RobotStudio for a while now. So far everything has been done in the virtual environment. Today I wanted to do a warm-start, but must have mis-clicked and performed an I-start. When the virtual robot controller booted up again, all the files were lost. Is there any way to recover them, or do I have to start over? (that's my guess).

Im trying Windows File recovery, but I have not found anything so far.

Thanks in advance!

/RoboticsMan

Hello,

I am trying to make an analytical inverse kinematics solver for the Fanuc CRX-10iA robot. I already made such a solver for "normal" 6-axis robots with spherical wrists (spherical = axis 4-5-6 intersect in the same point), and for UR-style robots.

For robots with spherical wrist, I use the flange->wrist offset to determine the location of the center of the wrist. The A1, A2, and A3 angles can then be found using a little geometry. A4, A5 and A6 angles are found using ZYZ Euler angles.

The UR robot does not have a spherical wrist, but I know that A4 is parallel with A2 and that both A4 and A6 are perpendicular to A5. So I can find the A5-A6 intersection, calculate an initial angle to that one (first guess for A1), compensate for the A4 offset to get the correct A1 angle, then subtract the A4 offset to find the intersection between A4-A5. This point is then used for the formulas to derive the A1-A3 angles, and the A4-A5-A6 angles are derived using ZYZ Euler angles like I did for the robots with spherical wrists.

But now I want to make an analytical solver for the Fanuc CRX-10iA robot. It is in many ways like a robot with a spherical wrist, only the wrist axes do not all intersect in the same point. See attached picture. Do any of you have a good idea for how to solve this using geometry? I know that I can find a solution using the jacobian method, but I want to use the analytical solver to find a good starting guess for the jacobian solver.

Thanks in advance!

Thanks for the answers so far! I think the robot was running a pretty new version of RW. Unfortunately I no longer have access to the robot, but I will keep it in mind the next time I get my hands on a robot with the same problem.

Quote from Lemster68

That is probably an instance of the built in safety signals.

Sooo.... is there anything one can do? It works on some robots, so it is not that it only works in the simulator.

Hi!

I am trying to make a program that can read the names of the available inputs and outputs on the robot, using the "ReadCfgData" command. The names are then displayed in a list, so that the user can choose which inputs/outputs to use for what, when the robot program is set up.

This works fine when it is simulated in RobotStudio, but on some real robots it doesn't work. We recently had a case where it gave us the following error message:

"

40747: Access Error

Description

Task T_ROB1

Cannot read or write to the system parameter Attribute. The parameter is internal and protected from reading and writing.

Program ref: /SBase/GetExistingIONames/ReadCFGData/4747

Actions

Recovery: ERR_CFG_INTERNAL

"

The code for reading the signal names looks like this:

FOR nIndex FROM 1 TO nMaxSignalIndex DO
  ReadCfgData "/EIO/EIO_SIGNAL/SignalType/"+sSignalTypeString,"Name",sSignalName\ListNo:=nListIndex;
  ReadCfgData "/EIO/EIO_SIGNAL/"+sSignalName,"Device",sDeviceName;
  IF (sDeviceName<>"PANEL") AND (sDeviceName<>"DRV_1") AND (sSignalName<>"") THEN
    sSignalList{nSignalsRead}:=sSignalName;
  ELSE
    Decr nSignalsRead;
  ENDIF

  IF (nListIndex=-1) THEN
    RETURN nSignalsRead;
  ENDIF
  Incr nSignalsRead;
ENDFOR

sSignalTypeString will have one of the values "DI", "DO", "GI", "GO", "AI", "AO". In this particular case (where it failed), the value was "DO".

We have not been able to figure out what the problem is, and how to solve it. Is it a system setting that we need to change?

Any help would be greatly appreciated. Thanks in advance!

/RoboticsMan

EDIT: Added information: It fails on the first call to ReadCfgData

I found the solution. RoboDK was apparently running on the wrong graphics card. I had the same problem in another program, but there I actually got a warning saying that the headset had to be running on the same graphicscard as the main monitor. In Windows it is possible to specify on an app-per-app basis what graphicscard it should be running on. Once I did that for RoboDK, it worked fine.

/RoboticsMan

Hi

I am experimenting with Virtual Reality, I would like to be able to see our cell layouts that we made in RoboDK in my Oculus Quest 2 headset. The headset is connected to the PC via Virtual Desktop. Steam VR is running on the PC, it is working fine. I start RoboDK and tell it to connect to the headset. A window pops up on the PC, showing the view of the headset, and I can see it tracks the movements correctly. But within the headset itself, in SteamVR, it just stays at "Next: RoboDK", and I never get to see the virtual view. It doesnt matter how long I wait. Any clues what could be going on here? I have not tried Oculus Link, since that does not work with my computer for some reason. But Virtual Desktop seems to be working fine for other applications, so I assumed it would be here, too.

Thanks for any suggestions in advance!

/RoboticsMan

Quote from panic mode

just FYI, i am using EKI right now and it is working without issue for quite some time on a headless unit (no smartPad connected). and i chose to make it auto reconnect etc. no matter what. you can unplug cable, reboot robot or restart external application or reboot PC on which it runs, it does not matter.... this thing reconnects automatically user intervention as soon as "stars align" (both nodes are booted and network connection is present).

but that's me...

Well that is nice.

But anyways: The message from EKI_CLOSE() is not suppressed, even though I use

<MESSAGES Logging="enabled" Display="disabled"/> .

The user will still have to acknowledge it. So is it by design only some messages that are disabled, or is it a bug?

/RoboticsMan

Quote from panic mode

you write code that initializes EKI, opens channel etc. all of them are writing to a variable you named RET_VAL but ... you never evaluate it. i see nothing in your code that checks what is in the RET_VAL. you are just following examples from EKI manual... which are very crude... they do not use things like

IF RET.Msg_NO==0 THEN...

IF NOT RET.Connected THEN...

also manual keeps reusing same RET variable. that is not good because very next command is going to overwrite the RET value.

Display More

Yes, I know that I don't evaluate the result, but that is irrelevant for this example, since the error message that I could not suppress is shown from within EKI_CLOSE().

As I wrote earlier: "The problem is that I get the error message when I call the commands, so I never get to evaluate the return value. "

I could evaluate the result all I want, but that doesn't change that the user would still have to acknowledge the message on the KCP first, and that is what I wanted to avoid

Quote from panic mode

and finally you are using EKI2.2

and while you are not into reading manuals, that manual is incomplete, it lacks info messages for example.

as always with KUKA... when things are not doing what you want... check other manuals (newer or older) and you may find what you are after.

try manual for EKI 3.0 ...

Display More

I think it would be a natural assumption that the manual for EKI2.2 would be valid for EKI2.2, and the manual for EKI3.0 would be valid for EKI3.0 and that the 3.0 manual might even be misleading for EKI2.2 . But alright, I learned something new today then. I will keep it in mind.

/RoboticsMan

Quote from SkyeFire

The "Alive" flag that Panic refers to is part of your EKI channel XML file -- you can assign an $OUT or $FLAG to reflect that status of the channel. This is in the EKI manuals.

Yes, I also considered that, but in the end I decided for another solution. But now that we talk about it: Is the alive flag always up to date, even before a connection is established in first case?

/RoboticsMan

Quote from panic mode

why i recommend reading pinned topic READ FIRST and posting some details. such as how to reproduce problem.

"we get an error..." is not specific...

i would say post your code sample, configuration, state exactly what the message as is etc.

Yes, you are right. There was not enough info. Even though I already found a workaround for the problem, I made some code to reproduce the problem, so that I could get the exact error message.

Test case 1: Messages are not suppressed. I try to open a connection twice

DECL EKI_STATUS RET_VAL

RET_VAL = EKI_INIT("TEST_COM")
RET_VAL = EKI_OPEN("TEST_COM")
RET_VAL = EKI_INIT("TEST_COM")
RET_VAL = EKI_OPEN("TEST_COM")

Then I will get the error "EKI00023: Initialization already performed"

Test case 2: Messages are not suppressed. I try to close a connection without opening it first.

DECL EKI_STATUS RET_VAL

RET_VAL = EKI_CLOSE("TEST_COM")
RET_VAL = EKI_CLEAR("TEST_COM")

This results in error "EKI00009: Connection not available"

Test case 3: Messages are suppressed with <MESSAGES Logging="enabled" Display="disabled"/>. I try to open a connection twice, same code as in case 1. This time there is no error message.

Test case 4: Messages are suppressed with <MESSAGES Logging="enabled" Display="disabled"/>. I try to close a connection, even though it wasn't opened first. Same code as in case 2. Same error message as in case 2.

So suppressing the error message only seems to work when opening a channel, not when closing it.

KSS version is 8.3.27, EthernetKRL version is 2.2.7

I am no longer looking for a solution, but maybe this info can be useful to someone else.

/RoboticsMan