Integrating Balluff RFID reader via EtherNet/IP Explicit Messaging

[moofish2842]

Good afternoon!

For the past several days, I have been trying to set up this Balluff BIS018A RFID head to communicate with a Do-more BRX DM1E-M-D PLC. The PLC Ethernet/IP scanner function only supports explicit messaging and I am having trouble figuring out what messages to send. Here is the manual for the RFID reader. It doesn't say much about connectivity over EtherNet/IP, only showing what to do with the input and output buffers.

I have set up an environment for testing different combinations of class and instance for outgoing messages. I can get responses from things like class 1, instance 1, as they are universally dictated as to what kinds of data they define. However, I can't find out what it takes to send and receive active data from the head. Every combination I have guessed has resulted in an error response and a status code of 5, 8, or 20.

I downloaded the EDS file from the web configurator of the reader. Here is a link to the text of the file. I can't gleam anything that looks obviously helpful. I have tried many class and instance combinations involving 100, 101, 1, 0, 128, and 209.

I found the manual for another Balluff device using Ethernet/IP but the manufacturer-specific objects (chapter 5.9) don't seem to work. The generic ones do however so I know that communication is happening.

I don't really know where to go next for this kind of information except for to the supplier and manufacturer themselves. Does anyone have an idea what I could do?

 

[L33er]

Do-more is exactly what it meant, LOL.
No Thank you.

 

[LadderLogic]

Does this RFID reader model even support explicit messaging? It does not appear so.

 

[moofish2842]

I didn't think that it supported explicit messaging, but was pressured to find a way if at all possible. We have determined it was not possible. The original choice was going to be a Productivity1000 but they were out of stock. We have now obtained an in-stock Productivity3000 CPU and it works well.

 

[AlfredoQuintero]

The device supports the mandatory Assembly object. There are several instances of the Assembly object documented in the link below (from page 63 of the manual).
http://usa.balluff.com/manuals/Balluff_EMS%20RFID(Former%20Datalogic)/BIS%20U-62x_User_Manual.pdf#page=63
For example, Assembly instance number 0x65 is, according to this manual, the "Node 1 serial produce data". Instance attribute ID 3 of the assembly object is the data attribute. That is where the process data of the device is mapped. In case of instance 0x65 there are three DINTs and 100 words. So a GetAttributeSingle request to class ID 0x04, instance 0x65, attribute 0x03 will give you 112 words of data with the Node 1 serial produced data. And so on for other instances.

 

[moofish2842]

So here's the thing, I spent days working on just this issue. I learned a lot in the process. Using instance 100 for input and 101 for output, the input buffer could be read and it showed the CP and MT bits when it was supposed to. However, no matter how much I tried, I could not get it to process the output buffer. I could send a SetAttribute and then a GetAttribute and the values would be successfully stored and retrieved in the buffer, but there would be no response in the input buffer.

I later started up the simulator in Productivity Suite to confirm it would work. With implicit messaging enabled, the SetAttribute command would throw back an error whenever I tried to use in on the output buffer.

There were also many other things I tried that aren't listed here. I concluded that even if I were to trick it into starting an implicit connection (something I deemed impossible after more research), it would not work without two-way implicit messaging.

 

[AlfredoQuintero]

According to the manual, instance 0x70 is the consumed data for node 1. How did you structure the SetAttributeSingle request? By the way there is a free tool called Molex EtherNet/IP Tool that allows you to test explicit messaging, including for assembly object. It shows the response including proper Enlgish description of the CIP error such as "too much data" or "too little data" which is an error very easy to make but perhaps not so easy to see from the PLC engineering tool. You would have to use Wireshark with Ethernet tap to see this level of error description, but the Molex tool shows you this error right there in its screen. I am guessing the program to send the SetAttributeSingle may have had some issue of syntax. If you still want to pursue this, would recommend you get this tool from the Molex site. It is free of charge, as Molex donated this to ODVA.

 

[moofish2842]

Thanks for sharing that information. I actually had that downloaded already from when I was first trying to figure out what I was even dealing with. I really have learned a lot since then, although there are still many mysteries. I don't really have time to pursue it further though.
It's unfortunate that we had to go with the expensive Productivity. I half-seriously tried to push just running a raspberry pi or cheap Codesys PLC for the EIP communications since another device could handle all of the I/O!

 

[AlfredoQuintero]

is a speed game with exciting new techniques in which you need to get the ball across different tracks.

troll!

 

[plvlce]

troll!

Not the first and it won't be the last... I'm sure someone will be along presently to delete it (and the other post made from a different account).

EDIT: And gone. Just wanna say thanks to Phil or whoever he deputizes for their work in keeping the boards spam-free. (Was gonna say 'tireless work' but I imagine they sometimes get pretty tired of dealing with spam).

imo it's generally better to just report the spam rather than post a response to it, even just pointing it out. That way when it gets deleted the thread isn't left with off-topic chatter about the spam...

 

[AlfredoQuintero]

imo it's generally better to just report the spam rather than post a response to it, even just pointing it out. That way when it gets deleted the thread isn't left with off-topic chatter about the spam...

...agree, and when reporting the spam one has to remember to delete the link in the spam message, otherwise the report itself becomes a vector for the propagation of the spam.