Posts by prnuk2003

    M98 is an S4c controller that only used boot disks that came with a key disk.
    You will need to contact ABB to get a new key disk and the boot disk pack containing all the boot disks.

    S3 Parameters can be saved and loaded from a double density disc. (manual/SCAN/PARAM then FR DISK to load or TO DISK to save).
    You can't see or read any file or folder with them on a PC as the format for parameters and blocks cannot be read by any windows or DOS type of program.

    It is strange that you only have a flashing cursor in one corner - maybe you have another issue with the controller at the moment that is hanging the controller rather than a wiped boot memory.

    If you had later 2.1 software you might of been able to make a backup through service/file/ that contained the serial number.
    Earlier versions of 2.0 and 2.1 had no backup facility so you had to save parameters in a SYSPAR directory and all modules separately in other directory.

    Normally on an M94 after a pulled Main/Axis/ Memory board, a forced c-start or a dead back plane battery you will see a lot of memory erasing steps after power on (T-xxxx several stages), then you will arrive at a prompt saying 'insert disk 1 (of 3) then press OK'

    The problem with M94a systems you will need at least one original boot diskette (RW2.0 or 2.1) to transfer the serial number (using the dos serial number transfer program 2300-2 update.exe) to a new complete set of boot disks unless you can get a generic boot disc set (no serial number) from ABB. We had to do this in the good old days when updating robotware and leaving a customer with new discs with correct serial number.

    I do not agree with sending key disks as this belongs to another robot and some company who paid for those options etc.

    Problems might occur if options and configuration are wrong and you will also end up with the wrong robot serial number.
    If you need ABB help with the robot in the future and the software/ serial number doesn't match the number then this could also cause issues.

    I'll stick with my original suggestion and recommend you contact ABB to obtain the correct key disk.

    The key posted by olddog71 contains this system:

    3HAC2700-1/53 System Key 3.2
    Serial no 24-14775
    Licence 24-14775
    516 BaseWare OS Plus
    575 611 English
    No Ext Axes
    2400/16 M98A
    530 Advanced Functions

    If 24-14775 is your robot then you've been very lucky!

    If you press the manual button (looks like a hand) then SCAN button a three or four times you will see a *LANG button on screen (LANG text depending what language you are in at the time).
    Then press this * button and you can select a different language very easily. No need for any fancy parameter changes on the S3 controller.
    Button always has a '*' so you could find it whatever the language was.

    I think (??) VERKTREL might be the RELTOOL function on a positioning instruction.

    I have an English S3 programming manual if needed.

    If you bought the system used from a used robot dealer then ask the company if they have a copy otherwise you will have to go to ABB with the serial number of your system and purchase a new key disk.

    RW2.0/2.1 is for the old M94/M94a controllers (S4).
    RW 3.0/3.1 is for the M97 -> M98A etc controllers (S4c). Totally different controller / boards etc. and is not compatable with the older controllers.
    RAPID language the same but will have more instructions/functions etc.
    Even going between some RW3.0 to 3.1 you had to check compatabilty then possibly need upgrade some boards.

    RW 4.x is for M2000 controllers (S4c+)
    Rw 5.x is for the IRC5 controllers.

    Are the cabinets exactly the same internally as there are a few versions of boards etc.?
    Is the robotware the same between the cabinets?
    Not 100% sure but the robotware keystring / robot serial number loaded in each system might also bring up some issues when loading complete backups from other systems.

    If you have backups from both cabinets you could compare to see whats loaded into the spare cabinet v running cabinet.
    Might be easier to 'modify' a backup with the robots sync parameters and also the eio.cfg file for the I/O. Then have a folder ready with up to date program/ system modules to load one by one (the RAPID folder from the running system backup folder will have all running modules).

    Not 100% sure about the 120 but most ABB robots have a ptc resistor in each motor and all six of these ptc resistors are connected in series (that's why you don't get any reference to which motor has the problem).
    Not clear if this has failed completely or is intermittent but I would assume as there is no heat evident that you have a cabling problem (quite common to loose the core in the base cable). You will need to dig out the drawings and test the wiring/ptc with multimeter.
    The error unfortunately occurs after 30 seconds after drives go on (even if the ptc has failed all the time) so you will need to watch the input in the I/O window (DRV1PTCINT in saftey signals) )and you will see the input change state (if its intermittent) when robot is being moved.
    One thing to note is the signal is fed with 0v (not 24v ) so the signal appears inverted.

    Please post the full error number and text to make it clearer for people to assist you.

    Is this the correct error?

    20214, Limit Switch open, DRV1
    Description The limit switch on the robot has opened.
    Consequences The system goes to the Motors OFF status.
    Probable causes The robot has been run outside the working range defined by the limit
    switches fitted to the robot.

    Recommended actions
    1) Press an eventual existing external "Override Limit" button and
    manually jog the robot back into the working area.
    2) Resume operation.

    vMax is a named speed data
    z200 is a named zone data

    vMax will have four 'parts' to it (go to data types - speed data) then press enter to look at these four values - depending on pendant/controller type.

    v_tcp The velocity of the tool center point (TCP) in mm/s.
    v_ori The reorientation velocity of the TCP expressed in degrees/s.
    v_leax The velocity of linear external axes in mm/s.
    v_reax The velocity of rotating external axes in degrees/s.

    speeddata vmax:=[5000,500,5000,1000];
    speeddata v10:=[10,500,5000,1000];
    (notice that the v.ori,v.leax and v.reax have very high standard values in all speed data)

    Zone data has more components

    finep Defines whether the movement is to terminate as a stop point (fine point) or as a fly-by point. (True or False)
    pzone_tcp The size (the radius) of the TCP zone in mm.
    pzone_ori The zone size (the radius) for the tool reorientation.
    pzone_eax The zone size (the radius) for external axes.
    zone_ori The zone size for the tool reorientation in degrees.
    zone_leax The zone size for linear external axes in mm.
    zone_reax zone rotational external axes

    Examples :
    zonedata z1:=[FALSE,1,1,1,0.1,1,0.1];
    zonedata z200:=[FALSE,200,300,300,30,300,30];

    Standard speeds and zones come with all system v5, v10, z1, z50 etc and should be left unaltered but you can create your own if required.
    In theory you can declare any speed values but the robot generally restricts itself to what it can physically manage. You should also be aware the you only see the declared data names on the move instruction. The actual values should be checked in data (especially if you see named data without a value as vMax or vAirFast etc.)
    A 'rough' rule would be the MoveJ would have faster tcp speeds (moving fast between process start/end positions) and bigger zones to make direction change smoother.
    MoveL would have slower tcp speeds and smaller zones (down to to fine 'stop' points) as these would generally be approach points or move during a process - every programmer will have different views on this and it depends completely on robot/ load/process/ fixturing etc. etc.

    S4c+ systems are originally delivered with the keystring printed on the RW dvd.
    If you lost this keystring then you can use RobInstall to generate a system pack from a backup that contains / files. Then you can download via the service port or make new boot disks.

    The older S4c systems always used a key disk (they do not have the service port). If you do get a new key disk make a copy immediately just in case!

    Unfortunately you will need to contact your local ABB office to request a new key disk for your system.
    The Key disk contains a few files that unlock the software options on the boot disks that were ordered with the system originally (robot type/ configuration and any process ware etc.)

    Not much to work with from your question.

    Are there any errors on pendant?
    Any other LEDs flashing or 'red'?
    Does the EN light come on briefly then go off?

    Internal errors have little or no information available as they are relating to machine code tasks that the Gurus in Sweden only know about.
    If the errors prevent something working or lock up the controller then the normal ABB response is to perform a warm start, p-start, I-start then finally a c-start etc.(only method if system is locked up)

    Check if a plc(if there is one in your system) is sending a program stop signal (system input) or that there is a sensor (e.g. weld gun crash sensor) that is sending a program stop.

    You need a crossover cable to connect to the controller. Make a backup in the hd0a/backup directory- sometime there is a hd0a/24-12345/Backup directory (24-12345 is the serial number of robot as an example).

    As soon as you have connected the correct cable and set your IP on the PC then connect through filezilla (or similar ftp browser) on - username 'ABB' Password 'ABB' as you must use a username and password.

    navigate to the backup folder and then download to PC the backups inside the directory.

    If you mean the ABB web based tool for monitoring / backing up and fault code viewing then I would strongly suggest you ask for a real demo from an ABB engineer before signing any contract for the remote diagnostics hardware and MyRobot access. If you have the sales rep demo it then you get a different perspective.

    Basically ABB install a Mobile GSM card in each cabinet in between the service port and controller - this also usually requires latest robotware installing.

    This card is reporting back faults etc. to a monitoring centre (somewhere in the world). This 'call centre' handles what happens next when a controller flags up a fault.
    As you can imagine - lots of faults can be generated by a controller most of which are not important but obviously some are instant 'wait for a phone call' type faults.... that's the weak spot - Thousands of controllers, thousands of faults 24/7 all going to a centre to evaluate and call the relevant person.

    ABB say that designated people will be called/texted/emailed when certain errors occur but from the feedback from my customers this is very rare (fan errors seem to be the one thing they get called about!!)

    Usually production people have grabbed the maintenance guy by the scruff of the neck and they are on the job way before any phone call comes in.

    There are also two levels of access - one allows monitoring of faults etc and some basic functions, the other includes backing up remotely (cost could be different of course).

    I really hope they have improved it or are working on it because it could/ should be very very useful tool but so far I find it to be not as versatile as described but you might have a better opinion once you see it in action.

    I saw a similar thing happen once on a controller that would not accept any more mods. It wasn't down to a maximum number just a corrupt directory that was blocking uploads (s4c+).
    We could create another folder and save to that one no issue but nothing would upload directly the HOME directory using ftp voyager. We could upload from new folder then open in the pendant then save back to Home directory but after a few more days then even this would fail.

    In the end a cold boot was needed.