Manually Parsing EDS file or any Software that can map EDS files to I/O

HEY YALL,

I’m trynna get a position command and move command to a motor driver via ethernet port.

Motor Driver: CKD Brand

ECG-ANNN30-EN

Controller:
Arduino(P1AM-OPEN w/ eth shield), Beaglebone black revC, Raspberry Pi.

If none of these work, I may resort to a PLC, but I don’t like working on PLC so this is how I want to do it.

Attached is the EDS file and the user manual for the ethernet/IP version of the motor driver which is what I am using. How do I structure my packets and how do I know what to include in my packets?

The EDS file is organized with Parameter settings, 0-37. I would imagine, I send these 37 parameters, to the IP address and port of the driver via TCP command, and the driver should know what to do with it? which of the parameters equals the position and move command bytes in the user manual?

How do I manually parse the parameter data(EDS) to the input output data(User manual) explained in the user manual? Is there a software that can manually parse and organize for me? Or does anyone have well enough understanding to be able to guess the responsible parameters. I just don’t know if this is the right direction, and what the structure of the data packet should look like.
I will try CODESYS softPLC for beaglebone to load EDS file and see if it configures there. But not sure if that would make things complicated trying to communicate between CODESYS and Beaglebone Software.

https://www.ckd.co.jp/kiki/en/file/15919

https://www.ckd.co.jp/kiki/en/file/15975

It looks like they are forcing users to use their PLC to drive it. It has some register data and that is part of it, however the protocol is missing. Found a link for EDS on that pdf and its was some anime and non-english. If you had all the information you can use the sockets to communicate over IP. You might be stuck using their PLC. The BBB can handle the IP communication very well. If you had a complete working system you can sniff the communications between PLC and the device and recreate it then send the commands from BBB. That is only as an extreme last resort because it is very tricky and time consuming project.

Yes agreed, the last resort would be to sniff the data packets between PLC and driver, but I am starting to feel that may be the road I go down.
The company is Japanese so their english won’t be perfect. I am currently asking if they have a working PLC program they can use to enter position data and move actuator so that I can possibly sniff out the data. I don’t think they have a PLC they sell, so I am hopeful that outside connections can be made. There were also case studies of the driver being operated by a Siemens PLC(?), but that company is not willing to share program.

As for the communication protocol, It does specify “Ethernet/IP” so I do assume that it’s in a CIP packet format. But as you said they don’t have a device specific packet format. I wonder if the EDS file parameters is the format I have to send out the data packets. I will try this on Arduino and see if I get any kind of response. Thank you for your input.

Wonder what they are using, might be a some proprietary protocol?? If they don’t sell PLCs then it must be something common. Pretty sure that if its connected to Siemens it is using what is out of the box on that PLC.

Looked up what siemens is using and it is S7Comm protocol, proprietary. That one should be easy, the newer one is S7CommPlus and it is encrypted. More than likely can be cracked, just depends on how much time you want to spend on it.

Worst case connect it to a plc and bit bang the inputs and let it run some pre canned moves out to the device. That might be a simpler route, cheaper if you already have a programmer for the plc.

thank you for your input. the siemens plc was an example but i can’t imagine this driver won’t work with any other plc. with a EDS file available i assume any software/hardware that can parse that file can command the driver.
i forgot to mention the company has a configuration tool called [S-Tool] that can configure operation modes, IP addresses, parameters, and directly jog and enter distances to move to. so if i can send a command to move to a position, and i use wireshark to sniff out the command packet being sent over USB, i should be able to recreate that packet bit by bit and send out the same command right? but im not sure if the command via usb and command via ethernet are going to be the same…… it would be great to have a working system so i can sniff out the ethernet commands but this is the next closest thing i got so i will try this.

sorry, another idea i had was to run the [S-Tools] on the linux environment and have keyed macro inputs basically manning the software and manually entering distances and move commands via s-tools on BBB. how realistic is this idea?

I don’t know. It will all hinge upon communicating with it. You might have better luck looking at the TCP/IP stack on the bbb or even a big box connected to the device. Just so many unknowns it is very hard to even guess at this point. You might plug it into a dhcp router or static IP on a big box and use nmap or zenmap to see what the ip is and what port is open. If the IP and port is discoverable open that address in web browser and see if a login console opens.