you are looking at it the wrong way. kcp2 is just a teach pendant and it is a non-intelligent device (like a terminal). you interactions are actually with KRC2 (robot controller) and operating system (KSS) that runs on it. so you need to get documentation on your version of KSS.
Xpert is the way to go when it comes to documentation though there is quite a lot in the downloads section of this forum
yup...
there is a function
GET_SIG_INF (CHAR SIGNAME[24]:IN)
but i have not found SET_SIG_INF or similar...
you could write something like
SIGNAL es $IN[1] to $IN[4]
SIGNAL fr $IN[5] to $IN[8]
SIGNAL de $IN[9] to $IN[12]
SIGNAL jp $IN[33] to $IN[36]
etc
and read it like
$OUT[666]=Get_Signal_Bit(es,2)
DEFFCT BOOL Get_Signal_Bit(sig_value:in,bit_pos:in)
DECL INT sig_name, bit_pos, temp
SWITCH bit_pos
CASE 1
temp = sig_value B_AND 1
CASE 2
temp = sig_value B_AND 2
CASE 3
temp = sig_value B_AND 4
CASE 4
temp = sig_value B_AND 8
DEFAULT
MsgQuit("Nope...")
ENDSWITCH
RETURN temp>0
ENDFCTwhen you see fault and robot stops, navigate to ext interface monitor and look at the values. everything is there. or... create own monitor using ConfigMon.ini
please read pinned topic READ FIRST and as always, approach challenges more strategically. forum is here to guide you, not do work for you.
so show your effort:
check your robot KSS version and ServoGun software version. post them here.
check your ServoGun documentation about this topic. it will tell you if your ServoGun software version supports this or not (perhaps you are using a really old robot/software and this may not be available).
if feature exist in your software version, try it out. software that supports this should have inline form instructions for this.
if it does not, you would have to develop it yourself.
and if you have a specific problem or question, feel free to post it here.
as far as i can see this was available for years:
is the OfficeLite running? did any of the network settings change? was it working before?
if you are using reflection of PGNO, there is no point in calculating parity. and could be calculated wrong.
parity is a poor man solution to check if value is correct. it reduces error check to a single bit. using reflection one can compare every bit. result of that comparison should guide you to specific bit or I/O channel to troubleshoot.
so when you see the issue, get all values (PGNO sent, PGNO reflected, parity value) and check them out.
what is the environment? did you check the wires/cables themselves? nothing pinched or scraped? how long is the I/O cable and how is it routed? what type of I/O modules exactly? more specifically what type of outputs and what current is sufficient to activate the inputs?
relays outputs are simple to work with as nothing seem to bother them - they will work with AC or DC or whatever. but relays are far from perfect because they wear. one of the problems are the minimum and maximum current. high current obviously erodes contacts and possibly makes them stick (weld). but inputs draw very little current and many are unaware that relays contacts require some minimum current or the contacts will deteriorate. this is called wiping current or wetting current (it cleans oxidation or contamination of the contacts). to avoid this one can use gold plated relays but i have never seen those in outputs cards, but they are common in instrumentation etc. so if your devices have inputs that only draw 1mA or so when energized, do not expect longevity from relay card rated for 2A per point unless you deliberately increase current. this can be done by adding resistors across inputs to get some 5-20mA of current.
finally what is the exact EXT setup and what program number fails to run when you get this error? with this you can narrow down search to specific input and output.
What happens is whenever they cycle the cell, or randomly it seems, the robot will lose reference positions.
there are different types of encoders. most robots use pulse counting (quadrature encoder) or resolvers (sort of rotating transformer). few use true absolute encoders (they know position any time, regardless if axis is moved by servo or external force while servo was switched off).
to compensate for this, it is common that non-absolute feedback types store information somehow.
on axes with pulse encoders, counters are keeping track of position, so even when robot is powered off, there must be battery to keep counters alive.
most common problem here is batteries failing or accidentally disconnecting them (or power).
resolvers are absolute feedback but only for rotation that covers single motor pole. most motors are 3 or 4 pole. on a 3-pole motor, resolver is absolute for 120deg of motor rotation. on a 4-pole motor, it is 90deg. so if external force somehow makes motor shaft turn precisely 120 or 90 deg, robot will not know that position was changed. fortunately such exact movement is highly unlikely so changes are easily detected by comparing to previous value that was stored somewhere.
but... if data is also lost while robot is powered up, something else is going on:
1. broken wire or oxidized connector contacts.
2. strong interference from some source of noise (or defect in the robot itself)
3. lost encoder shielding ground connection
4. ground loop when encoder shielding is grounded in multiple places. if installation is purposely done with shield grounded at both ends, then shield itself must not carry significant current (add external GND conductor with large wire size). this is common on robots used for welding, plasma cutting etc where strong and high frequency interference is present.
5. worn out cable. when flexed for too long (or too much) strands in cable may brake. flexible wires (and shield) are always multistrand so single break is not an issue.... unless... the end of the broken strand is digging into insulation. this becomes easier with higher temperatures (insulation becomes softer) and faster motions (inertia of the cables causes increased wear). so what happens when one of the demon strands pearces insulation and touches GND or another encoder wire? yes, it would be pretty much like what you are experiencing. to troubleshoot this one would need to replace encoder cable and run robot to see if issue persists (at least temporarily, does not need to be pretty, can be hanging ). the other test is insulation test but you would want that done carefully by someone that knows what they do so you do not fry anything, because insulation test is done with high voltage (500V, 1000V, ...)
etc.
note:
if only one encoder is disconnected, only that axis should be affected.
but if multiple encoders loose positions simultaneously, then it must be something that is common to all of them... an example of this is a loss of supply power to encoders or their logic boards (counters/RDC/whatever). so perhaps replace batteries by some temporary source (must be suitable voltage) such as another battery or even power supply. intermittent power loss in a circuit can be monitored using suitable devices (power analysers, loggers, electronic version of trigger latches etc.)
if you have more robots of same type, you can try swapping parts until you have narrowed it down. good luck...
couple of points could be the problem if they are close to each other and not forming smooth path. i like to eliminate as many points as possible.
that looks ok but everything shown is only standard signals (control signals). you also need to consider safety aspect and make sure that spindle can only run if operator is safe. planning ahead goes long way to avoid issues. for example getting VFD with STO, means one can omit external safety contactors. one way to confirm that spindle is not running is to use safety relay to monitor for zero speed.
if your robot has suitable I/O or fieldbus - yes.
showroom setup
spindle needs spindle controller. this is what powers spindle and allows control of the spindle (start/stop and speed). could be electric or pneumatic or whatever...
spindle itself mounts on the robot. different types of spindle exist (size, type of power,...).
spindle controller goes into some electrical cabinet, usually on top of robot controller. this needs to be powered and interfaced to robot. interfacing means wiring and programming. type of interface is also not something generic - may be using digital and analog I/O, may use fieldbus... so everything is product specific.
once the spindle integration is done, then robot program can use it.
that will depend on your spindle controller requirements
that connector is underrated, should have been something beefier instead of simply doubling contacts - they never share load perfectly so one contact will always suffer and once it is gone, the same happens to the other.
same goes for the A1.X302. it supplies power to SIBs, and I/O... anything feeding power to user circuits (in this case I/Os) should be protected separately. I/Os are something that users expand and wire. one mistake here should not take out safety boards.
A1.X3 is a brake power... has nothing to do with RDC
if the gun is stationary (not mounted on robot), yes...
Yes, that is the RDC box. And E1 feedback cable is the one at the bottom of the picture.
as them messages state, there is a problem with wiring of the encoder.
are you using KUKA cables? if so, one can still get problems if cable is not correctly brought into RDC box. Usual issue is that shield is not connected to the RDC box.
if cable is DIY, there are other things that can go wrong.
