Remote Control for Denso VS-6242E/GM and RC7M Controller

    Hey All,

    I just picked up a used VS-6242, RC7M, and TP-RC7/8 for a good deal off of eBay. I would like to use it with the Click PLC that I already have (I know people tend not to be a fan of them, but they work for most of what I do).

    I know I can do some digital IO through the Mini IO port, but I would also like to be able to write more than Off/On to the controller.

    The Click is capable of Modbus TCP, Modbus RTU, and Ethernet/IP. I know I can get a card for the RC7M to handle Ethernet/IP, which leads me to my first question:

    Does anyone have a part number for the appropriate Ethernet/IP card for an RC7M controller? I don't mind buying one if that's my best option.

    My second question is:

    Does anyone know if it's possible/have any info on communicating with the RC7M over Modbus? Particularly Modbus TCP. I found a document about Modbus.X providers and Modbus ASCII/RTU/TCP communication, however, that seems to be for writing your own software using ORiN, which I would rather stay away from if I can.

    I was playing with Ignition SCADA and its OPC UA Device Connections. If I add the robot's IP address as a device it shows as connected, but I can't find anywhere online that talks about Modbus Addressing for variables in the controller.

    It may not be possible or I may just be missing something, but I've spent the last 2 days googling and have yet to come up with something useful...

    Thanks!

  • 95devils November 6, 2023 at 12:51 AM

    Approved the thread.

    Ethernet/IP is the easier way to go as far as communications, but the cards are not cheap. A new one far an RC8 controller is around $1200. I would contact Denso support to get the proper part number for an RC7. The cards also require a licensed extension code to be entered in the controller to activate it. Unless you can get a valid license with one you find on eBay, a used card may not work.

    The RC7 communicates via Ethernet TCP/IP. In the past I have used a protocol converter such as an RTA 460MSTCP https://www.rtautomation.com/product/460mstcp/ to communicate between an older Automation Direct P3K PLC that only had Modbus and an RC7's Ethernet TCP/IP using comma delimited strings.

    Got it. I just called my local distributor to get a quote for an Ethernet/IP card, although I'd prefer not to spend $1200 if I can avoid it...

    It currently has a DeviceNet Master card in it, but I didn't see a good way to integrate that with a Click PLC. I may just have to deal with it and find a PLC that can act as a DeviceNet Slave...

    I was looking at the Click manual. Another option is to use the RS-232 ports and exchange ASCII strings. You did not specify what your application is, and/or if comms speed is an issue. Comma delimited strings require programming to parse the data so there is always that too. It does work though if you are trying to expand on "usable I/O" and exchange data such as position, timer, or counter values.

    Yeah, I think that's what I'm leaning towards at the moment. I'm not entirely sure where to start, as far as what those strings will look like though. Do you have any good resources for that? Ultimately, my use case is passing position data from a camera to the robot, and a few expanded IO values if I can do it with low enough latency.

    Hmmm… not really any resources out there that I’m aware of. It’s stuff I learned doing my first vision application and expanded on with other applications.

    The comma delimited strings can be configured to hold whatever data you want. Send and received strings should have the same structure so that you can use a similar subroutine structures in the PLC and the RC7 to parse through them. My strings have looked something like this (*Note- Not shown is the carriage return or carriage return/line feed at the end of the string. That depends on which one your system is set up for.):

    1034,125.83,-75.38,46.13,138

    • The first value is I/O boolean points converted to an integer. In the RC7 you can use ndInb.pac and ndOnb.pac to encode and decode the I/O points, however you are limited to 16 points. You cannot use 32 as the RC7 uses the last bit as the sign bit. I modified and made my own code so I can use more points, up to 31. In the P3K PLC I used the Pack Bits and Unpack Bits instructions. I’m not sure what instructions the Click has to accomplish the same thing. These are your “expanded I/O”. I primarily used them for manual commands and feedback so that communications latency is not a big issue.
    • The second, third, and fourth values are X, Y, and RZ coordinates. In this example these could be the coordinates of the part the camera is seeing.
    • The fifth value is a timer value. In this example it is the vison process time of 138 ms.

    The limitation to the strings is the overall string length. None of my applications ever gotten to that many characters.

    Hey all! Just wanted to come back and update what I ended up doing!

    I got a Modbus TCP to DeviceNet gateway from SST Automation. I can safely say it's not great, but it's also not terrible... Their support is also very helpful, although the fact that it was needed was not promising...

    I currently have communication between the robot and the PLC, however, I'm now stuck trying to figure out how to deal with the fact that each Modbus address is actually hitting 16 DeviceNet addresses in order to pass the 16 bits... I'm hoping I'm missing something in the controller, but I'm not 100% sure. Otherwise, I'll have to figure out how to do a binary-to-decimal conversion in the controller, which I would rather not do...

    That's where I'm at, now I just need to solve the conversion problem and I'm there!

    I liked the comma delimited strings idea, but the Click will only do ASCII over Modbus RTU, and I didn't want to use up my only serial port as I was planning to use that for a C-More Micro HMI.

    Thanks again, and if you have any ideas for how to deal with the conversion let me know!

Advertising from our partners