Kuka robot project and difficulties

soft limit value cannot be +/-360 deg. reduce that to +/-358deg.

the only time larger value is possible is when axis type is endless because in that case soft limit is ignored.

also there are two sets of machine data:

- robot MADA is in KRC:\R1\MADA

- controller MADA is in KRC:\R1\STEU

each MADA is a set of files. here we are focusing on robot MADA, which is following two files

- $machine.dat

- $robcor.dat

one thing to note about MADA is that one may not add or remove any lines,.... or you get message that MADA is corrupted.

to see if any line is added or removed compare robot MADA with factory MADA that is on D:

Quote from Oatesy

Having a bit of trouble with the SPS. The SPS folder is empty and when I click on it says "no objects" on the other hand there is a SPS file under archive/disk/krc/r1/system. When i try to access it on the kuka it says "command not available".

The default location for SPS.SUB is in /R1/System/

Define "access" -- are you using SELECT, OPEN, VIEW ERR, or something else? Note: using the "enter" key counts as SELECT, which you don't want.

What user group are you logged in as when you try to access the SPS?

If using OPEN on the SPS doesn't work, try manually cancelling the SPS first. That should be under the CONFIG menu. The 'S' icon in the bottom of the KCP should be grey (green is Running, red is Stopped). Normally, just using OPEN on the SPS should do all this automatically.1

The brute force method is to copy the SPS off, edit it with a text editor, then copy the edited version back into the robot and overwrite the original. You still have to Cancel the SPS before doing this though. Unless the SPS is cancelled, the system won't allow the overwrite, and using OPEN will generate a "file opened read-only" message.

We are so close.

Third time lucky, we removed the 7th axis as it was part of the original setup and getting back to basics brought it back.

Does anyone know what Cross3 is?

It looks like a sub folder....

I'm writing from memory so I might make a mistake.

Under the monitor tab.

Pretty sure this is associated with Cross3.

I see 3 red I/O radio buttons.

Effectively not enabled X 3.

Guess it's communication from the remote Alena computer we did not receive with the purchase.

Working on a work around.

Dave

Quote from Oatesy

These are the fault codes still present.....

Number	Source	Message
1541	KCP	Machine Data error
256	M.DA….	Erroneous DSE axis assignment E1
259	Loader	/R1 machine data loader aborted

Display More

Pretty sure those 3 errors are all interlinked. 256 is probably the key, causing the other two. What is the actual source of 256, when it's not truncated?

My first though, looking at Error 256, was that $DESCHANNEL[7] was set to something other than 0 in /MADA/$MACHINE.DAT. But the copy of the file you posted shows 0 for that setting.

Also check $SERVOFILEKPS7.

The MFC and DSE make up the "double stacked" PCI card plugged into the motherboard. The DSE card is the "input" from all the servos, and connects out to the RDW card in the robot base. The RDW takes the analog signals from each servo resolver and converts them into digital data channels that are sent to the DSE.

Every servo connected to the KRC has to have its own DSE channel. Normally, it's strictly linear: A1 is on DSE1, A6 is on DSE6, E1 (axis 7) is on DSE7, and so on. But some configurations can change that, like setups where two servo motors drive a single shared physical axis.

Just spitballing, but try checking $PMCHANNEL -- they should all be 0. Also check all the $SLAVE_xxxx variables. All of them should be 0 except for $SLAVE_LOOP_FOL_CRITICAL, which should all be 1.

Hmmm... Error 259 should only happen when the number of errors generated while loading MADA exceeds the size of the message buffer, which is thousands. Check your $MACHINE.DAT file in a plain text editor (I recommend NotePad++), with the "show all characters" turned on. Look for any unprintable ASCII characters that might have sneaked in somewhere. Especially at the top of the file, check the very first lines. Make sure they look something like this:

&PARAM VERSION = 23.0.6

&REL 16

DEFDAT $MACHINE PUBLIC

And ensure there are no blank lines before the '&' lines. That can throw the compiler into fits.

Watchdog error points to a bad connection between the KCP and the cabinet. in the worst case scenario the cable itself is damaged, but more likely in my experience is a bad connected plug. This could be a in the connector to the cabinet, but also on the connectors on the ESC board. So check for connectors that are not seated properly or pins that are bent or pushed into the connector.

Quote from Oatesy

Thanks SkyeFire. It worked perfectly. We are down to one fault code

What worked? What did you have to change?

To expand on Leon's comment regarding the Watchdog error:

The KCP has a CANBus connection (IIRC) to the KRC to carry the signals for the various soft keys. The Teach/Auto key switch, Motor On/Off buttons, and the E-Stop are all individually hard-wired back to the KRC. And the video signal for the display is... I want to say VGA, but it might be converted for the LCD driver.

All this means that the main culprit for a "KCP watchdog error" (which isn't documented in any of my manuals, sadly) is probably the CANBus, since the other connections aren't interactive that way -- the "hard" buttons would all produce their own unique errors.

If the KCP connector to the KRC is a small, cylindrical connector, those connectors are easy to damage unless you're quite careful with them. The most sneaky failure mode is for one (or more) of the pins on the cable side to be pushed back into the housing. They can look fine, but still be loose enough that, when plugged in, the pins get pushed back into their housing instead of being driven into the socket. To check this, test each pin gently with some needle-nose pliers -- they should resist being pushed back into their housing. Sometimes, if they have been unseated, pulling them to full extension can re-seat them, but that pin will always be a bit "weak" afterwards. All the pins should be at the same height, except for the ground pin, which should normally be a bit longer and thicker.

To avoid damaging the connectors this way (the resolver connections on the motors are the same!), always be very careful about aligning the connector precisely before you begin screwing the mating threads. It's sadly easy to get the connector slightly off angle, and never know it. Screwing the threads down has so much mechanical advantage that pins can be easily unseated without "resisting" enough for you to notice.

Quote from SkyeFire

What worked? What did you have to change?

Skyefire,

We made the mistake of assuming the hard drive status.

We fixed a fair bit by removing the 7 axis for the 3rd time. (I want to laugh but i cannot...... well I can now but talk about frustration ) It came back when we reverted back to 7 axes when loading the original hard drive image.

Yes, three times, but in our defense we did make mistakes when we did the first and second 7th axis removal so we started again with an original HD image.

Interestingly we used the notes from page 3 of this thread to remove the 7th axis.

I am taking a recreation day to visit Chris on Friday and we will go through this methodically.

What are the chances someone has the KCP cable pin out diagram?

Important note.

We have been digging around.

The Alema computer (That we do not have ) must of had significant control of the Kuka. One of the cables from the KCP to the main control board C13 cannot be mounted as the header pins have not been populated on the C13 board in the factory. As a result the 6 way mouse and tactile buttons do not work. We have been using an external mouse to configure the PC.

Apologies for the poor quality photo. the connector is mounted somewhere low on the board in I think location 20.

More in next post.

To clarify the above, The factory has the cable and socket on the KCP for the 6 way mouse and buttons but the factory did not populate the header pins on C13 for the cable.

We have been using an external mouse and I want to solve one issue at a time and not introduce complexities but here we are.

I have purchased this header pin to populate the C13 position 20 (21?) location (Right now it is just solid solder in the 6 holes.) I fear there might be more to the circuits and firmware than just adding the header pins but it is worth a shot.

you mean CI3, connector X5? if so, that is not keyboard and mouse, it is a safety circuit and should always be populated...

The 6 way mouse can not be used as standard mouse like your external mouse to control windows. It only can be used to move the robot in manual mode.