These are defined in bas.src. Where does your bas.src come from? Is it even part of your project and if yes does it have the necessary declarations?
Fubini
Actually, I created the KRC4 Project from the very initial stage mean didn't browse the project from
KUKA robot
I considered as there is no robot present.
and I assigned the all CONTROLLER component in that way
$STOPMESS==TRUE
$H_POS=XHOME
$VEL_AXIS[1] = SVEL_JOINT(100.0),
$TOOL = STOOL2(FHOME), $BASE = SBASE(FHOME.BASE_NO),
$IPO_MODE = SIPO_MODE(FHOME.IPO_FRAME),
$LOAD = SLOAD(FHOME.TOOL_NO),
$ACC_AXIS[1] = SACC_JOINT(PDEFAULT),
$APO = SAPO_PTP(PDEFAULT),
$GEAR_JERK[1] = SGEAR_JERK(PDEFAULT),
$COLLMON_TOL_PRO[1] = USE_CM_PRO_VALUES(0)
I created the new project in Workvisual
I also added controller components in the controller(KRC4) and Manipulator(KR 16 L6-2 C)
1. Cabinet Interface Board (CIB)
2. CIB Safety Module (SION-CIB)
3. Resistor (1.6 KW)
4. KUKA Power Pack 3 20A (KPP3)
5. KUKA Servo Pack 20A (KSP)
6. EMD
7. Safety Interface Board SIB Standard (SION-SIB-STD)
8. 7. Safety Interface Board SIB Extended (SION-SIB-EXT)
and then generate code is applied but still shows above mentioned variables are showing RED
WHY
I attached the Workvisual photos
give me an appropriate solution
HELP !!!!!!
PUBLIC is required in the DEFDAT line in order to allow GLOBAL variable declarations, or GLOBAL DEF/DEFFCT in the associated .SRC file. It's a flag to tell the module linker which modules have what degree of scope.
can you give an example please
how to assign it in program
You should look at doing your dressout/cabling differently, that looks like its pretty tight to me.
Also, looking at the speeds in your program, It doesn't seem like you are really going collaborative speeds, if contact stop is causing you issues, you could disable it in places where it's not necessary. But be sure to do your risk assessment, I'm making a judgement call off a single photo.
I don't disagree with the Tablet TP. As I stated, it has connection issues.
actually, I have disabled it.
at picking and placing zones because the robot makes vibrations due to clamping of the gripper, even though I have added flow control valves on the gripper.
otherwise, in the air moment, I kept it in cobot mode by turning off
the NSI bit
Display MoreI am not a fan of Cobots to begin with, as I feel there are few and far applications that make sense to be Collaborative, and the term gives end users an unrealistic expectation. But let's be fair here, the question was asked around a CRX, and you are basing your opinion off the CR-Series. As SkyeFire states, the force sensing is different between the 2 series. I think Fanuc came a long way from the CR to the CRX.
As far as the CRX goes, I find most of my problems relate to me wanting it to be a Yellow Robot, and expecting it to be the same. They take some getting used to. Fanuc has gone down a path similar to other brand cobots trying to make a robot that is easily deployable, and therefore "easy to program". But the step by step menus, and Icon programming, take away some of the more in depth tools/settings, that (at least I as an integrator) am used to using.
That being said, software wise, I find myself utilizing the conventional TP Views, rather than the Icon Editor or other menus. Being a bit too "Dumbed Down" compared to what I can do on a traditional TP, the guided menus are just a bit of a nuisance.
Hardware wise, they seem to be alright. Biggest issue I've seen is the Tablet TP loses connection. Also, its a touch screen tablet, so dirty fingers, gloves, etc. can pose issues.
Biggest gain, Grab that sucker in Manual Guided Jogging and throw it where you want it. (or at least relatively close. But that feature is not limited to Fanuc/CRX.
I am facing the same issue in CRX 10 iA/L too
and its CRX 10 iA/L TP is not robust
I don't know why FANUC has been providing such poor quality Teach pendant for robust operation
I have uploaded two attachments
1. the APPLICATION photo(MACHINE TENDING)
and 2. communication error photo
Really, is there any strong proof and argument from your statement
hey it's just my suggestions for who is going to use cobots for their automation system
because KUKA has far better system cobots than FANUC
because currently, I am facing an issue with CR 15 iA cobot sometimes it stops even its not in contact with any object even though the part is absent on gripper its stops in the air
Don’t use Fanuc Cobots its contact stop errors sucks
payload is close to capacity
how to disable or remove or bypass this error from Teachpendant
please help me 
hello guys
I have been working on the pick and place of connecting rod project for the last 4 months
I am facing a severe and irritating issue with FANUC CR-15iA Cobot (collaborative robot)
we are running it in the production cycle for the last 4 months
but, Due to contact stop, the cobot has frequently been stopped. that isn't very pleasant for me
because every time I have to press the resume button.
I have grouted the robot as per Fanuc's guidelines.
I also checked the payload execution
and payload with the job and without a job has been declared.
and also used disabled the collaborative whenever it's necessary. as per the FANUC's instructions in "COLLABORATIVE FUNCTION MANUAL"
but still, it stops in the Air even if the robot is not holding the job.
I have shared the photos of the program sample
NOTE: DO 200 is NSI bit (Non-Safety Input) which enables the Robot mode and disables the Cobot mode and VICE-VERSA
After the D200 is in OFF condition its stops and shows "contact force stop" error
PLEASE HELP
WAITING FOR CYCLIC CONNECTION ERROR
You have DCS, so you can utilize this one. DCS position check, Target model collision
This looks at the robot Bubbles versus the tool model. BIG thing is don't let the tool bubbles overlap the robot bubble when you create your tool model. Works really well
[attach='34303','none','false'][/atta
due to the weight issue, I can not use this manipulator as a cobot right now I am using it as a robot
our part weight is 13.80 kg its Connecting Rod(CONROD)
its execute the auto pay load weight in motion and DCS
but whenever I am trying to run it in auto external mode (PLC Master and Robot Slave)
It shows the weight is over load error or force monitoring error
we also designed the gripper such as the CG of the part is in optimum position also cross-checked with Fanuc DATA SHEET excel. Fanuc also verified that this is the okay condition bus still we need to check whether the manipulator is in fault condition or not
that's why I am using the NSI(non-safety input) to avoid the force monitoring input so the robot could run in an auto external mode without giving an force monitoring input
I don't think you can use JPOS or UALM in BGLogic. But you could monitor the system variables for the current joint angles and if they are beyond some limit then drop out the UI Hold signal.
How can I write the program for this can you elaborate
Is this to stop the robot if in a forbidden area?
If yes, this can be even done in BG logic, but the reaction time may appear insufficient for fast moves.Or, probably, maybe done by Interference Check, with fixture models modified programmatically on demand.
If, however, the axis limits are intended for MROT motion, they must be system settings and yes, require a power cycle after modification.
NO
I WANT TO AVOID COLLISIONS ONLY DURING THE MANUAL JOGGING TO PREVENT THE GRIPPER FROM DAMAGE
What are you trying to do? Those variables look to be correct, but they require a power cycle.
DCS can dynamically limit an axis but would require a safety input to enable and disable.
I WANT TO AVOID COLLISIONS DURING MANUAL JOGGING TO PREVENT GRIPPER FROM DAMAGE
How I can give a soft limit to the for the specific axis using bg logic
The simplest solution for your code is to place an END statement or a JMP LBL[100] between line 3 and 4 of your PICK_CONROD program.
My main issue is that it runs without any satisfied condition it's running the sub program
I HAVE DONE simple prog of PICK_CONROD but still runs the priority program
for example, even though the DI signal 22 (INFEED_1 is OFF ) still jumps to the LBL 101 and runs prog PICK_CR_1
and same thing happening for all the rest jump LBLs
It's okay on the monitor
So, the robot is working properly. The issue is the connection between the KRC and SmartPad.
Was this SmartPad working correctly before? Have you tried swapping SmartPads with another robot? Have you checked the SmartPad connector and cable for damage?
yes problem solved the I just replaced the cable with the new one
It's okay on the monitor
Connect a monitor to the krc controller before switching on.
