Posts by bidzej

    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.

    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 ID

    you 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...

    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.

    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).

    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...

    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% CNT100

    Then, 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).