Autoext kvp+eth only

Hi guys.

After two months with a krc2lr + lbr4 robot, i already have a working system and I’m able to communicate with the host controller (ethernet) and remote io (devicenet). Programs runs ok and i have no big issues.
But… some things are really annoying and i would like to ask you guys for help.
Here is the list:

1) Sometimes the boot fails. Either it doesn’t shows the windows logo and get stuck or stops during the loading bar. I installed a power and reset button on the pci bay to allow me to reset it without the internal batteries holding it on for minutes. It works after ine or two hw resets without issues.
Does it happens to anyone alse?

It’s not always like this. But randomly and rarely But it would be really annoying happening in the final application. I will test with other memory bank to be sure. Ddr 1 ecc type 1gb.

2) any changes of running it in a fully automated mode without even the kcp2 attached, only with ethernet and x11 signals? Now I have the jumper but Im planning to use the external emergency stop and qualify inputs. There is a driver enable there. Don’t know why.

3) i tried the auto external and it looks like everyone around is using it by means of the remote io and plc ro generate the required sequences. I have the wago remote io configured and working through devicenet. But i do t want to waste a remote io on the pc side just to set high and low on 16 pins ( driver en…ecc). Is there a way of setting this mess up through kvp variables? Kvp reads it but doesnt write to these autorxt variables.
Can i map them to simple globals instead to avoid the hw mess and cost? I found the p00 where they set and read them. Can i modify it to do the same with these globals instead of IN[x] and OUT[x]?

4) i also thought about ditching the autorxt idea and making my own auto internal program that does more or less the same without this messy hw (if the hw io is mandatory). The only downside it that i have to manually start the program the first time and indont know if i can seitch of the drivers and brakes in the middle of a program for when it has to stay idle for a while. The program basically respond to program requests from a human user through ethernet. Sometimes it will be idle for a while and indont know if letting drivers and brakes on forever are a good idea.

5) what is the goal of external powering the esc circuit? The robot does nothing without power and shuts off. Does someone have an apolication where this thing is useful? Or should i just use the jumper and be happy?

6) Im using the x14 relay to enable the field supply to avoid any unintended activation of the periphery while the robot is not running. It cuts the power from the field side of a wago remote io using a second relay (I don’t want to open the krc to change a fuse).

I have electronics engineering and embedded programming background. This is my first robot. I read the manuals and found nothing about this part specifically. Seems like they assume everyone has a standard plc and robot cell.

I dont want to waste time putting a microcontroller with lots of isolated inputs and outputs to interface with my pc just to control the autoext without selling a kidney for other ethernet remote io that i already need for the rest of the machine.

Any help about any of the topics will be appreciated the main problem is the autoext without phisical io.

Thank you for your help.

Ok. lots of good answers.

thank you guys

I will go step by step. at first,

Quote from panic mode

6. no idea what X14 relay is

I wrote it without the machine in front of me. the connector for the fieldbus supply relay is the X12. Dual + Single NO contacts that activates when the drives are enabled. at least it closes when i hold the enable switch.

Quote from SkyeFire

This was more useful for Teach mode, as it meant that dropping the KCP deadman would also deenergize the EOAT. Of course, this also required designing the EOAT such that it would "fail safe" on power loss -- having a gripper holding a 100kg object over your head open whenever you let go of the deadman would be... not very good.

I was thinking about the safe state as well. having the "tool open" mode and "tool release" connected to the solenoid's NC as a safe state. thank you for confirming that!

CMOS battery is new. internal lead acid batteries as well. all new.

Motherboard looks like new. no signs of anything weird. I even put a fan on the CPU as it gets hot as fk. changed thermal paste... normal PC stuff.

i'm not using the HDD. I took it of, backed up, copied to a SATA SSD using a IDE-SATA converter. Thank you kuka for disabling the internal SATA for nothing . This SSD is attached to a PCI bay bracket that allows me to remove it without opening the KRC cabinet. really neat. I will try to run a chkdsk on this disk to verify if there isn't something going on. the new rams will arrive soon. Old RAMs does some weird stuff as I remember.

