Ethernet Communications Guide/Control Logix 5550

[ispyisail]

Hi

I'm fighting with the guide instructions

My first problem was finding the correct "port"

I have now fixed this problem. see attachment

The Port I required was 44818

Below is the last instructions that I completed successfully, the instructions after that was getting a bit over my head.

To use this I/O type we have to apply the protocol to our new serial / Ethernet
device. First close the protocol configuration window by hitting OK. This will save
the new protocol. Now in the device configuration window, check your
communication port and put a check next to your new protocol. Give your device
a name, say, MyDevice, and hit OK. Now if you go to the channel table and
create a new channel you will see MyDevice listed in combo box in the Device
column. If you select the MyDevice device type you will see GetData in the I/O
type column. The D# and Channel number are not used in the code we wrote. If
you select a timing of 1 and hit apply, DAQFactory will start sending out D and
carriage return every second waiting for a reply. If you open the monitor on the
comm port you will see this.
That is the simplest of polling routines, and in many cases this is all you need. If
you had different commands to get different values, you would simply create
more I/O types and send a different command to the Poll function.

Has anybody got some suggestions on how i can connect to my PLC?

Thanks

Pages_from_PLC_ConnectionE_AB_Ethernet.pdf

[AzeoTech]

Do you have any specific information about the protocol? Are you sure the ControlLogix doesn't talk DF1 or Modbus already? Sorry, its surprisingly hard to find specs on AB hardware on their site. Anyhow, that would eliminate the need to create your own protocol. If you just want to get it on ethernet, you might consider using a serial to ethernet converter and doing DF1 on the serial port if the 1756 doesn't support DF1.

If this isn't an option, I'd really need to see a protocol specification to tell you how to do this.

[ispyisail]

How about this

http://forums.lavag.org/Industrial-EtherNe...t-IP-t9041.html

or attachment

I don't know if any of this information is usefull?

Is it impossible to talk me through building a protocol manually?

I would assume you would like to have the Contrologix protocol built into your software!

Thanks

ioclogix1_0_1.pdf

[AzeoTech]

I can talk you through creating a protocol manually, but you need to have the protocol spec in order to make it work. This is a pretty complex protocol and would be challenging, if not impossible to simply zen your way through it. Even if you could get something working, I'd be worried about relying on a protocol that wasn't verified against the documentation.

Unfortunately, the PDF only shows a few samples. Helpful, yes, but you still have to have the protocol spec. As for the link, that's to a LabView VI that claims to perform the communication. This is unusable for us because of copyright issues, and more importantly, we don't know the reliability of it. Also, we'd have to have LabView to be able to even view the VI.

I don't want to disuade you, just make the point that without the protocol spec you are pretty much out of luck. This is why we don't have a Siemens S7 protocol driver. The spec is not publically available and for us to purchase access to it from Siemens would require us to double the price of DAQFactory! This is why some OPC servers should cost $800. They have to cover the cost of the protocol spec. Of course others, I believe, are way over priced.

So, if you can find a protocol spec, then we can make quick progress, but be warned that it might be hard to find.

[AzeoTech]

Hmm, I see in that PDF there is a reference section with some links that might lead to the spec. There is also a note that indicates that even Ethernet/IP is a proprietary protocol that we would have to pay to implement.

Are you sure you don't want to do this using DF1 or Modbus? Ethernet/IP is typically a fieldbus protocol, meaning a protocol for communicating between PLCs and other field instruments and not so much for communicating with PCs. I know they use it for this, but given the proprietary nature, wouldn't it be better to support an open protocol like Modbus?

[ispyisail]

All right i guess that road is coming to an end.

I need more information on DF1 and Modbus! I don't really understand the concept or the requirements.

At the moment my setup is

PC<<-->>ethernet<<-->>1756-ENBT/A<<-->>PLC processor

What about OPC?

What about "RSLinx classic Professional " can we do something with that?

You could do what linux does with proprietory drivers, make the drivers a Plugin downloadable from sourceforge or some other site unconnected with DAQFactory

[AzeoTech]

You could do what linux does with proprietory drivers, make the drivers a Plugin downloadable from sourceforge or some other site unconnected with DAQFactory

Yes, this would be the option. We'd have to look at the actual license agreement. Its more that DF1 or Modbus would be a lot easier for everyone. Ethernet/IP is not a particularly simple protocol.

Exactly which PLC do you have and which ports are available on it (i.e. serial and ethernet)? Presumably there is a serial port that should run at least DF1, but you may be using it for something else.

As for OPC, this is certainly an option. I'd probably get the AB suite from software toolbox (www.softwaretoolbox.com). RSLinx is just another OPC server, and I think a bit more pricy than the software toolbox equivilent.

