Posts by Too_Fast_46

    MotoComES works with the newer protocol, High Speed Ethernet Server. I have not personally used MotoCom32 but from what I am told MotoComES is faster and possibly easier to implement. For HSES to work, the robot must be DX100 with newer software, or DX200/FS100/YRC1000. It's also a paid option on the robot.

    Have you tried installing MotoSim from an administrator account then running it from your user account?... I personally have admin rights, but most people in our company do not and IT was able to make it run for them. I'm not certain how at this moment but there is a way.


    Potis did a nice job with this list, just one warning wtih #2. Have a timer- 0.01 seconds is sufficient- before the jump loop. Loops like that without a timer *can* overload the processor and cause alarms. I learned that one the hard way.

    It is absolutely possible. I use visual studio to create C# applications communicating to the robot using the high speed ethernet server protocol. You can find a manual on Motoman's website for how to enable it on the robot (minus a necessary paid parameter), and how to format the packets for transmitting the data. To save time in development, Motoman does offer MotoCom ES which comes with a library of the instructions to use in your visual studio application.

    Since first asking for your RS.PRM, I spent more time researching the parameters which helped me understand which ones are necessary. The one that stands out to me in your robot is RS007. Try setting it to "2".


    There are parameters in the HS Eserver manual, but here are some parameters I've found through trial and error that also have an effect on the HS Eserver and my recommended settings:
    RS000=2 Port protocol
    RS005=1 BSC Port Function
    RS006=1 Data Transmission Ext.
    RS007=2 Allow actions outside of REMOTE mode

    I do not recall any differences in the packet format besides the settings for each instruction. Have you used wireshark to look at the packet data?


    If all that is correct, there are some RS parameters that could be the culprit. I've had robot control instructions work, but file control did not and RS005 to 1 fixed it. If you post your RS.PRM I can take a quick look.

    There is a parameter responsible for this:
    S2C541 Specify the permission of variable and I/O input during the play mode. 0: writing is allowed. 1: writing is not allowed.


    A related parameter:
    S2C542 Specify the permission of variable and I/O input during the edit-lock status. 0: writing is allowed. 1: writing is not allowed.

    I use MotoSim EG-VRC extensively for offline programming. It has more than paid for itself for proving out and developing new cells before we ever install the robot. We do primarily pick and place applications so I cannot provide feedback on welding applications. I will say that it's far more useful when you have access to CAD software to create the STEP or IGES files to load into MotoSim. With accurate CAD data for your cell, I don't see any reason you wouldn't be able to do a large portion of your programming offline.


    Other features that it's useful for is setting up cubes or FSU, because it creates models that help you visualize the zones. Also, I use the file manager all the time. Using it, if your PC is connected to the robot via ethernet, you can transfer files to/from the virtual robot controller. Faster and easier than dumping the files from MotoSim to a USB then loading into the controller.

    The GETS instruction will allow you to get the current robot position to a position variable. The GETE and SETE (read get element and set element) instructions help to manipulate the data.


    One way to accomplish what you describe:
    NOP
    GETS LPX000 $PX001
    GETE LD000 LP000 (3)
    ADD LD000 100000
    SETE LP000 (3) LD000
    MOVL LP000 V=100.0
    ..
    ..
    END


    Those instructions would get the current robot position, in base coordinates, and put it in local position variable #000. Then it sets the Z data from LP000 to local double variable #000. Then 100mm is added to LD000. LD000 is then put back into the Z coordinate of LP000. Then use a move instruction to LP000.


    Hi Too_fast_46,
    I hope that 46 stands for Valentino Rossi :toothy9:


    Sure does :icon_smile:


    From things I've heard, I was under the impression that you had to be in yaskawa mode with a DX200 to load .PRM files. I'm assuming that's still true with real controllers, but the virtual controller just let me do it in management (should've tested it earlier). If I wasn't able to do that, I would definitely want whatever piece of code you've made work.


    In my opinion, with the new security of the DX200, they should just give you an option to go into Y mode and/or turn on a list of options in MotoSim. Might as well let people experiment with it there so they will purchase it for their real robots.

    This is a very delayed reply, but someone may find it useful some day. Here are some simple job examples.


    Example job using MULMAT: This job will create user frame 1, rotated around Z at 45 degree from the base frame.


    GETS LPX000 $PX001
    MUL LP000 0
    SET LP001 LP000
    SET LP002 LP000
    SETE LP000 (6) 450000 Sets up an origin point at the base, rotated 45deg about Z
    SETE LP001 (1) 100000 Sets up LP001 as a 100mm offset in X
    SETE LP002 (2) 100000 Sets up LP002 as a 100mm offset in Y
    MULMAT LP001 LP000 LP001 Overwrites LP001 as a point shifted 100mm in X from the origin point, LP000
    MULMAT LP002 LP000 LP002 Overwrites LP002 as a point shifted 100mm in Y from the origin point, LP000
    MFRAME UF#(1) LPX000 LPX001 LPX002 Creates the frame


    Example of job using INVMAT: This will calculate the offset from a point, back to the origin of its frame.


    GETS LPX000 $PX001
    MUL LP000 0
    SETE LP000 (1) 100000
    SETE LP000 (2) 100000
    SETE LP000 (6) 450000
    INVMAT LP001 LP000


    Picture moving to LP000, a point 100mm in X and Y, with a 45 degree rotation. In this job, this PVAR is in base coordinates but it would be more realistic in a user frame. The INVMAT instruction then calculates the offset you would need to say IMOV the robot from LP000 to the origin of whichever frame the PVAR is in. INVMAT and MULMAT work in 3D so it's even more useful when Rx and Ry values are being used.

    Just to be clear, there is no way to get into Yaskawa mode on a VRC without going into maintenance mode? There are several options we use that can't be turned on using maintenance mode. I haven't been stuck yet, but surely will be on the next DX200 cell I develop.


    3) Using MULMAT and INVMAT


    I don't use this one often, mainly because I don't have a good understanding of how they work, but you can use a predefined offset position variable (call it P002) to generate a new position variable (call it P003) based on another (call it P001). To clarify, the instruction does matrix math on P001 and P002 to calculate P003. The "matrix math" is the part that I don't really understand.


    I use MULMAT rather frequently for calculating frames. It essentially calculates the result of applying a shift to a position, in 3D. For a crude explanation of theory: when creating frames with a job, you often start with the origin point. Then to create the frame you need ORG, XX, and XY. Use the MULMAT to apply an offset of whatever distance in X, to the origin, and the result will be XX.


    As you might guess, INVMAT is basically the inverse of MULMAT. If you wish to calculate the offset from one point to another, the INVMAT is very useful.


    That's just a quick description. After lots of :wallbash: , I feel like I finally figured those two instructions out so I'd be willing to help others if they were interested.