May probably be some bad contact on RAMs or PCI as well. Now is running fine for a long time after I cleaned up the 3COM ethernet board contacts used by the FRI. has anybody used FRI before? would be an option? this robot has the license. It was from an university. The cabinet looks like new. Not even dust inside.

General rule: don't interrupt the KRC controlled powerdown unless it runs really long -- like 15-30min or more. Normally it should take well under 5min.

I'm not powering it down through those "backup" power buttons. That's just for these situations where it may hang up even before the windows has loaded. I had to close that PCI bay as well, so I 3D printed the bracket with power and HDD leds with PW and RST push buttons. I used only once. It powers ON and OFF in 30s more or less with the SSD.

3. using EXT mode requires I/O. most of the signals can be simulated or replaced by variables but few essential ones must be I/O... but Inputs are read only - only IO drivers can write inputs. so workaround is to connect those few inputs to outputs. then you can write to outputs...

Now we are talking, yo.

If I understand well, I can reassign these signals inside P00 or config.dat ( i guess that was the name) to an OUT[x] instead of IN[x] and then write them through the Ethernet using KukaVarProxy? That would solve my problems! at least until I buy a cheap MODBUS TCP relay board just for the matter of controlling the bureaucratic AutoEXT sequence. Please, could you tell me more?

What is "driver enable"? Use specific names -- there's $DRIVES_ON, $DRIVES_OFF, $MOVE_ENABLE, and a few other signals that might be slanged as "driver enable".

My bad. I meant DRIVES_ON.

There are some partial workarounds -- KVP can probably control some globalized variables that can trigger the CWRITE $CMD stop/cancel/run commands (lots of discussion in the archives) in place of the fieldbus remote start. But AFAIK, for $DRIVES_ON, $MOVE_ENABLE, $CONF_MESS, and most of the the related signals, You're stuck with fieldbus I/O. I think you could assign $DRIVES_OFF to $IN[1025] (the "always on" input), but your KSS version probably blocks you from doing that for $MOVE_ENABLE.

DRIVE signals where assigned to $IN[1025] when I got the robot. It was displaying an error then I changed it to a random input and now seems fine.

Thank y'all for the good answers. Now I have some directions depending on the answers to the following questions:

1) As I understand from Panic Mode, the "soft" inputs can be assigned to Outputs (can somebody confirm where?) and these Outputs can be write to from kuka var proxy. maybe i'm gonna need just a couple of signals hardwired to the interface for the HW functions like $DRIVES_ON, $MOVE_ENABLE, $CONF_MESS.

2) forget about not using KCP. Find a good place to store it inside the rack cabinet and that's it.

3) As soon as I get the robot on path (I need to ensure a proper start in a HOME position to avoid a manual/auto BCO run) I can consider that the robot will start running CELL.src after booting and I can command all the process from the host computer. The idea is to avoid the person in charge of the machine to touch anything related to the robot unless something goes wrong.

4) Is there a (safe) way to reset the system (KSS) to factory settings? as this robot was from an university, there are a lot of programs on it and I guess, by looking some config files, that they probably messed around a lot of config files. everything is working (more or less?) fine but I would like to avoid things not working due to unknow mods applied before.

ps: Now I understand the reason why devicenet is being ditched. once it works, it is ok, but from making the cables, inserting isolated power, using those connectors, resistors flying around, the HW cost, the cable I have is quite stiff, protocol is complicated so it is not simple to build something custom (by yourself) that can communicate through. overengineered thang for a couple of IOs.

Thank you SkyeFire !

It is going to be simpler to get any PC IO module, probably a modbus one, and play with these signals as intended. I have to focus on the application.

I had the same impression about this LBR4. looks like a testbed. all the solutions, from this KRC2 hw/mech/sw integration to the robot insides (the way those boards are integrated and the complexity around) looks either overengineered or adaptations made on hurry.

