Posts by DS186

Quote from cat91345

can I offset 2 axis on one move?

No problem, if needed you can change all components together.

Use $MCR.$GENOVERRIDE which is the global override shown on the TP.

A chain failure cannot be reset with a power cycle. Select the Alarm Log within the ALARM menu. Press ACTIVE within the Alarm Hist screen and then select RES_1CH. Confirm with yes and press reset. That should reset both alarms.

I don't think that this is documented in any of the manuals. The behavior you have described is normal when HSCD is installed at a later time.

Check the system variable $HSCD_GROUP[1].$HSCD_PRM_ID. Enter HSCD01.02 and make a cold start.

Did you try to deactivate the collision detection? There is a checkbox under the collision detection tab named "Override collision detection" which allows you to deactivate the collision detection for jogging.

Hey all,

Over the time I have created my own styleguides to get my projects standardized as good as possible. These docs describes for example the naming conventions for programs, variables or signals, etc. and many more information. Let's make an example for a digital input:

diDoorLockedSt1

di/do + functional description + station/fixture

I wonder if you also have your own naming conventions, standards, etc. and how it looks.

Quote from foffulaRob

How do i know if it is local or not? After selecting "Registers" if i try to modify the variable and i select "List" it shows me the global variable. So how do i select local if it's enabled in my version? (v9.40 confirmed)

Check this thread for more information on local registers.

Quote from hermann

Following statements are valid for TP programming, Karel is another case.

1. There are no local variables, you have to use registers

If you have a controller with software version v9.40 you can use local Registers, PRs and SRs.

Quote from SkyeFire

Hm... some more issues. I uploaded the active Project from the KRC5, made a change to the Cell name, and tried deploying, and got this:

I'm not sure what the MADA issue could be -- the robot is jogging correctly, and there are no obvious errors in the $MACHINE.DAT file. The customer did have to change the $TRAFONAME to achieve that, from KR6R700_2 C4SR 230 to KR6R700_2 C4SR in order to achieve that. The new $TRAFONAME matches the robot label, except that the label doesn't make it clear if there needs to be an underscore between 700 and 2.

I suspect the Bus error is related to why I can't get access to the I/O to start mapping.

Display More

Did you try another version of WoV?

That is odd... Attached some screenshots how it looks in my project. I cannot see something wrong from your screenshot, but did you accidentally set a filter in the IO Mapping tab?

The EM8905 I/O module is only for the arm-mounted IOs. The XG12 IOs are controlled by the Interface Board, check my post from this thread. It is the same for these IOs, simply map it as all the other "normal" IOs.

By default it is inactive/not mapped. Open the IO mapping in WOV and under fieldbusses you should find an EM8905-1001 I/O module. This is the one for the internal valves and IOs. You can map these just like all the other IOs.

As far as I know there is no "loopback" option for using internal power for XG12. If you want to use the XG12 non-safe IOs you have to wire external power to the XD12 connector.

However, the internal valves and IOs of the Agilus will also work without wiring XD12. Configuration via WOV is enough to make them usable.

You will find the information in the SafeOperation manual. The mastering reference test is e.g. required after a restart of the controller, if the robot is mastered, after a reconfiguration of the IO driver and in case you are using an external reference switch e.g. from a PLC.

Change the mechanical batteries and clear the reminder as described above. Do not power off the robot while changing the mechanical batteries! Further information can be found in the maintenance manuals of your robot and controller.

You can use $MOR_GRP[1].$ROB_MOVE in a BG logic task to check if the robot is moving, e.g. DO[n]=($MOR_GRP[1].$ROB_MOVE).

Quote from Sergei Troizky

Unless such a switch is attached to the pendant, this will only relocate the problem.

But you can install the mode switch to a better place near the TP. Maybe not perfect but it might be an improvement. The only option from FANUC I know which gives you the possibility to have the mode selection directly on the TP is "TP Mode Select" (J768). But as far as I know this option is not compatible with the R-30iB controller.

Quote from DS186

By default there is no speed limitation when jogging in Auto mode. It is possible to jog the robot with 100% full speed. We normally limit the override when the TP is enabled in Auto mode. For this, we use the (non-safe) TP enabled signal (and some other logic). This is okay since the fence has to be closed to jog the robot.

Jog in Auto mode from FANUC is a nice feature but it is as always, you have to know what you are doing.

I accidentally wrote "full speed" instead of "override". Sorry for confusion!

I did a quick test with a real robot to verify this. The speed is definitely limited when jogging the robot in Auto mode with an override of 100%. It looks like it is the same speed as with 100% override in T1.

Quote from kwakisaki

I assume by this method the robot speed is reduced to a maximum safe speed with the word 'jog' being utilised for the option?

By default there is no speed override limitation when jogging in Auto mode. It is possible to jog the robot with 100% full speed override. We normally limit the override when the TP is enabled in Auto mode. For this, we use the (non-safe) TP enabled signal (and some other logic). This is okay since the fence has to be closed to jog the robot.

Jog in Auto mode from FANUC is a nice feature but it is as always, you have to know what you are doing.