Posts by Too_Fast_46


    ifound a beteer way for the speed overide. use the pro face to change a bit variable. then make a system job that will use the DIN instruction. this way you can control live your speed through a variable


    Or you could use the CIO to move a register value so you don't have to use a system job. The reason I didn't do it that way is because then you would need to interrupt the cycle to change the variable from the I/F Panel.

    The attached document is the one I use for trying to understand the capabilities of the E-Server function. Starting on PG30 of the PDF, there are explanations of what the instance and attribute do for each address type.


    I have used the Proface to call a particular job, or see the job list of the robot. My method is to set a byte variable as an index, call the master using the CIO, then use the index to call the desired sub-routine.


    Reading I/O from the proface is an easy one, but I couldn't figure out inserting an image inline with text.
    Class: Use "I/O Data"- allows you to read literally any I/O address in the robot
    Instance: assuming familiarity with Motoman CIO, use the 1 digit class + 3 digit group number.
    For example, universal input #10 = #00021. Set "Instance" to 2.
    Attribute: by default is 1. Not sure why, but it works.
    Control Address: by default is 0. Again, it just works.
    Bit Number: this is the last digit of the Motoman CIO address.
    Using the previous example, #00021. Set "Bit Number" to 1.


    As far as writing I/O, the only addresses that can be controlled by the Proface are the network inputs. For DX100 this is #2501X-#2756X. For DX200 this is #2701X-#2956X. So to make them do anything, they must be mapped out in the CIO.


    As for changing the speed of the robot, are you talking about using the Speed Override function or changing the programmed speed? I currently have the Speed Override function mapped out for 20, 40, 60, and 80 percent speed- able to be controlled from the Universal Outputs, I/F Panel, or Proface. You guessed it: mapped out in the CIO.


    I can locate the center of the holes and after I have located the center, the sensor frame moves on the holes so laser beam and hole center align, there is a also a distance between last sensor and hole. I want to process the holes with a tool that is fixed on the same flange but at 90 degrees to the laser sensor.


    I have tool data for the laser sensor and processing tool. I'm using a user frame where all measuring points are located.


    I'm not crystal clear on how you're calculating the user frame. I may be oversimplifying this, but I'm assuming you have the user frame origin located at the center of the hole, Pt. If that's true, you shouldn't even need the offset from there to the "tool" TCP.


    1. With a PVAR on your user frame, multiply it by zero. This is the ORG of your user frame.
    2. Convert that PVAR to Base using the "tool" TCP. By using the CNVRT instruction with the correct tool label, the robot knows to move its "tool" tcp to those coordinates.
    3. Move to that point.


    If you still need the offset from the user frame origin to the "tool" TCP at the point in time as the picture shows, the INVMAT instruction should do it.
    1. Get a PVAR on your userframe with all zeros.
    2. Get the robot position in Base coordinates.
    3. Use the INVMAT to get the offset between the UFRAME ORG and current position.


    I remember that sometimes the line numbers were not shown even on DX100, only the error code. It may depends on the error code.


    He's right. I've had a DX100 that gave me a line number which didn't even exist in a job because I typed "IF" rather then "IFTHEN" or forgot an "ENDIF." Also, no specification of line number for not declaring local variables which were used in the instructions... it might not be a DX200 thing.


    There's one big gotcha to this method however: if the robot is passing through the point, rather than actually stopping there, then I have seen B000 never change to 1 as I passed the point. Two solutions here, 1 is make your cube bigger (in the ROBOT/INTERFERENCE menu) or force the robot to stop at the point, by adding a PL=0 tag to the move instruction.


    Out of curiosity have you tried changing the "check measure" setting from feedback position to command position? Or is this setting overwritten when the new work home position is taught?

    Do you have any prior programming experience or manuals to reference?


    To get you started, I would recommend using the shift function to offset your initial position. Use the JUMP and *LABEL instructions to create the loop for adding each increment of the offset.

    Glad it helped.


    1) Correct. You can only control the state of the Network I/O, then map it using the CIO.
    2) I have not done anything like that. The closest thing I've done is home return sequence that requires you to hold the button to continue moving. That was done by calling the master, then calling the home return job using the state of a universal input. There's probably a better way to do it though, haven't found it yet.

    I couldn't find the sample we initially started with- it wasn't the one from the website with mostly Japanese and confusing scripts. I took one of ours and stripped most of it down. Should give you an idea of how most addresses work as well as some of useful common ones- servo on, start, etc.


    Hopefully attaching it this way works. I'll answer any questions about it that you come up with.

    Just to be sure, you're using the High speed e-server option- not Moto EIP? (High speed e-server uses the CN104 LAN port.)


    If so, I can help you some. The documentation is not incredibly helpful. The addressing system can be confusing. I'll admit for most operations I just use the network I/O and map them in the CIO to where I want.


    If you give me a preferred method to send you something, I may be able to send you the template project file we started with that gave us several pre-configured buttons for servo on, start, alarms, etc.

    This seemed a lot simpler when I realized it would've been a lot easier to do this:


    DIN LB010 IGH#(1)
    DIN LB011 IGH#(2)
    MUL LB010 10
    ADD LB010 LB011


    Duh :icon_rolleyes: . From there it was pretty simple to do this in the ladder:


    STR #12560
    SHR #00010,4,M006 OR WAND #00010,240,M006
    STR #12560
    WAND #00010,15,M007
    STR #12560
    MUL M007,10,M008
    STR #12560
    ADD M006,M008,M005


    Figured I'd answer my own question just in case anyone was curious.

    Hello,


    I'm using a tooling ID with 8 pins. They're divided into 2 groups of 4 to have possibilities of 0-99. (For those who may be familiar, this is using an ATI RF-10 electrical module.)


    As it is right now, I use the following to assemble the tooling ID into a byte variable:
    DIN LB010 IGH#(1)
    DIN LB011 IGH#(2)
    VAL2STR LS010 LB010
    VAL2STR LS011 LB011
    CAT$ LS010 LS010 LS011
    VAL B075 LS010


    This works just fine for me, I only provided it so you might further understand the real question: Can I assemble the values of the two half groups into a single register using the ladder? Honestly, I just want to have a constantly updating display to the I/F Panel of the tool ID without running a job.


    Sorry for a basic question here.


    What address creates a digital Input or output? I want to set an output on but I don't want to actually tie up a physical output.


    The digital or internally used address are 7XXXX. Just for your reference, the complete list:


    0XXXX Universal Input
    1XXXX Universal Output
    2XXXX External Input
    3XXXX External Output
    4XXXX Specific Input
    5XXXX Specific Output
    6XXXX I/F Panel Signals
    7XXXX Auxiliary Relays
    80XXX Control Inputs
    82XXX Psuedo Input
    25XXX-27XXX Network Input
    35XXX-37XXX Network Output



    Nope, unless somebody from Motoman knows it


    I have the same wish


    Ditto. No way to control a universal out, black dot i/o, with the CIO.


    Side note: I don't know if you've used the I/F Panel at all, but it's awfully useful for displaying various signals. It can display the status of universal I/O, external I/O, auxiliary relays, etc.

    You'll have to compare this to yours, but our robots have a rung that would be useful for this:


    STR #50010 -- Major Alarm Occur
    STR #50011 -- Minor Alarm Occur
    STR #50012 -- System Alarm Occur
    OR #50013 -- User Alarm Occur
    OR-STR
    OR-STR
    OUT #70020


    I don't know if that covers arc alarms and e-stops, but it covers most everything else. I'd either use that rung if it exists in your robot, or create your own.

    It really depends on your current CIO configuration. From Motoman, most of our robots are setup so you only have to turn on an auxiliary relay correlating to the right I/O alarm and it takes care of the rest. Does yours currently have anything to turn on #40012?

    FYI- there is a new ethernet IP card available that does allow you to still use the LAN port on the controller, available for the DX100's.


    As far as communicating with multiple protocols through the LAN port, I do not know the specifics. All I can say is we have had success communicating through the LAN port with a switch to a PC using Motocom SDK, for reading/setting variables, and simultaneously a PLC using a high speed ethernet server connection, UDP protocol. The only certain thing I do know is that communication with multiple instances of the same protocol, i.e. two instances of high speed e-server, is not possible.


    All I can really say is good luck.

Advertising from our partners