Posts by panic mode

Eso sí parece código KUKA.

El problema es que se usan llaves para asignar el valor de la estructura... pero el contenido de esas llaves debe ser literal (valor codificado). No se permite ninguna manipulación ni aritmética. Por eso el compilador se queja...

La solución alternativa es usar otra variable y manipular un elemento específico de la estructura.

Ejemplo:

DECL E6POS temp_pos

temp_pos=xdd ; copia el valor de Xdd a la variable temporal. Esto copia TODOS los elementos (X, Y, Z... E6)

temp_pos.X = xdd.X + 5; esta línea solo modificó el componente X, los demás elementos conservan su valor de la instrucción anterior.

LIN_REL temp_pos ; mueve a la posición modificada,...

KR200 is a robot arm... you need to know controller type (KRC type).

in general, all KRC types that are powered by 3phases (KRC1, KRC2, KRC4, KRC5) are meant to work on 400VAC. that is voltage that they can work with without transformer. all other voltages require transformer (240VAC, 440VAC, 480VAC, 600VAC).

newer controllers (KRC4 and probably KRC5) can be powered from wider range of voltages without transformer (400VAC, 440VAC, 480VAC). however this requires modifying WoV.

when supply voltage is too low (240VAC) or too high (600VAC) there is no other choice but to use transformer.

as i recall batteries are tested very infrequently and i would guess that observed is simply a coincidence. coincidences become a pattern only when they happen several times in that same situation.

message refers to pair of 12V SLA batteries, not counterbalance. there is no sensor on the counterbalance.

my experience is that 80% of motherboard failures are that same thing. the other 20% are Ethernet port getting zapped. for a pricey industrial grade motherboard, i would expect design that is more protected. TVS diodes are dirt cheap - we are talking pennies...

this message is displayed by KSS and removed by user.. that is YOU...

so for messages to go away YOU must:

1. navigate to message window (it will turn blue)
2. press button "Ack All" or "Confirm All"

... unless there is a compatibility issue as mentioned by Fubini

For KRC to control an axis as its own it would need to use own drive (KSD) and feedback (resolver connected to RDC).

I have seen but had no time to investigate where 3rd party servos (Siemens) were used as external axis. This was done by KUKA Systems. They behaved like normal robot axis but i noticed that they were only running very slow.

accu voltage has nothing to do with this. intermediate circuit is basically DC bus... it is what powers inverters... when drives are enabled bus voltage goes to some 600VDC. when drives are disabled, voltage drops down... this is not instant and it is one of things that robot checks for "ready to move". others include safety circuit state, etc. one of them is also delay from enabling switch.

Quote from PhunxamLinda