I work with product development, so all the HW development part is my job, as designing circuits, debugging, printed circuit boards and integrating systems at low levels, so certain solutions smells bad. This robot was decommissioned (probably) because of a bad contact of an micro IDC connector inside of it on axis 6 and 1. it stopped completely (sometimes) due to the lack of torque feedback. I fixed it. Piece of cake to me, but for somebody not used to low level HW, the insides of this robot probably looks like a monster.

then all the HW inside this cabinet, the way they are connected feels almost like a last minute project solution.

I will not comment on the fieldbus part because i'm by no means an expert on that. Just recently I developed some fieldbus products (hart, modbus, analog...) and the first hand's on experience is with the devicenet. knowing the electronics behind it and the firmware implementation of other protocols, I tried just out of curiosity to sniff the CAN bus and read some documents about the protocol. would be cool to connect other custom parts of the machine to the devicenet just with a CAN interface. The protocol was quite complex in comparison to an rs485 modbus, for instance. I dropped the idea really fast.

I will build some IO on the PC side for the AUTO_EXTERNAL and report back if it worked ok or if I find any issues (hope not, probably yes.)

btw, almost all I built here was by reading the forum topics. rack cabinet, devicenet, everything under an online-ups, kuka var proxy on the host, first programs, safety interface setup, understanding where to find information in the hundreds of manual pages, io-linking, safety interlocks. Thanks for sharing this kind of niche information.

Quote from panic mode

normally one would just use any IO module (DeviceNet or whatever) to add some I/O to the KRC. then place jumpers between 4 outputs and 4 inputs and map them to essential signals like move enable, drives on, confirm messages and external start.

this way state of those inputs are yours to control... by writing to outputs that connect to mentioned inputs.

i have not tried it but IOSYS.INI also has a section [IOLINKING]. perhaps one can accomplish the same without hardware I/O.

EDIT

ok, just checked comments on IOLINKING and it it is not suitable - it operates only as output following input, not the other way around. there is also VIO but have not messed with that either.

Display More

Sure panic mode . I'm already setting up something here to give me some IO's on windows side. the problem is the host computer side, not the KRC, as it already have the devicenet module up and running with a bunch of IO's. the PC is the problem. I need an interface just for that.

but you convinced me. in the end, it is simpler to use the things as they are supposed to do, if the focus is the application, instead of hacking the device. I will probably use a modbus TCP wago 750-363 for that. the dowside will be to bring all the cabling to the cabinet instead of making it distributed at machine level as the host computer and the KRC2 controls different things at machine level. nobody is gonna die.

now I learned as well that the absolute minimum IO's are 4I and 4O. I was wondering which of them where strictly necessary or optional. almost 20 signals sounded a little bit too much. there was where the desperation began.

Quote from panic mode

the DeviceNet or whatever I/O does not need to connect to PC.

It is enough that KRC can access the I/O so that you get something like:

KVP > Write KRC variable (or write an output directly but... writing an output from an outside world can have limitations... perhaps for that controller must be in correct mode, drives must be on or similar...)> so just have Submit process the data further (add conditioning if needed etc.) ...(Submit can do this regardless if drives are on or not... > output turns on/off as requested... > output is physically wired to a related input so input will follow state of the output... and that means System will perform assigned function when input is set or triggered (for example clear messages, turn drives on...)

as stated before, use EXT mode and you can do anything without touching teach pendant:

1. move enable... you do need to be able to control this. if anything goes wrong, you need to be able to stop robot instantly. this is it.

2. confirm messages... this is essential, must be able to acknowledge messages or robot may not be able to move.

3. drives on... also essential. without this one cannot enable drives remotely.

4. external start. this is needed to issue start from external controller (PC/PLC).

Display More

I get it.

making it short... perform the gimmick by HW jumpers, as the sw has some stupid limitations. cool idea. thanks!

I will clean up this KSS installation to have all the ports reset to standard values and avoid previous mods (university robot) causing problems, then assign a list of outputs to be written by KVP and fed back into the input modules at least for these 4 signals. fortunately, I have enough spare IO modules to use.

bye bye driver-enabled signal for field power supply switching with this solution. it will be always on or use a different power rail in the future.

update: the io expansion i had here was an Ethernet/IP wago 750-363. it didn't work in modbus mode and no common software uses this EIP protocol, like the bloody devicenet. no way (at least for me) to use any standard windows sw to make some external IO.

Hi guys.

Just bringing some updates. Maybe you guys have some hints.

Since panicMode's advice on HW signal loopback I performed the following steps:

1) found out a lot of limitations of cases when you can actively set an OUT from KVP in autoEXT. I found two variables to override on $config.dat to enable these interfaces (sorry but I don't have the sw here now to get their names. something like external IO enable.

2) after that, I tried to make SUBMIT send the signals and it worked ok, it runs on boot and can use an intermediate global from $config as input. for some german reason, I cannot simply associate the variable value to an OUT[x] and I have to perform an if/else then true/false for each one but not a big problem.

