Alternatively i think you could send your weld established signal from the robot to the PLC
I think tha's not going to work - "arc established" or actually any signal related to welding feedback requires 100% override, because welding won't be started until the robot is set to full speed.
did you assign the F-address to the ProfiSafe module? Did you configure it in the robot's ProfiNet Safe settings?
try this on the pendant hit menu>0>8 (browse) select Error/Diagnostic File then TP2Menu.DG or TPMenu.DG this should give the id. you should see the soft part ID and Screen IDyou will need both of them.
Hope this help
There is an easier way to do that: split the screen in 2. left half will be used to navigate to different menus, right one for reading out the variable. Switch to right screen and go to MENU > System > Variables > $TP_CURSCR > $TP_CURSCR[1]. Now switch back to the left window and go to whichever menu you wish. The right screen will show $SP_ID and §SCRN_ID of that menu.
Hi there,
I am getting pretty confused: I have a backup of a robot, that uses PMC to start RSR programs and it works. But in RoboGuide it seems, that the UIs used to start these RSRs seem to be ignored. Is that normal?
I'm using I/O simulator to set all the necessary signals as they would be required by the real robot, I can see the PMC trying to set an UI, but it remains OFF (even though the signal reaches the coil in the program).
UI signals are enabled, Remote is set, RMT_MASTER is set to 0 (as required to set UO1 CMD Enable), everything seems to be fine, but is just doesn't work...
That is a plastic cow...
1. RELEASE and ATTACH generally work - so the example might be correct. However, some of these examples don't work as expected.
2. Unfortunately, %NOPAUSE only works with %NOLOCKGROUP, which doesn't allow locking motion groups (as the manual says about %NOPAUSE: This directive is only effective for programs with %NOLOCKGROUP.)
About that switching between RELEASE and ATTACH - try condition handling, with TP On signal. Have no idea if this will work with %NOPAUSE though. Generally, I would avoid mixing Karel with motion, as this functionality was abandoned by Fanuc long ago and it has tons of issues.
Looks to me like the gripper is designed to hold cylindrical parts - I would set the TCP so that it's in the center of the cylinder (right between the fingers), with Z pointing away from the flange and X pointing up when the robot is in zero position.
No, it won't work. Just read what the manual says - programs CAN NOT lock any motion group for %NOPAUSE to work.
You might try writing a program with %NOPAUSE (or Ignore Pause set to true), which in turn will RUN (not CALL) a program with a motion group - I think it might work.
Contact Fanuc on that one. TP firmware update (or even system software update) might be necessary.
Have you used %NOLOCKGROUP directive in the Karel program?
Here in the U.S., we need to pay for nearly every Fanuc option.
That's pure politics. Fanuc Europe and Fanuc America are separate subsidiaries of Fanuc, they have their own policies. They don't even share most of the robot documentation.
Yep, Europe here. Currently Germany, previously Poland.
M-3iA is a robot model.
.PC is a Karel program - you'll need a manual for that (and possibly a software option for the controller). Programs that you can work with on the teach pendant are called TP and are available in menu SELECT (either press SELECT on the teach pendant or press MENU - SELECT).
It is not true. It is related to your programming method. We install a lot of KUKA robot almost with all application package. There is no problem here and this contrary to motion control liteature.
Well, what I've written is not only my opinion, but also what I've heard from quite a number of KUKA's own robot programmers, some with experience counted in tens of years... 
Guess we need to clarify one thing - many features, that are an option in the US, are standard in (most?) European markets. Like Karel for example, where the only thing you need to do is change $KAREL_ENB to TRUE. Looks like some path related options might also be treated differently.
I tried to find it, but no luck... Anyway, you should be able to do it, it requires a bit of code, but is 100% doable on the teach pendant...
So you have your answer above. Be aware, that these motion macros will only be executed in AUTO, with the TP switched OFF, safety IO etc.
KUKAs are generally more accurate robots (for example, they don't change continuous motion paths nearly as drastically as Fanucs do when increasing speeds)
Not sure if I understand you correctly, but from my experience KUKAs are a PITA when it comes to continuous motion, as the paths change with the override, not with the programmed speed.
With Fanuc, if you program a motion, the robot will move identically in T1 at 10% and in AUTO at 100%. With KUKA - no way, you won't know what the path is until you run the program with override set to 100%.
That thing about being accurate... Well, I can't really agree on that too, especially that it's possible to increase the accuracy of Fanuc robots using "absolute accuracy" option/procedure. The difference here is negligible in most cases.
There is a couple of things that I find as KUKA's advantage:
1. some heavier robots' designs - without the additional arm in the back, which substantially increases the work envelope. On the other hand, the smaller, hollow wrist robots by KUKA are quite bulky and clumsy.
2. easier setup of many functions and options. This is mostly because the controller is Windows-based, which allows it to use many features of a "civilized" OS. But, again, on the other hand - it can be a cause of quite some problems with KUKA controllers (of which being laggy is the tiniest one).
I did a small program like this once - the robot was stacking large trays full of eggs. These trays were not always fitting together perfectly, so I added a section where this "wiggling" motion was executed, using a PR and a couple of registers to modify the amplitude as te robot was getting closer to the stack. I might even have a backup somewhere...
You want to jog ther robot from the PLC/HMI?
If so, write a couple of macros for each axis and direction and use DIs to call these macros.
For example, a macro for moving J1 in + could look like this:
PR[1] = JPOS
PR[1,1] = PR[1,1] + 1
J PR[1] 100% CNT100Then, in Macro Setup, assign a DI to this macro. Assuming that all conditions for running a motion macro are satisfied, the macro will be executed as long as the DI is ON, which will result in jogging the robot by 1 deg. with each iteration.
Repeat this for all axes and directions, possibly both for joint and linear motion (which will differ by JPOS/LPOS and motion type).
