Try and make a manual 5-point (4+z) TCP and report the results (min/max error).
Be as accurate as possible... (if your robot calibration is messed up then you'll get a fairly large error)
Try and make a manual 5-point (4+z) TCP and report the results (min/max error).
Be as accurate as possible... (if your robot calibration is messed up then you'll get a fairly large error)
That's a standard AW system from Sweden, so not a "wolf system" as such.
Not a whole lot going on there, could you post a complete e-log as well ?
There's no welder defined so that's not it (which welder did you have in the past ?)
AW_SYSTEM:
-name "EMPTY_SYS" -aw_units "SI_UNIT" -aw_functions "EMPTY_FUNC"\
-aw_equipment "EMPTY_EQIP" -aw_weldguide "EMPTY_WG"
EIO_UNIT:
-Name "BOARDC" -Type "d327" -Bus "BASE" -Digin 16 -Digout 16 -Anout 2
-Name "SIM_BOARD" -Type "eip000" -Bus "SIM" -Address "" -Digin 16\
-Digout 16
#
That assumes that he's got a configuration for a 2-axis positioner and not just two MTD's loaded from the template files.
Which size MTD's are you using and what style positioner have you built ?
Skyhook / IRBP-A or more of a tilt table ?
Could you post / PM the option disc ?
You can edit the install.cmd file and remove anything you don't need / want, easier to do that than to manually edit the backups.
If Sandep K is still there you should tell him I said hi
Path Offset will most likely be sufficient, RRI is more if you want high resolution and fast corrections (it's a shortcut to the motion planner if you will).
Path Offset is a bit more "sluggish" since it relies on rapid sampling your feedback and writing corrections to the motion planner.
Two additional alternatives would be to use a 3rd party compliance device (look at PushCorp for example) and a science experiment would be to use force control but instead of a force sensor you'd use your own feedback from your device, but pushcorp is probably the closest to an out of the box solution you'll find.
What's the application ?
Which external axis is it ? ABB's own, 3rd pary ?
Assuming the gear ratio is correct, i.e. you rotate it 360-degrees on the pendant and it represents 360 degrees in reality, your solution is to measure a base frame and coordinate your movement (w. a moving work object linked to your external axis).
The "lazy" solution is to define your own speed data and change the r-eax (rotational external axis) to a lower number than default (which I think is 5000 or something on all pre-defined speed data).
The "sampling" is only for current weld-speed which doesn't change that frequently, it would only change when you change the weld data so sampling every 0..2-0.5 seconds will give you enough precision.
You might even be able to set up an ivar trap on that instead of a timed poll which would negate the whole "issue".
I did timed samples on S4C/C+ and resources was not an issue, granted, I don't know how heavily loaded you system is already but the motion planner has a lot higher priority than a measly rapid task so you'd see a bunch of other weird issues long before motion craps out (which it wont).
https://us.v-cdn.net/5020483/u…ditor/aw/bkkb1ykmrxsj.pdf
Older manual but it should be enough to explain the gist of it.
It's basically an open sensor interface so you can control the robot path from an external device.
If you're only moving 5mm/s then the path offset method would probably work.
Is the motion static ? (i.e. is the robot not moving except for regulating the current, or is it supposed to be adjusted on the fly as the robot is moving along a path)
Static
Theoretically you could do it through a background task and an "analog" input and use Path Offset/corr write (writing correction vectors to the path planner), but odds are this is too slow for what you want to achieve.
On the fly
Your best bet is probably an external PC through RRI
What you're trying to do is "impossible".
Multiple Welding Systems is for when you have separate welding equipment, i.e. a MIG here and a plasma there and you switch between them, then you get ARCL and ARCL1 instructions allowing you to connect to both (separately).
For a single system, twin torch solution like yours you have a few options.
1. Pitch the welding equipment and buy a dedicated twin torch system (Fronius, SKS, etc.) not sure if ESAB has it.
I understand this is not the response you want, so the solution for what you have is that there is no solution (short of developing your own arc instructions and GUI), only compromises.
Come to think of it, I think the old Fronius Twin is still DNET so you might be able to set it up as a Froinus Twin and re-map all the signals / I/O's to match the ESAB machine (let me poke around a bit).
Post your EIO and PROC file (or send via PM)
Easiest - RobotStudio
If you want it done on/in the robot I would recommend writing a program that you run in a background task that monitors the Arc Established (traps routine) signal and when high also samples the current weld speed.
That way you get both Arc On time and weld length (travel-speed x time).
Kind of the long way round instead of declaring a global NULLFRAME:
CONST robtarget pNULLFRAME:=[[0,0,0],[1,0,0,0],[-1,0,0,0],[9E+9,9E+9,9E+9,9E+9,9E+9,9E+9]];
and in your code just using:
PutPos:=NULLFRAME;
AIf you like the idea of using a function instead, then in your routine/function you don't need to separate out all your components of a robtarget (it's a robtarget after all) you can assign all at once just like you did in your initial post.
FUNC robtarget NULLFRAME(robtarget p)
p;=[[0,0,0],[1,0,0,0],[-1,0,0,0],[9E+9,9E+9,9E+9,9E+9,9E+9,9E+9]];
RETURN p;
ENDFUNC
Do you have the multitasking option ?
OK, so there's no "automatic" way of doing it unless that functionality have been included in Production Manager (which I still hate with passion) as roulv implies
What lemster suggests is to use the Dist function to calculate the distance between two named positions, while this works it's a royal pain in the butt, especially if you have multi segmented welds (more than two points).
What we used to do if you have multitasking is to make/use a logger that looked at arc established and read the current weld speed. that way you get the weld distance, arc on time, etc. (which is probably what transferred into Production Manager)
I can check in my treasure chest if I have something like that saved.
Different school of thoughts I guess...
If you're in the cell programming and some dimwit decides to walk in without you knowing / seeing them, then it's quite convenient to have the gate on G-Stop so it stops the robot...
Yeah... no...
While it technically would accomplish the job, you don't want to wire safety functions to system inputs.
Depending on the age of the controller it might be a different drawing set but look at this diagram and the run-chain.
(open the cabinet do you have black or silver drives ? back wall straight ahead)
https://abb.sluzba.cz/Pages/Pu…/3HAC024480-011_rev11.pdf
You want to use general stop for gate switches and light curtains.
VAR ProdData ProdData_1{2}:=[[1,1,3,3,358,225,91,1], [1,1,2,2,358,225,91,2]];
Rather than declaring your own datatype (assuming all are the same datatype) you could also have declared a multidimensional array as well (easier to deal with sometimes).
VAR num ProdData_2{2,8}:=[[1,1,3,3,358,225,91,1], [1,1,2,2,358,225,91,2]];
The beauty of records come into play when you wish to combine multiple datatypes into your own, just as in the example from lemster and/or when you want the structure of being able to name each "Value" and keep it a bit more readable for the next guy.
What do you want to achieve ?
I would have to double check my history books, but we did use 422 <> 232 media converters back in the day, but I could have sworn we used normal 232 without converters too, but that could have been S4's (M94)
The console should be normal 232 though
Make a backup and open them with any text-editor