3)everything I read in the manuals assumes that you have a classic PLC in a 1wire per bit configuration to send the program data. I read P00 and noticed all the mess it does to bit-bang the data and transform it from physical inputs to an internal variable.

In a scenario where you are communicating through Ethernet, this is not needed because the lower layers of OSI takes care of the error correction and things alike, so... I started modifying the P00 program with a new case. Ethernet PGNO.

4) Of course I didn't know it this thing would work or not. I created a PGNO_TYPE 4 and forced this mode on $config (because the UI doesn't allow to set it to 4 as a normal gentleman) and wrote the CASE 4. It just displays a message to be acknowledged saying that its using Ethernet PGNO mode. This mod is done both on PGNO type and where it read the PGNO afterwards.

5) I wrote 3 stupid programs with random moves starting from #HOME, resetted the controller, first MOVE_EN, Ack message, Start program, it showed me the message I wrote before, Start program again and... It WORKS!!!

In essence, it needs 4 inputs (and outputs as well because of the loopback on HW through the devicenet).

the weird part is that it turns the drivers on automaticaly from the first boot but, if you touch anything, it needs a reset or a manual drivers on signal.

I noticed that this controller has the same teach pendant HW signals on X11 as well, as the dual channel stop switch, drivers ON, drivers OFF (single channel) and mode selection (AI, T1, T2 and AE). I tried a jumper for drivers ON and it works the same as on the TP.

Questions on my mind:
With the same signals on X11, theoretically I could run without KCP in auto mode through X11? I don't need it but, just wondering.
Did I do anything stupid editing P00 to avoid the Old School checks and just accept the PGNO value?

If i keep the PGNO number (that I can read back from the variable) I just have to acknowledge the movement and issue a program start and it runs again. Any comments about doing something stupid?

The final cell will just have to wait for a human to perform a selection from an user friendly HMI and the PC in control of the KRC will receive the program number then set PGNO to start executing. this PC takes care of the entire cell as well, startup, accessories and other stuff, as I don't want to rely on the KRC for these upper level tasks because I'm considering making a second cell in the future with a more modern robot as a R900 SIXX KRC4. My idea is just to adapt the individual receipts (programs) and points/tool/workspaces.

all these tests where done with push buttons to be fast, now I will come back to the SUBMIT loopback and automate from the host PC. Any advices?

last point. has anyone used the circuit from the datasheet to enable the drivers in autoext mode that gets a signal (aparently) from the MFC to close a relay contact to DRIVES_EN on X11 using the voltage from the ESC (x14 I guess)?? I want to be sure before doing something stupid with the MFC and wrecking my startup's bank account 4 figures down.

Thank y'all for the help and I will keep the post updated with the progress in case anyone else needs this kind of information.

Quote from SkyeFire

Not sure what you're going for here.

Neither me. I posted the datasheet section that says you should perform that wiring to be able to turn the drivers on in auto ext.

in the doubt, i will do nothing. Is working for now.

