Labview TCP/IP Communication with Keyence PLC

[Seangoh]

Hi, I am working on an automation project and require TCP/IP communication protocol between Testers (Labview test program) and Keyence Nano series PLC.  The Testers need to write/read information to & from the PLC for control of start/stop test & provide pass/fail/error status.  I have checked with Keyence and they do not have any sample Labview TCP/IP code for the PLC communication.  Does anyone has some sample Labview code that can be shared for reference ?  Any help would be very much appreciated !  Thanks a lot...

Below is block diagram of the TCP/IP protocol principle from the Keyence user manual.

[rolfk]

Typically you have a number of options here but not all are equally feasable.

The Keyence proprietary protocol used by their own tools is most likely undocumented and therefore not even remotely an option.

Next, there are usually options for all PLCs to install optional software components on the PLC such as an OPC UA server or Modbus TCP and configure a mapping of your PLC variables to according OPC UA items or Modbus registers. These options are often an additional license cost on the PLC and in the case of OPC UA also on the LabVIEW side. Depending on the PLC manufacturer you may also have other options such as Ethernet/IP or EtherCAT but here the same applies about additional license costs. NI also has a paid Industrial Communication library for these two protocols but setting that up correctly is a challenge. The naming conventions for Ethernet/IP for instance can be confusing and it’s often unclear why things don’t work without other usually also commercial protocol analyzers that were written specifically for that protocol. 

Last but not least many PLCs offer a TCP function block that lets you define your own raw TCP packet that contains all the variables you want to have accessible. You then program in LabVIEW with the native TCP nodes to query this raw data and optionally also write to (part of) it .

[LVNinja]

I never used Keyuence PLC with labview. but you can start with simple TCP-IP commuinication example in Labview and use the ip address of the Keyence plc, the communication procedure example  in labview is very similar to the diagram you shared , if you know the commands, try using the exapmle to test if you can make any communication work. 

[Andrey_Dmitriev]

---

@LVNinja wrote:

I never used Keyuence PLC with labview. but you can start with simple TCP-IP commuinication example in Labview and use the ip address of the Keyence plc, the communication procedure example  in labview is very similar to the diagram you shared , if you know the commands...

---

...if the unit properly configured and programmed, of course.

Probably here is good "starting point" — Keyence#KV8000 TCP Communication.

I also haven't experience with Keyence PLC, but in the past was done very similar task for Siemens S7, where we implemented own TCP protocol over network and connected to LabVIEW-based SCADA. It was just hell from PLC side with functional blocks including indirect addressing, etc.

[Seangoh]

Hi thank you very much for the advice.  I will try out with the LabVIEW native TCP nodes and see if able to communicate with the keyence PLC.

[Seangoh]

Thanks for the advice , will try out with the simple TCP-IP communication example in Labview.

[Kyle97330]

The diagram indicates that the PLC is using Ethernet/IP.  That's a specific protocol, not a general term for "It uses Ethernet and has an IP address" or whatever.

LabVIEW has an addon kit that you can license that is specifically designed for this:

https://www.ni.com/en-us/shop/product/ni-industrial-communications-for-ethernet-ip.html

Alternately, there's an open source .NET DLL that can do the Ethernet/IP protocol, free but a lot less friendly and unsupported:

https://github.com/rossmann-engineering/EEIP.NET

I tried manually looking into replicating the protocol myself and it looked way too complicated to do it myself with raw TCP/IP.

[rolfk]

---

@Kyle97330 wrote:

I tried manually looking into replicating the protocol myself and it looked way too complicated to do it myself with raw TCP/IP.

---

The problem with implementing your own Ethernet/IP library is that it is fairly hard to get at official and accurate specifications for the protocol. The whole standard is maintained by the ODVA consortium and carefully guarded. The actual documents can be bought for a substantial amount of money (after signing up for a membership or an even more substantial fee if you choose to not be a member) that makes implementing this as a side project unreasonable. If you don't have a product to sell and to earn some real money with, it is simply out of reach.

Snooping the principles of operation from Open Source implementations such as your .Net component is usually tricky and those components are often only based on parts of or semi-official documentation that leaves a lot of room for interpretation. Without a canonical document to consult in case of doubts, it is a nasty trial and error approach that usually ends up to only work for the specific devices with which you tested it during development.

The CIP protocol itself isn't that complicated to implement with LabVIEW native TCP/IP nodes. Things get more tricky if you want to support the many different subprotocols and compatibility layers, Device Net compatibility, device discovery, etc. etc.

But that problem exists for pretty much every industrial protocol. The standards are guarded carefully and only made available on request and usually for a significant cost. It is understandable in a way as you don't want your standard to be poorly copied by some do-it-yourselfer who knows just enough to be dangerous but not enough to know that they are dangerous. A faulty implementation could in principle shutdown an entire production plant.