As for concepts: DF1, Modbus, and Ethernet/IP are just protocols. The analogy I like is that of a telephone. There are many different types of telephones: land lines, cellular, cordless, radio-phones, etc. This corresponds to the different hardware transport layers: Ethernet, RS-232, RS-485, etc. Then there is the communication on the telephone line: english, spanish, sweden, russian, etc (can you tell I'm watching the Euro championship while writing this?). This corresponds to the protocol: DF1, Modbus, Ethernet/IP. It doesn't really matter which language you talk with on a particular telephone type, and all languages work on all telephone types. This is why DAQFactory splits the protocol from the transport layer. It makes DAQFactory more flexible, allowing our users to use unusual combinations of hardware and protocols (and believe me, we hear about some unusual combinations).

The only thing you can't do is go communicate using different protocols, or using different transport layers without a converter. Transport layer converters are easy and cheap. A serial to ethernet converter is about $200 for a good one from a company like SeaLevel.com. Protocol converters are a lot harder. They exist, but are expensive. An OPC server, technically, is a protocol converter. It converts a particular protocol to the OPC standard. My analogy really holds. Its easy to convert from cellular to landline. The phone companies do it for us. However, if you are talking swedish and I'm talking english, we aren't going to get very far unless we have a translator.

Now then, all these transport layers are considered serial. This means that its made up of a series of bytes (well, really bits, but its always combined into bytes). So, its a series of numbers between 0 and 255. A protocol simply defines the meaning of these numbers. In ModbusRTU, for example, the first number is the ID of the device, the second is the command, then a tag number, etc.

So, if you have a spare serial port on the PLC that talks either DF1 or Modbus, then you can buy a serial to ethernet converter to put it on the ethernet layer and then DAQFactory can communicate with it directly. Or you can use an OPC server to convert Ethernet/IP into OPC which DAQFactory also understands, but this requires an extra piece of software so is more cumbersome and less reliable.

[ispyisail]

Thanks for your excellent post

My understanding is greatly improved

Processor is "1756-L55/A Logix 5555" and yes it has a spare serial port. I would assume it can handle DF1

I also have a copy of "RSLinx Pro"

I'm just trailing the DAQFactory to see if it suits my job. It

[AzeoTech]

If you already have RSLinx then its certainly worth a try. I'm sorry that its been a rocky start with DAQFactory. Connecting to hardware is always the hardest part with any software because there are so many variables and so many ways it can be setup wrong. For example, on serial communications you have to have the baud, bits, stop bits, parity, com port #, and protocol all set correctly, and the standards aren't always followed. ModbusRTU for example is typically 9600,8,e,1, but many devices use different parameters.

Anyhow, to avoid another long winded post: to use RSLinx/OPC, just go to Quick - Device Configuration, select OPC, then browse for the OPC server, then browse for tags. You can double click on tags in the tag browser to add them. This is all described in the help under OPC.

[AzeoTech]

Also, it appears that that PLC does support DF1 on the serial port (I think most AB PLC's do), so you can always get a serial to ethernet converter and then talk DF1 natively from DAQFactory and skip the OPC server. I'd start by going serial directly before buying the converter and make sure it does what you want.

[ispyisail]

OPC

I've got OPC to semi work, works well with integers but Character Arrays do not work. I beleive this is due to a bug in the version of RSLinx im using. With my version of RSLinx i can't browse my network for Character Arrays, only integers. I have overcome this limitation in other software by manually editing the link e.g. in Excel =RSLINX|Feed!'RECIPE[0].PRODUCT_NAME1,L1,C1' will display a Character Array.

Attachment is my RSLinx browser screen shot

DF1

I can't find the RS232 "serial port configuration" for my processor, I haven't tryed the default setting.

Do you know what the setting should be?

[AzeoTech]

Sorry, didn't get the screenshot, and don't know how to configure that hardware. It may be DF1 by default. My guess is that RSLinx will allow you to do the configuration.

[ispyisail]

It may be DF1 by default. My guess is that RSLinx will allow you to do the configuration.

You are correct

Question:

I think i have connected with DF1. Does DF1/RS232 have and IO browse feature.

If not how do i find my IO?

[ispyisail]

I've gone back to OPC

In respect to "character arrays" i was trying different configurations with no luck and then it started to work!!!

I then tryed to enter in other "character arrays" form other parts of the PLC memory and again it only works sometimes. Its crazy

I think there is a bug in DAQFactory in respect to adding channels with "character arrays"

I've added some screen shots

[AzeoTech]

Initially we didn't even support character arrays in OPC. I'm not sure its supported now and will have to check the source. But for know, try changing the I/O type on those channels to Synchronous.

[ispyisail]

But for know, try changing the I/O type on those channels to Synchronous.

Tryed this but it started logging instead of a static display

Asynchronous works best

I'm sure DAQFactory has bugs in respect to OPC/character arrays but i was trying to work around this but with no luck.

See screen shots

[AzeoTech]

OK, I will admit that character arrays were never tested nor really supported, however, it looks like they work somewhat. A couple things:

1) you get the second row on the first channel when you add a second channel because whenever you update that channel table, it has to resend the async list to the OPC server, which apparently triggers your OPC server to reupdate all the values, thus the second row.

2) You get the {} display in the variable value component because you forgot to put [0] after the channel name. This tells DAQFactory you only want the most recent row.

[ispyisail]

Thanks

Now it works

It looks like i'll finally be able to test the software

Your doing a great job, i wish other posters would accept that citech/rockwell type support requires citech/rockwell type payments.

[cjudson]

I am looking for the easiest way to solve what looks like a really similar communications issue!

Customer has a FlexLogix 5434. It is communicating with Software Toolbox OPC Power Server (TOP Server) running on a PC. TOP Server is then communicating with what looks like a protocol proprietary to a data service which forwards information on to that service. TOP Server has the Allen-Bradley Suite loaded on it.

We want DAQFactory to be able to read data from the PLC. From looking over this thread it seems like I could leave Top Server running (I can see the tags I want listed) and DF could read the tags from TOP Server. In other words, I'd like to replace the data service with DF running locally.

Can you suggest a way DF and TOP Server could communicate? Buy an add-on for TOP Server? If so, which one.

Thanks,

[AzeoTech]

What data service are you referring?

TOP server is just an OPC server. You can use DAQFactory's OPC client capability to communicate directly with it. Just go to Quick - Device configuration, select OPC, then browse for the server and then for tags. It is talked about a bit in the DAQFactory help file.