Posts by SAABoholic

    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

    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.

    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...

    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.

    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.