Posts by SAABoholic

If it's an ABB supplied positioner the ext. axis is booted into the system with some parameters as "hidden" so deleting what you can will most likely cause a sysfail.

Easiest as Reboot mentions is to create a new system without the external axis (option) and reboot the robot with the new system. At that point you can remove the external axis without an resolver error, however, you will most likely get the PTC / overtemp error in which case you need to jumper the PTC signal that used to go to the external axis.

Just because you can doesn't mean you should

ABB fully supports ArcLink\XT (XT signifies AL over Ethernet)

and they also support just about any welder out there as long as you can connect the welder through some kind of signal based interface (i.e. outputs / inputs and analog reference), be it discrete, DNet, EIP or whatever your flavor of fieldbus is.

I personally would be very reluctant to use a big robot like that for welding, while technically possible, the sheer mass (i.e. Inertia) of it is not suitable for arc welding.

Imagine a 3mm weave with 3hz cycle and the motion performance of that

If I absolutely had to pick one of them I'd definitely pick the 6700 over the 6650.

But since you're dealing with refurbs I'm guessing these are "left over" automotive units, if so I'd probably just refurb them, sell em and use the earnings to buy a 2600 w. Arc Ware already on it.

You'll probably end up paying a couple of grand in software upgrades to get Arc on that 6700 and in the end you still have a robot that was never really mean to do what you're doing.

So - Just because you can doesn't mean you should

With all that said - if this is their tinker toy and your buddy plan on doing a bit of everything, MH, polishing, etc. and just the occasional arc welding job, then I'd say go for it.

The robot drive system is not your average VFD so you cant just slap any motor on there and make it work.

The 6640 uses a "high voltage" drive system so I believe the motors are rated for around 450V.

Second is the resolver (position feedback) which need to be of a specific type / specification.

Long story short, you're better off swapping out the SEW motor for something more robot friendly.

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.

robot-forum.com/attachment/26570/

robot-forum.com/attachment/26571/

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.

https://www.ebay.com/itm/ABB-A…742c34:g:M2wAAOSwoRpcUa7o

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.