Are you jogging/running with Nullframe or with a (potentially incorrectly) taught Tool?
Is your problem around the 'y' axis of world or of the tool?
Are you jogging/running with Nullframe or with a (potentially incorrectly) taught Tool?
Is your problem around the 'y' axis of world or of the tool?
If you have another KCP onsite (say on another robot) you could try swapping that quickly to rule out the key-switch being at fault.
Failing that it is likely the relays on the CI3 board.
we have a similar scenario where we travel down a stack of parts with a vacuum on to pick parts, to an end position with 2 interrupts active:
one is to check for the vacuum ok signal (calls sub routine to save current robot position (for rapid down next cycle) and to return to top of stack with part).
the second it to check for $curr_act[5] <-15.0. (if we meet too much resistance without making vacuum - returns rapid position to top of stack, calls for pallet change and returns robot)
$ON_PATH is true following a BCO if that helps?
In the X55 jumper you need to link pins:
5-7
6-8
If not solved by deleting .freeze, then add faulty G1/KPS600 to the list of possibilities.
Firstly, you say you mastered all axis using ‘dial gauge’ is this the EMD or an actual dial gauge. If you are using a manual dial gauge, are you sure you mastered in the bottom of the ‘v’ and not at the bottom of the leading or falling edge?
Secondly, do you have an external axis (like robot sat on a liner track) which may not be set-up correctly in the project (robot base coordinates wrong)?
Thirdly, are you using the correct robot in your project (using correct machine data)? If your actual robot has a 'reach' modification but machine data doesn't match, this would cause similar errors. (Robot flange coordinates wrong).
If you jog the robot flange can you orientate around the centre of the flange or does that wander off?
in the 'Name' field for the variable press 'return' or 'shift+return' cant remember which, but one should work.
PGNO_FBIT_REFL is the first output of the output range used to reflect your program number.
This is set in Configure > Inputs/Outputs > Automatic External, under the 'starting conditions' tab.
Check out section 6.17.2 of the v8.3 System Integrator manual.
reset offset and symmetry?.... or is that not a thing on KRC4s??
Man that is weird....
I too have seen slippage on the 'glued' shaft joints that started after a collision.... found by pulling the shafts, marking across the joints and checking them later after a noticed shift. Only hard acceleration/direction changes caused shifts; and that was with a big, heavy servogun on the flange. But, as SkyeFire said... you are unlikely the see this on all wrist axis.
Maybe there could be a problem with machine data??
How are the parts presented to the robot? Is there some kind of external axis (like a rotating table) that may be having repeatability issues? create a target on the fixture that holds your parts, see if the robot TCP is hitting that.
What about your actual 'child parts'? How repeatable are those and how much variation can you get from your assembly fixture?
Are you using anything any tech packages like TraccTCP?
I guess the easiest way would be to swap to your back-up HDD that was cloned when your system was working perfectly! lol
Hi Marco,
Sounds like the safety configuration is wrong for your requirement.
If the 'Operator Safety' signal is lost you can choose in the safety configuration how you want to acknowledge it. You can choose 'By acknowledgement button' OR by 'External Unit' (i.e. PLC).
Log into safety config, press 'hardware configuration', the 3rd option down is 'Operator Safety Acknowledgement'.
Changing this should not stop your machine from working, but remember; this will change your safety checksum. You could always take an image first and restore should anything go wrong.
With the software there will be the documentation in a range of languages within the 'Doc' folder on the CD/USB.
The documentation will have a chapter on start-up/commissioning and will tell you all you need to know.
you can open projects created on earlier versions but not the other way round; so if you have the latest WoV you should be good.
You could get the project from an archive C\KRC\User\ProjectRoot\'name of project'. Try opening this and re-deploying to the robot maybe?
As Panic said... being a KRC1, in all likely-hood the flash memory on the RDC1 will have reached its write limit. The 2 back-up batteries allow enough time for the axis positions to be written to the flash memory on the RDC when the power is switched off.
Once the write-limit is reached on the RDC1 it can no longer store axis positions (hence loss of mastering on power-down) and must be replaced (usually for an RDC2 which will not have this problem).
The RDC is the card in the black box (rear base of the robot). If you are doing this yourself, remember to use an ESD strap whilst doing it!
Just to check... What are you using to teach TCP? Are you replacing the tip with a spike or just using a length of weld wire?
If you are using the stick-out/wire; the wire will likely not be straightened perfectly and so will twist/bend/move in the liner as you re-orientate the robot.... resulting in poor TCP.
Excellent.... this is the same argument that has been playing out in my head over this issue!
Like panic said, the Load_data is relative to the flange.... so I am convinced that as the ceiling robot flange, (and indeed the whole robot), is 180° out to the floor robot; then the tool needs to be mounted the same relative to the flange of the floor robot, (making it upside down relative to gravity).
However... Skyfire mentioned he has previously used the same tools on a floor and a ceiling robot without making any changes to LD... were these tools mounted the same relative to the flange of each robot Or relative to gravity/the external environment?
so...
If I drive a floor mounted robot 'x +' in the tool coordinate system (nullframe), the robot drives towards the floor. If I then do the same with a ceiling mounted robot, the robot drives upwards.
Therefore; the tool should be mounted upside down (180deg) on the floor mounted robot to be relative to the flange of the ceiling robot?!