As a "Can it be done" question, the answer is definitely yes. G-Code is mostly movement instructions, after all.
In terms of automating the translation from G-Code to RAPID code, I've never personally seen how it is done.
As a "Can it be done" question, the answer is definitely yes. G-Code is mostly movement instructions, after all.
In terms of automating the translation from G-Code to RAPID code, I've never personally seen how it is done.
The robot is able to access the contents of encrypted files, but Integrators can encrypt proprietary code to make it difficult to modify and/or copy.
What you're describing sounds like the functionality of SafeMove. Safety (zones, signals, comms,) is all handled within that system option.
I'm almost exclusively an ABB guy, so I'm not sure what you mean by multi threading. I think you're referring to tasks. The robots are capable of having background tasks that can monitor incoming data, etc. and feed it to the TRob_1 task that controls robot motion.
Safe move pro should not require a re-sync after every restart. I have 30 robots running safemove pro (the second generation of safemove) and they don't need a resync on startup.
Do you get any messages explaining WHY the sync was lost?
Here's the little I know about how AbsAcc data is generated. I don't know enough to give you a solid answer to your question, but hopefully this information will help.
The robot is moved through a series of movements, while the actual position is compared against the robot-reported position using a very accurate position sensor.
When you see measurements of "Arm Compliance", this is a number that describes the deflection of the arm, the "bending" of the metal itself.
I would imagine that, depending on the degrees of freedom of each joint in relation to an established coordinate system, this would determine which axis is assigned certain arm compliance axes (x,y,z)
Maybe I'm being dense, but what process are you trying to configure?
If you cannot adjust flow, your best bet will be to turn off the flow as you approach the corner, then re-align the robot with the next edge and turn the flow back on.
WIth dispenseware and IDFP, you have the option of adjusting flow on the fly, to dispense less as you slow down to go around the corner. It sounds like you don't have that ability though.
In the sys.cfg configurations, you can set up the user.sys to be an automatically loading module on start-up. I'm a little surprised that it isn't already automatically loaded though. If you discover that the user.sys file is already being loaded automatically, have you tried saving the module that's got your desired data (active in Rapid), back to the hard drive location (Home/Programs, or Home/robdata) from which it is being automatically loaded?
Your odd-tasting method is the only method I'm aware of to achieve what is described.
GS1 and GS2 are part of the dual run chain. Both run chains should open and close simultaneously.
Are you using the CIP communication protocol? Usually the PLC side generates an ID number that gets entered into the robot side. I seem to recall that the PLC generates the ID with dashes between groups of numbers, and those have to be either removed or changed to underscores (it's been too long, cant remember exactly)
are there any dashes/underscores in the ID? I seem to recall that on the robot side, you had to change the dashes to underscores to make it work... or just eliminate the dashes? I can't remember, it's been too long. Does anyone else remember this?
I dont know welding, so I'm going to assume that the output is just a standard digital output.
on an IRB robot teach pendant, open the top left menu, go to configurations, change topic to EIO (or signals, or communication, etc). Use the menus there to define your new signal. You can copy the settings for a signal that uses the same device on a different address, that will get you most of the way there.
The image you have supplied does not match the fault you are describing. The fault you describe can be caused by incorrect wiring of the mode switches (whether driven by PLC, a key switch, or some hybrid of the two)
I believe only one task can have a declared value for the data. The others must declare the name but not the value.
TRob1
PERS DataExample NameHere:=1;
BackgroundTask1
PERS DataExample NameHere;
BackgroundTask2
PERS DataExample NameHere;
Hello,
It's been a while since I set up profinet on a robot, but when we did it, I had to load a file, IPPNIO.xml, to the robot, so that the robot knew how to talk on Profinet. Did you do this step?
the Profinet Configurator program that ABB supplied built the IPPNIO file, and then in config you had to point the system to the location of the file.
It's been a number of years since I did this, on RW 5.61, so the process may have changed since then.
SkyeFire,
I've worked with ISRA as recently as this year, and your statements are still accurate.
Out of curiosity, which vision vendor are you using?
All the robots think they are in the same location (base frames match). This means that they should all have the same workobject, so that a single vision result can be given to all robots in the cell. Wherever the shared location of the workobject is, put that into the U-Frame
put the vision offsets into the o-frame. Here's the basic structure, simplified slightly.
VAR pos VisionTranslationPoints:=[0,0,0];
VAR num VisionXRotation:=0;
VAR num VisionYRotation:=0;
VAR num VisionZRotation:=0;
VAR Wobj WobjExample;
VisionTranslationPoints.x:=giVisionX;
VisionTranslationPoints.y:=giVisionY;
VisionTranslationPoints.z:=giVisionZ;
VisionXRotation:=giRotX;
VisionYRotation:=giRotY;
VisionZRotation:=giRotZ;
WobjExample.oframe.trans:=VisionTranslationPoints;
WobjExample.oframe.rot:=OrientZYX(VisionXRotation,VisionYRotation,VisionZRotation);