Easiest is probably just to write your own function to read out the robot model and compare it to known parallel link robots...
PROC readrobmodel()
VAR string strRobType;
ReadCfgData "/MOC/ROBOT/ROB_1","use_robot_type",strRobType;
TPWRITE strRobType;
ENDPROC
Would you mind explaining the sequence and why you wish to change the speed...
As you coordinating with the press itself, the conveyors or something else ?
Tool at target is just graphical whereas the controller is... well.. the controller so any mismatch between them is usually calibration/setup related (TCPs baseframe etc)
For example, it doesn't look like the tool coordinates are the same (hard to tell when you're using the show tool/robot at target).
If you send me a pack'n go I can take a look at it.
Right click your controller and select activate external axis, activate the appropriate axis (all three are only active during indexing, so typically you'd use STN1 or STN2)
71397, No application protocol
Description
The application protocol arg is missing or the name is faulty.
Consequences
The application instance arg is unavailable.
Probable causes
The option holding the application protocol is not installed or
the protocol name is faulty.
Recommended actions
Install the option. Change the name of the application protocol.
FTP set up but haven't the actual option ?
May I ask what the purpose of this is ?
While you could create your own "MyMove" instructions, or you can take it another level and create "ghost" instructions that is an exact duplicate of the original but with your own code inserted to allow you to do this tracking... the downside is that you're now also responsible to do all the error handling which is usually a royal PITA and with your own instructions (non standard) you're also dealing with the programming aspects of things.
So, while you're solving your initial problem, you have created multiple others.
If this is meant to be in an production environment I for one would find other ways.
Additionally, with this approach the read-ahead might (most likely will) trick your "tracker" since it'll show the last robtarget "read" not necessarily which one is the current one being addressed by the motion planner.
30% of vMax is still plenty fast so I would personally use other methods
Your best option in that case is a system input to "limit speed", not sure when that input was added and/or if your system has it.
Next option would be the instruction VelSet through either a background task (ideally) or event routines (program start) and traps (after 5s).
Neither of which are "safe" and only you and your customer can put a price on safety.
Personally I'd make sure you inform your customer what the BEST / safe option is even if it's a lot of money and have them make the decision to go with a less ideal route and in that case which one. That way you have at least partially covered your butt for delivering a safety function that isn't all that safe to begin with...
Just my two cents...
I doubt they'll actually ship it for $60 to the US but, Ebay / machine auctions is probably your best bet.
Personally I would probably just add SafeMove (ABB's DCS / Cubic-S) and force it to run at "safe" speeds (<250mm/s) during the startup phase.
Worked just fine on my home pc...
You can't.
Back then you needed an additional Ethernet board and if my memory serves me right it only supported NFS, plus the robot was a client, so you had to run an external server which the robot connected to.... no transferring of programs TO the robot.
The cool thing was that you also could run a BootP server and cold-boot the robot via the network, which usually took ~5 min (with modified install scripts to eliminate the questions) compared to probably 30min or more with the old floppy way.
Theoretically you can go from 5.07 to 6.0, but it all depends on the application.
A lot has changed between ~2006-2007 and today, so you're better off (more likely to get it to load w/o problems) choosing something closer to 5.07
and definitely on the 5.0x or 5.1x track... (i.e. skip 5.60 / 6.0).
See PM
I'm not sure I follow exactly what you're trying to do... could you try and be more specific, i.e.
With regards to the picking from a pallet...
Yes, there's a lot of bin picking solutions out there today, Canon's is a pretty good one, but expect it to be in the $50,000 range.
This probably wont work on older (S4) control systems if that's what you're using.
Theoretically, yes...
Practically, no... unless you have a LOT of free time on your hands.
The very first S4's was actually paired with MHA's but I don't remember the specifics.
Personally I would not attempt to do it "as-is" since the MHA's are DC/Encoder based and the S4 is AC/Resolver,
so at a bare minimum I'd look at getting an old MU20/30 motor and build some kind of adapter to fit that motor to the MHA.
Shouldn't be a need for any particular order and you should be able to load all cfg files except MOC.
loading the modules might create an reference error at first until you have them all loaded but just hit the "yeah, yeah, whatever..." / "OK
button and keep loading.
Make sure you have the right robot model, Type A/B/C, the label on the back of the robot should tell you which one you have.
I don't remember when they did away with com-offsets, but if your labels only have one value (resolver offset) and nothing about comm offset then that's not the issue (most likely anyway).
Fine Calibration / Resolver update won't affect your ability to move the robot, it'll only screw up it's 0-position and with that it's accuracy, but you should still be able to move it just fine.
Easiest is probably to contact ABB and have them give you the information as to the exact model / generation.
Are you using wobj0 when jogging ?
Which type of machine(s) is it, CNCs ?
Have you timed the robot program (use timers in rapid / robot code CLKStart / CLKStop) to determine if it's the robot that slower on one side or the machine itself ?
