I am trying to use a Keyence LJG laser controller with a ControlLogix to capture the profile of an object. The LJG is capable of taking a snapshot of up to 800 points of data at a time, but I'm having trouble getting that data into the ControlLogix. Does anyone have any experience with this that may be able to offer some advice?

First you need to determine what communication methods are available on the laser controller. Next you need to see determine whether these communication methods are compatible with ControlLogix. For your information ControlLogix have serial, Ethernet, ControlNet, DeviceNet, etc.

I'm having trouble getting information from the Keyence rep, but from what I have found out so far, the LJG has RS-232 and ethernet. But I am finding out that the ethernet is only for use with the setup software, not for communication to a PLC. That basically leaves RS-232, which will require us to convert serial to ethernet, since our serial port on that processor is already being used. This is why I wanted to see if anyone had experience with this setup and possibly some other suggestions or advice that we may not be thinking of.

I'd experience with other serial devices, but not a laser controller. In my previous project I need to use the ASCII Read (ARD) and ASCII Write (AWT) that send command and receives data from the serial device via the PLC's serial port. Unfortunately both these instruction only work on a real serial port not the the Ethernet port. Maybe you can check out this product which add extra serial port to your PLC system.

Let's establish a couple of key understandings right away.

1. Serial and Ethernet are Protocol Families just because two devices speak Serial or two devices speak ethernet does not mean we can connect them. You would not connect the RS485 port of a bar code scanner to the RS232 terminal of your laptop.

2. Allen Bradley PLC's and PAC's doing ethernet speak one of several varities. The most comon is CIP not to be confused with the TCPIP Ethernet used by Personal Computers and Several Scanners and such.

The best recommendation I can make for your situation is to plan on accessing your laser controller thru it's RS232 Port. Since the RS232 Port of your ControlLogix is otherwise occupied I recommend you use a 1734-232ASC module and 1734-AENT to connect your Laser Controller to a Serial Port {the 232ASC} and then ethernet. The 1734-232ASC can be setup in the I/O tree of your controllogix and programmed without the use of the nasty ARD and AWT instructions. It gives you Serial over Ethernet and a second serial port for your Controllogix. Place the 1734 as close as you'd like to the Laser Controller.

Used the 1734-232ASC with a Sick bar Code Scanning array to retrun data froma baggage id system some years ago. We had to use the 1734-ACN and ControlNet as the AENT did not exist yet, but the concept is the same and solid.

How are you getting on with this? Have you got the data out of the LJ-G yet?

I'm asking because I may be doing something similar in the next few months. We currently have an LJ-G (80mm Version) on loan for evaluation. We are checking the cut angle of the sealing lip on oil seals and also the size of the PTFE band on shock absorber pistons. At the moment I'm just getting the data from the LJ-G via USB into my laptop. This is fine on my test rig but when we come to fit it to a production machine we need to capture the data automatically.

I was planning to use the RS232 port as this seems to have the most functionality in terms of data in and out plus control and set up of the LJ-G.

Cheers,

Graham

With reference to the LKJ series of products, it's not just a simple range finder, and you can't just have it output a series of readings. It simply doesn't work like that. If that's what you want, Banner makes a nice high resolution laser distance sensor that outputs an analog signal. It's not as good as the Keyence product but it does what you are asking. And that's why I went with the Banner device in the past.

The speed that it collects data is well beyond what you'd normally ever expect a PLC to handle. The controller works a lot more like a vision sensor than just a simple sensor. First, it processes the line scans that it makes (when triggered...and this is in itself very programmable) through up to 8 functions. Functions available are items like peak or valley height, average height, section area, width, position, angle, or a profile comparison to a standard. Up to 8 functions can be executed at a time. The outputs depend on those functions and can be either analog or binary values. The serial port produces roughly similar information to the analog (voltage or 4-20mA) or digital signals.

That's the key to understand here...you don't simply get "raw data". You get data that's been processed through the controller's functions. So interfacing can be anything from a simple digital input to an analog signal to a serial data stream of the same kind of information. The whole idea of the product is that as far as data processing and analysis goes, you incorporate those functions directly into the Keyence product. The PLC gets fed processed outputs (such as go/no-go) and deals with it accordingly. This was done simply because the raw data stream speed is so high that it isn't realistic to record raw values in most cases, not even with a decent quality PC.

The Keyence reps seem to have a rough time explaining/understanding this themselves. I happened to talk to one that used to work in that department so he was much more useful than the others I've spoken with in the past.



Actually, CIP is to be confused with Ethernet, Arcnet, AND RS-485! CIP is a packet format and some additional protocol details. The underlying physical media and transport layers are different. ODVA has defined no less than 4 of them. They are DeviceNet (CIP over CAN which is an RS-485 serial variant), ControlNet (CIP over Arcnet which is an old competitor to IEEE 802.3 Ethernet and shares the same physical media specifications), and Ethernet/IP (a horribly chosen marketspeak name, which is CIP over TCP/IP OR UDP/IP, which uses Ethernet as the underlying transport layer/physical media).

The basic idea that BobLfoot is describing is correct, but saying that CIP is NOT TCP/IP isn't quite correct. But just saying that a device speaks Ethernet or Serial by itself doesn't help either. For instance, SYNET was the Ethernet protocol used by Square D PLC's. It is Ethernet as well, but does not use IP. This makes interfacing to it thoroughly confusing. All this protocol soup stuff is not black-and-white. There are so many subtle variations in the way that the specs are written that it makes your head hurt just thinking about it. For instance, many Honeywell products use Modbus/RTU, but they use a particular and very unusual Modbus/RTU protocol variant.

"Serial" protocols (RS-232, RS-422, RS-485) specifies a physical, electrical specification. It doesn't specify the signal patterns. CAN for instance uses the same electrical specification but the signal patterns are so screwy that standard RS-485 transceivers can't deal with it. ASCII 8N1 for instance specifies the signal pattern. Modbus/RTU and Modbus/ASCII are protocols that operate on top of the standard ASCII protocols. DH-485 is completely different and incompatible with standard ASCII. DeviceNet uses CAN, and has the same relationship with CAN (and DH-485) that Ethernet/IP has with TCP/IP (and Ethernet).

"Ethernet" specifies a FAMILY of physical protocols (there are many more than are still in common use) such as the most common, IEEE 802.3, but all have a single electrical protocol specification and transport layer specification. The physical wiring specifications are also shared for the most part with IEEE 802.2 (Arcnet), which is the basis for Controlnet. Out of about two dozen different protocols that ride on top of Ethernet, just two (ARP and IP) are still in common use for the most part. IP similarly supports a variety of protocols. ICMP, UDP, and TCP are the most common. CIP isn't really a "third" one. It uses a mixture of UDP and TCP to get things done. Modbus/TCP is another, which uses just TCP (which uses IP which uses ARP and ICMP among other lower level protocols).

I appreciate all the input on this matter. We have chosen to try the Prosoft ASCII module (MVI56-GSC) to get this data into our AB PAC. We plan on grabbing the 800 point profile from the Keyence controller. Our goal is to be able to utilize the Keyence controller to grab the data fast enough and then pass it to our PAC, which should take some of the load off the PAC by allowing the Keyence to handle it. We will hopefully be testing the setup next week if all goes as planned. I will post findings when I have them.