hi panic. I have some updates.

shortly, everything is working now.

I edited the P00 and added my case as PGNO type 4 and force it through the system variables, so there is no changes to the rest of the system behavior, except that it doesn't performs all those checks that are useful when wiring up bit by bit to a plc to set a program.

it simply waits for PGNO and check if the number is in the range of the available programs. Done!

Then I declared some proxy variables to control the critical signals as drives on/off move enable and program start from ethernet. SUBMIT takes care of translating that to the HW loopback (your Idea of wiring up the outputs with the inputs at the devicenet remote io) and normal mapping from the autoext IO. just 4 signals because I want to have the drives off as well for prolonged Idle periods.

I developed a PC application that abstracts all the low level part and gives me (for testing) a simple gui with program number, robot status, init, run, pause, continue and stop. works like a charm. An WiFi LBR4!

My doubt about the drives on signal wasn't about signal levels or edge detection. I'm an electronics engineer and I develop boards and microcontroller stuff btw, so I'm quite aware of all this stuff (just to give you a background). but thank you for point it out anyway. I've seen that part in the datasheet and nowhere else (the picture attached on last post). the pinout of that MFC connector is not described anywhere I looked at, so I got a little bit reluctant to wire 24V to one essential (and expensive) expansion board without having a full documentation of that connector. is there any advantage in performing the drives activation through that interface?
currently I'm using the "out[x] directly wired to two relays that toggles them high and low for 300ms at X11 when I want to toggle the drives state, directly from an ethernet command.

am I being paranoid by using 3 different isolated power supplies on the devicenet? I have a tiny one (15W overkill but was the smallest I found) for the fieldbus, other for the devices themselves (remote IO logic, all of them together, 48W overkill as well) and other for the field side (48W), relays, sensors ecc.

thank you guys once more. I have a lot to learn about the robot automation part, because everything is meant to be done in a certain way and you don't have to build circuits from scratch as i'm used to. I don't know if and how long I would take to solve these small issues that blocks the development, without your help. I'm relieved seeing the orange snake twisting around!

cheers.

I totally agree with you, panic mode .
we do these same best practices on embedded software (firmware) as well. But some times we have to go down the rabbit role due to limitations of the platform. what we do is to document it.
Btw, I got a RS485 to IO (8 opto inputs, unfortunately NPN, so I have to add some pull Down resistors manually, and 8 relays spdt) so these files will probably be brought back almost to original state. I have backups of everything, actually the entire system. Unfortunately kuka considered that everyone will wire up bit by bit to a PLC and never use a higher level system through Ethernet, so those routines messes up with the PGNO once you write externally and it tries to read from whtf IN[[PGNO_FBIT[x]] is set to.
anyway, now with the PC IO I can get rid of the 4 HW signal loopbacks and just keep the PGNO type 4 switch case that I created. But your loopback solution made me advance before spending money on it avoided making stupid shit.

SkyeFire Thanks man. I will keep it as it is and just use the RS485 relay outputs for it instead of the loopback. what matters is that the system is working as it is. so lets keep that MFC$$$ right there where it belongs to, doing her devicenet duties.

About the power part, I really ask to myself how crappy a PSU should be to make all this mess. I made A LOT of power supplies in my life, almost for every PCB I made in my life, and in order to mess up a bus communication, worse yet, a CAN bus communication that is already isolated from the rest of the system, so no internal ground loops are possible, you have to be a little bit creative.
I'm using simple DIN rail supplies from MW (who knows if original or not) and from the scope, the outputs are pretty clean.
Also, in industrial or aerospace, the power supplies has a LOT of voltage range. The last one I made for an industrial ultrasonic flowmeter was from 9 to 36vin and would survive even 42.
The problem is that you never know what they used inside there so, as you said, better to be safe keeping it around a couple of volts of the nominal.

Guys, thank y'all once more and I think that I will wrap up this topic here. I'm gonna make the gripper for this guy.

Cheers from Italy.