Yes you can.
You can get more or less any status tied to an output.
There is a section in your IO settings deticated to this called system output.
If you are using a system older then IRC5 you can still setup the system outputs but not through robotstudio.
Hello again.
The S4c+ systems are nice and bullet proof but they are getting quite old. The problem with that is that most of the tuning possibilities that exist in a modern controller where not implemented yet. Pretty sure tune master won't work for that old controller.
The 4400/L10 is a good robot and normally has some really good path performance. I am actually getting nostalgic thinking about tuning those old systems and robots. Now most likely you are having some issues with friction or axis resonance. I am thinking that you cant use tune master to fix any of that so instead i have something you can try.
Copy paste this code into the start of your cutting routine.
WaitTime\InPos,0.01;
PathResol 70;
AccSet 50,50;
TuneServo ROB_ID,1,60\Type:=TUNE_DH;WaitTime\inpos will force the robot to be in compleate stop for 0.01 seconds. This is important, the robot will not like it if you tune servo parameters when its moving. (it wont break, but it will hate you).
PathResol will change the path resolution time to 70% of its original value, this will increase the path resolution. If this value is to low you might se an error saying something along the lines of "corner path failure", you can ignore that error as long as the path is good.
AccSet lowers acceleration and acceleration ramp. Instead of using PathAccLim it is better to use AccSet on a 4400 robot since they respond really well to the increased ramp. Values are %.
Tuneservo command is used to change servo parameters, this is ok to do and it is well documented in the manual. "DH" tuning is the robots finite impulse respons filter, lowering the value will increase the amount of filtering, This should smooth out your path a lot. If the value is to low you will see the robot taking smal shortcuts in zones.
This tuning is 100% safe and won't damage anything.
As for the zones, this is data declarations.
CONST zonedata zone0:=[FALSE,0.3,20,0.3,0.03,0.3,0.03];
CONST zonedata zone1:=[FALSE,1,20,1,0.1,1,0.1];You can copy these lines into your base modules in your tasks. This will make them available to all programs in the system.
This will allow you to use these custom zones in you movement instructions.
! Go from this
MoveL p10,v200,z0,tool0;
! To this
MoveL p10,v200,zone0,tool0;It should help you keep the speed up int he small zones.
The abb robot will let you create custom data of more or less anything so you can get it to do exactly what you want it to do.
And as you stated the abb "fine" zone is the one that will force the robot to stop completely, all the other zones including z0 will not force the robot to stop. But z0 is a zone of 0,3mm and the robot is quite big so its hard for it to maintain speed through the zone.
Don't worry about your lack of experience, everyone in this forum was in your shoes at some point. Just see every day as a chance to learn something new and you will ace your job.
What robot modell are you using? Who made the system?
There could be a number of things causing this. I am guessing you are using the industry standard with some hanging robots, probably 1600/2400/2600. If that is the case then you should be able to go way faster then what you are right now. I normally cut with 400-600mm/s in waterjet applications.
Its been like 20 years since i programmed motoman robots but i seem to remember them handling zones way different then ABB. I guess your cutting something other then carpets since your are using such small zones. There is a behavior in the robot when using such small zones that will cause the robot to slow down in each transition from L to C and vice versa. This will happen if you are using small zones and there is some kind of reorientation in the movement. You can get around this by making your own zonedata and increase the oriantation zone.
CONST zonedata z0:=[FALSE,0.3,0.3,0.3,0.03,0.3,0.03];
CONST zonedata z1:=[FALSE,1,1,1,0.1,1,0.1];
CONST zonedata zone0:=[FALSE,0.3,20,0.3,0.03,0.3,0.03];
CONST zonedata zone1:=[FALSE,1,20,1,0.1,1,0.1];I assume you know this but i am going to say it anyway just in case. The first two entrys in your speed data are linear speed and orientation speed for the robot the second two are for external axis. The orientation only applies when you re orientate the tool and the value is degrees per second. Now if you are using the small robots 16/24/26 then you should not have to go below 120°/s. If you need to go lower then that the problem is usually something else in the system.
There are a lot of things you can change in the system to go faster with perfect quality. Some things are complicated and some are hard. I would recommend trying a lower acceleration and see if you can get the speed up.
! On
PathAccLim TRUE\AccMax:=2,TRUE\DecelMax:=2;
!Off
PathAccLim FALSE,FALSE;You can play around with accelerations, valied values are 0.1 to 20 and the value is meter/second².
You can take a look at a software from ABB called TuneMaster it is free and can be downloaded from ABB's web page. It can be used to tune foundations stiffness and resonance depending on robot modell and robotware version. This tool will usually help the 1600 and 2600 a lot.
Just like my answer in your other thread. The solution is to install a module with the RECORD as shared. This will make the datatype available in all tasks. You can then create PERS data with the same name in several tasks to send data between tasks. But again. This stuff can be tricky depending on how many tasks you have, and how many background tasks are installed that you don't know about. It is quite normal to have a MODULE with records in each task. Normally you set those modules also to auto-load but instead of shared you just load them to AllMotionTasks. But in your case that probably wont work.
In robotstudio when connected to your system, look under controller tab:
> Configuration > Controller > Automatic Loading of Modules.
I seem to remember that you need to perform a p-start for the module to load, this will clear the system of all modules so make a backup first.
Also if you have a RECORD used as a datatype in your main RECORD that you use for programming. You can load that as shared+hidden in one module and the main RECORD as shared in another module. This will make the unused RECORDS invisible in the user level.
Edit: I know i suck at explaining, i am trying my best 
SAABpholic is on the right track.
You can do this by putting the functions/instructions you want to share in a module and auto loading it as "shared". But you need to be careful with this. You could have 2 program-pointers simultaneously using the same data, and that could cause you some serous headache. So to manage this you have to manually program semaphores using commands like "WaitTestAndSet". So yes you can do it, but you need to really think it through.
Hello Everyone.
I was looking around for some stuff to play with in my lab. And i found a controller with X3,Y3 drives and i have some MU300 motors.
Now it occurred to me that it should be possible to create a second mechanical unit as a second task.
I was thinking just for fun to try and make a XY table with the two external axis. And maybe play around with some motion coordination just for fun.
I can get it all working if i just treat it like external axis. But i would want to create a custom mechanical unit, so i could use MoveC commands.
Does anyone have any idea of there is any documentation on how to do this? Anyone have experience with this type of thing?
( I am between projects at work and really bored, so just trying to entertain myself 
)
Do you mean the "irc5 compact"?
There is usually no single root cause to these errors and the normal reasons varies depending on robot modell.
The 4600 is a well known bastard child off ABB and puts shame on their long legacy of excellent path performance.
Most likely your tool is very light compared to the max tool payload of the robot. This will result in your dynamic factor being all wrong.
There are many things you need to fix to get the perfect motion but many of them are complicated and require secret knowledge about the robots.
Best advice i can give you is to download tunemasters, it comes with the tools and utilities package and is a free software tool from ABB.
https://robotstudiocdn.azureed…And_Utilities_6.08.01.zip
Depending on your RobotWare version you should let the software Tune you DF (RW5.15) or your Foundation stiffens(RW5,6x and up).
If your RobotWare is 5.6x or newer the system will save the data to your motion process modes, otherwise you need to write down the results and add TuneServo commands manually.
You should Increase your "Finite Impulse Response filter" with the command TuneServo.
TuneServo ROB_ID,1,60\Type:=TUNE_DH;Tune_DH can not break the robot so play around with it, lower value then 100 means more filter, This is described in depth in the Rapid reference manual. Also make sure your arm payload and tool weight are 100% correct.
If you fix all this your drift should be around 0,2mm.
Like everyone says, 5.15 and older systems are unable to upgrade beyond 5.15.
However 5.6x systems can be upgraded to the latest robot ware. (and probably should be, 5.6x where buggy as hell).
Not sure this works on all versions off the teach pendant. It will work on newer ones at least.
With the robot controller up and running. Restart the teach pendant.
This can be done by pressing the Small button on the back of the teach pendant, inside the small hole.
The other way is to have someone help you disconnect the cable and plug it back in with the controller running.
When the teach pendant starts to boot up you need to hold down the "p1" and "stop" buttons. This will force the teach pendant to re-download an image from the controller and re-install itself.
Not sure this will fix you problem but worth a try.
Hi Gilldur,
a problem with this may would be that you check the reachability of pick_point only but move to RelTool(pick_point,...)! It should rather look like:
CodeIF CanRobReach(pick_point,suction) AND CanRobReach(RelTool(pick_point,0,0,-200),suction) THEN MoveL RelTool(pick_point,0,0,-200),v1000,z50,suction; MoveL RelTool(pick_point,0,0,0),v1000,fine,suction; MoveL RelTool(pick_point,0,0,-200),v1000,z50,suction; ELSE ! Ask camera for new pos ENDIF
You are correct i misunderstood the question a little. 
Hello Robot freak.
I would do it with a function for ease of use.
!*******************************************************************
! Function: CanRobReach
! Description: Checks if a robtarget is within reach with given tool and wobj
!
FUNC bool CanRobReach(robtarget ToPoint,
PERS tooldata Tool,
\PERS Wobjdata wobj)
VAR jointtarget jdump;
jdump:=CalcJointT(ToPoint,tool\wobj?wobj);
RETURN TRUE;
ERROR
SkipWarn;
RETURN FALSE;
ENDFUNCSo you can just use an IF statement to sort out if to pick or to ask for new position.
Example:
IF CanRobReach(pick_point,suction) THEN
MoveL RelTool(pick_point,0,0,-200),v1000,z50,suction;
MoveL RelTool(pick_point,0,0,0),v1000,fine,suction;
MoveL RelTool(pick_point,0,0,-200),v1000,z50,suction;
ELSE
! Ask camera for new pos
ENDIFAnyway how you program it is up to you but that function does what you need it to do.
EDIT: Forgot SkipWarn;
Gravity Alpha is only functional in newer robots/robot-ware so depending on what you have it might not do anything.
Because of this most people simply use Gravity Beta to tell the robot it is inverted.
Gravity Beta is the robots rotation around the Y axis and is defined with radians. So to tell the robot it is inverted in relation to gravity you can simply put "pi" in gravity beta. 3,14159.
Don't forget to warm start after changing gravity beta.
Cheers!
Hello Royston.
Basically you need to point a tip of your tool against another fixed tip in at least 4 positions.
After this the robot will figure out where that point on the tool is and you can use that point to define your work object.
Look in the attached manual under 4.5 Tools and 4.6 Work objects. There are step by step guides with illustrations on how to do everything.
What controller version do you have?
This manual is for an IRC 5 system. I can probably find an older manual if you are using the S4c,s4c+.
The other unofficial version that I know of had no issues with naming, encodes as well, and handles both RW 4 and 5.13+ (I think that's when they changed it ever so slightly)... don't remember if there's any changes on 5.6 and I'm sure there is on RW 6 and later (calls for some investigation).
All RW 5 and 6 use the same encryption, They did a Small change way way back before 2000/2001 but it only has to do with how the controller/encryption handles "new line".
Quote from SAABoholic
While I can't say for sure since I never used the ABB version, I find that very hard to believe.
I have used the official parameter decoder and it has no issues opening files from a controller.
The only scenario I can see where the ABB version might struggle is if the name changes, for example if the filename is myModule_enc.sys but in actuality it is a system module declared as MyModule only and as a result get saved as myModule.sys.
It shouldn't struggle even if the name is changed, i understand why the name is important. But ultimately the encryption adds information to the file so nothing is lost if the name is changed. the decode software will decode files even if the name is changed. The decode software won't decode files taken from a controller as a safety thing. There is tag in the encryption when a file is saved from a controller and if the decode software sees this it will just refuse. This keeps you from taking other peoples files and decoding them. I guess they feared what would happen if people started sharing it. So if you lose both the original file and the encrypted file not loaded into the controller you still need to ask ABB for help. But i only have what ABB gave me so there might be other versions out there, so don't take what I'm saying as absolute truth.
The official decode software will only decode source files that have not been loaded into a controller.
So if you take a file from a controller you can't decode it with ABB's software.
The easiest way to decode files is to make your own "brute force" software. It's not that hard...
I am sure the people who made their own decode software will not share it on the internet. So you have to make your own.
To make the robot remember the signal state at power off and automatically restore it at power on you have to change the signal safe level type.
You can do this manually through the MOC, Example:
-Name "doR1_Home" -SignalType "DO" -Device "IO_Internal_Device"\
-DeviceMap "33" -Category "machine" -Access "DEFAULT"\
-SafeLevel "SafetySafeLevel"
Or you can use the "new" io configurator in robot studio.
You can find all manuals in all languages here.
https://robotstudio.azureedge.…mentation/18.1/start.html
Manuals for the 14000 are located under: Robots > Collaborative robots >
There is a way to get the key strings that works in most cases but not always.
What you need is a backup from the system you had. Open Rob-install and click the Update button.
Point the program to your backup and update it. This will often cause the program to access the encrypted key.id and copy the key strings inside it out to a file that will be named key.txt or something similar, ( same location as key.id ).
But as long as you have the key.id file you should have everything you need really.
