RO 1 - 6 Typically control internal solenoids that are plumbed to the 1A - 3A and 1B-3B ports.
RO 7 & 8 Are wired to the connector.
RO 1 - 6 Typically control internal solenoids that are plumbed to the 1A - 3A and 1B-3B ports.
RO 7 & 8 Are wired to the connector.
What arm type? What controller generation?
ROs made the change from sinking to sourcing outputs a while ago.
Not the rapid code but actual abb backups, I wanted to have a look at the I/O Mapping.
The IO was a single dry contact relay output to close the "torch on" circuit to the plasma cutter.
I had plans to eventually implement dynamic height control, but I have since sold the arm.
Can you output the acceleration trace? That is what you need for force. F=ma after all.
Good job posting your solution. The only thing I will add, is that particular system var may not be present on older models. Probably V7.70 and lower.
hello
I have a question. Can I open any file in this format ? For example I want to open a .pcd file and change something
Thanks for your reply’s
Yes. You can open any file with that command.
You can move local points to PRs, but the reverse cannot be done.
Valid:
Not Valid:
Also, I would recommend against storing a path in PRs. I like to use them only for points that need to be accessed from multiple programs. Path specific points should be local only, in my opinion.
I haven't done this, but here is how I would approach it.
I would get comms up between the PLC and the robot without the NAT in the middle, and then add it in once comms were established.
Also, why are you going through a NAT? Robot to PLC comms are typically done on the same subnet.
Without knowing where your application user frame is (I believe it is specified in the snap part of the tree, or at the root), I can't answer that. If it the ground, that is correct, but if it is not the ground, it will be wrong.
Is your part really -287mm from where your application frame is taught?
Also, my understanding is that the reference position is the position where the robot arm is inside the object and is ready to pick up the object. Is that true?
No. It is what will be subtracted from the vision's found position.
Pretty rare you need to increase the stack size of a program.
Are you calling your program again at the bottom of your program?
Right click on the robot controller in the tree. Then hit properties.
It will bring up a properties window, and at the very bottom of it is what ports the robot is running its various services at.
In this example, the second robot's webpage is on port 9001. You would connect to it like this: 127.0.0.1:9001
Not quite. It is replacing karel programs you call from TP. Not commands within Karel.
Both MATRIX and INVERSE can be found with the Vision Support Tools Option, and is usually included with 3D vision packages.
I don't have any experience with the Karel compliation process on the controller, but you could rewrite the Karel routine to take arguments from a TP program.
I did that on a robot that had humongous blending paths.
Here is an example of the tp program calling the Karel programs:
: !Download Part 1 Programs. ;
: CALL PROGDOWNLOAD('part1\*.tp')
*** all the various calls and logic here***
: !Delete Part 1 Programs from ;
: ! controller. ;
: CALL PROGDELETE ;
Progdelete in this case would use a list created during the program download to delete programs.
That robot is too old for DCS, at least of the software variety. Earliest software DCS was V7.5 I believe.
It does have hardwired DCS, and this is what you need to use. The fence circuit would be the proper way of doing this. That, or maybe the servo off circuit. Depending on the cell setup, you man need additional J1/J2/J3 safety rated cam switches, and/or multiple light screens for watching the robot position, safely. You need to have a proper risk assessment done.
Not knocking you. I'm glad you are here asking questions. Your boss's approach to the problem is wrong, and could be DEADLY wrong.
Your boss is exposing your company to some serious liability by not following standard practices in the robotics industry regarding safety.
If you want a remote hold switch, just drop the hold signal on the UOPs. That will bring the robot to a stop gracefully.
I guess I am having trouble parsing what you want to do here. Pictures would help.
Tell me if I have it right:
If I am correct, the proper way of going about this is to use the fence safety circuit. It is safety rated (at least to 1998 RIA standards). The EE connector is the absolutely wrong way of going about this, as it is not safety rated.
This particular line confuses me, as it implies the robot is still moving while the operator is in the area:
He wants the deadman to remain active throughout the cycle instead of just when the operator needs to move into the operation area.
So active at all times? If that is the case, definitely fence circuit.
First off, why does the operator need to hold in a deadman? Is the operator in the workspace of the robot while it is running? Because if so, hoo boy.
Second, no, the EE connector can't be used for an external safety device. Also, are you hooking into the connector on the arm, or splicing into the connector on the servo amp?
I wonder if the PLC is watching one of the UOPs and aborting the robot when a specific scenario comes in. Might be sending the CSTOPI bit for one scan.
I would recommend disabling the UOPs and trying to recreate the scenario.