when I press the trigger switch and press the move charges then (("I" is green in "SIR"), then the Robot can move. but when I do the same job but (("I" is red in "SIR") the Robot cannot move.

that is correct and expected behavior.

Quote

I don't know when the Robot can move and when it is prohibited.

what do you mean by that...??? you just stated that it works when drives are on ( "I" is green). that was expected behavior.

Quote

The problem I have here is that the screen always shows the error "1376 Active commands inhibited"

what do you mean by that? this message should disappear when acknowledged. are you sure you are acknowledging messages? maybe the KCP button is stuck...

use blue button on the left to switch between windows until Message window is active. then the buttons will appear in the lower right corner (red highlight) to acknowledge single or all messages. part of working with KRC2 is to constantly go through this routine and keep acknowledging messages.

The window that is active has same bluish/cian color like the button on the left. in image below, active window is the Robot position (has the cian frame)

my guess is that it is just the timing issue of when drive indicator comes on and when you press some key to move it...

acknowledge all messages... press and hold enabling switch until drives are on (("I" is green in "S-I-R"), and then press the jog keys. if you still see the problem, something is not right. could be worn out switch or sticky safety relays...

if the terminals 37 and 38 are pins on X11, that means you are using single channel of the EStop circuit to drive some relay. then relay contact is tied to some input on your laser. and another relay contact is driving sound alarm. this of course can work but without seeing entire installation i cannot say if i agree or not.

if the cell is properly guarded so robot cannot just turn around and start blinding people or cutting them in half, and one cannot access the robot area without shutting down the laser, this may be ok, at least functionally.

if that laser input is a safety input and the only protection - then answer is categorical no. first problem is that you are only using single channel. so you have no redundancy. but even if you turn your relay on through both X11 contacts (37-38 and also 55-56), your relay is also a single device (so by definition there is no redundancy). and also it is probably a general purpose relay, that is not safety rated. for a safety application that relay would need to be monitored by a safety controller which is not the case. and it would not qualify for more than what you have even if you:

a) put two of them with monitoring relay or
b) replace them by two safety relays but without monitoring relay.

in general one should not mix standard and safety components or IO. one notable exception is using higher grade device (safety) for lower grade function (standard) if this is used only for annunciation or display but ... not as a safety interlock.

do you mind sharing your solution?

so use it...

or...

try downloading and installing latest version of WorkVisual. that is the way to get KUKA device description files.

wait.. what?

KUKA does have several communication options but none with the name of KUKA.Ethernet.MS

there is KUKA.Ethernet/IP which is one of products with an M/S in the name (master and/or slave). this is a fieldbus that can be used with some PLCS like AB, Omron etc.

there is KUKA.EthernetKRL which is also paid option that allows TCP/UDP socket communication (client or server or both). Pretty sure this is what maleza was thinking of.

those official KUKA packages are of course not free.

if your robot has them - good for you. you may also check for others like OPC or DeviceConnector.

but if none are already installed and you are looking for communication option that is free, your best bet is to pick one of proxy servers developed by users:

KVP (Kuka VarProxy)

KVP for KRC4

C3Bridge

Quote from LucassNieva

The 24V are on the X253 signals.

woah... why are you doing that????

i would recommend to stay away from any internal circuitry and specially naked boards (CCU, SIB, RDC...). same applies even for trained people who are familiar with ESD, and know the actual pinout of the connectors, how to interpret schematics etc. because one mistake or slip-up and you can have things damaged... or worse.

if you want help, you came to the right place but... to get correct advice, you need to follow instructions and answer asked questions. which you don't.. and it was asked several times already ("on what exact pins did you measure ..."). post #2 shows exactly where EStop status should be checked. but you did not... and it took some effort to extract from you that you are messing completely different circuit. because you do not know the difference between input and output?

inputs are signals that robot can sense. the EStop button is wired to one of internal inputs and not to X11.

outputs are signals that robot generates. and the EStop status is one of those generated signals. this signal is active (contact closed) when robot does not sense any EStops (this status combines several input signals, not just one from smartPad).

and as herman says, you are not qualified to do this. you need someone that knows much more. not just electronics but also understands safety circuits and robot safeguarding.

you did not even state what kind of laser you want to control. if this is a sensing laser (Class I for example) they are not dangerous but could be annoying or irritating if they are shining beam of light while moving. this mere annoyance can be dealt with easily, even without safety rated circuitry.

but if the laser is powerful enough and can cause harm to humans (damage eyesight or burn skin) like cutting or welding lasers, then linking them only to an EStop is unacceptable. in this case cell guarding must be used also monitored and part of safety interlock.

Quote from LucassNieva

The problem I have is that the signals from my X11 do not change state when pressing the emergency button. I’m not sure if this is due to a configuration issue.

what is the configured safety interface? if X11 is installed, most likely that is the safety interface - unless someone bypassed it and decided to use one of fieldbus based options (ProfiSafe, CIP safety or FSoE).

no problem. pretty sure that i do understand your objective and you do not understand replies.

be precise...

there is more than one KRC4 type and more than one X11 type. you did not confirm which one you have and what pins you are trying to use for this.

outputs from X11 are dry contacts (potential free contacts). there is no 24V or 0V on them - unless you bring voltage to those contacts.

If nothing is connected to X11 interface, you can measure such voltage on the safety input circuits. But that is wrong circuit... You want to use KRC safety output circuits.

you did not answer my questions. be precise...

how are you testing? are you able to move robot? if so what is the status at the safety outputs? do you know how to test relay contact? measuring voltage will be fruitless if this is not wired into a circuit. if not wired, one would have to test it with continuity tester or ohm meter.

do not translate messages yourself... that is meaningless.

change language to English on your teach pendant and then take screenshot of the messages. post the screenshot and then change the language back to Portuguese.

and when you have problem with a program, post the program so others can see it.

do not post large things - duplicate your program then trim it down to something short that still reproduces problem. then share that reduced program.

you need to be precise.... how are you testing?

and what do you mean by "they do not change state" when pressing EStop? what is the state?

are you able to move the robot? if you can move the robot, EStop must be ok so those contacts must be closed.

KRC4 controller manual shows EStop status on X11 are two contacts, terminals 37-38, and 55-56

so you can run power to your outputs through those contacts. but... if anything goes wrong (overload or short circuit) you are going to damage the SIB board and that is going to be expensive...

so better idea is to only use those for signals and let the heavy lifting be done by something external and lower cost.

you can add safety monitoring relay to monitor X11 EStop status. then you can use contacts of that relay to control the power to your outputs. chances are your monitoring relay contacts have low current ratings, so you would likely need to add a pair of contactors and have them monitored as well (by the same monitoring relay).

Akkus are batteries shown in post #11. they are either old/defective or PM1 is defective or there is a bad wiring/connection.

A lot of problems can be traced to bad wiring. i have seen case where tapping finger on the middle of KRC2 door causes reboot. problem was badly routed cables so they got chewed up by opening and closing cabinet door.

i do not know what "Atomat" is.