Hi,

I'm in a bit over my head here. Could someone explain how an iPad application would be able to communicate with a PLC (specifically an AB PLC like Micrologix) over wireless ethernet?

If I was explaining it to someone who develops iPad applications, how can I explain how to read and write data to/from a PLC?

Sincerely,
Programming Newbie

 

Communications are done using what are called "protocols" which are sets of rules about how to frame and interpret requests and responses.

"Modbus" is a pretty simple one that comes in both serial and ethernet flavors, and has the added advantage of being open (easy to get a copy of the spec). Hook your friend up with one of those as well as one of the open source implementations as a guide and learning tool.

As far as AB PLC's go, back in the old days before their head was up their CPU port, they freely published their comm specs as well, for example Publication 1770-6.5.16, the "DF1 Protocol and Command Set". Now they've gone the route of complicated (both in technical and legal terms) CIP protocols such as DeviceNet, Ethernet/IP and so on. I've DONE AB drivers and I'd really hate to have to implement one of those. Just the reading alone would probably kill me.

The reason this is relevant is that AB Ethernet comes in two flavors, which they refer to in RSLinx for example, as "ABETH" and "ETHIP". ABETH is, as I'm told, just the (good) old DF1 protocol wrapped in an Ethernet packet, while ETHIP is the (PITA) new protocol.

One approach to your task would be to do DF1, bury and unbury it in Ethernet yourself without the PLC's knowledge, and pop it back out an RS232 port at the other end. That would be doable. Or if your muLogix understands "old" AB Ethernet, you could probably pull it off. But if it only does ETHIP, I'm sure it's not going to be for the faint of heart, and not for your friend if he doesn't know what a protocol is yet.

There's also a guy named Lynn Linse, who's forgotten more about PLC comms than all the rest of us together will ever know, and he maintains a blog about it at http://iatip.blogspot.com/

Go there and start reading. Good luck!

 

At least the larger ML have a primitive web server built in as I recall, that shouldn't take more than attaching a wireless router or wap to the ML. You could check it out for $30 at walmart. Other comms would be difficult but you didn't say what you want to do. but the webserver would let you see the IO. I'm sure AB could fix you up with something for a grand or so.

Regards
cww

 

This link to Lynn's main site (not blog) will be very useful too:

http://iatips.com/

 

Define "communicate".

In other words:

- Do you want to get "n" words of data (Periodically, event driven)?

- Do you want to program the PLC from iPad (I'd hope not).

- Do you want to read/write realtime data or are you doing data gathering/statistics/logging?

Most PLC brands come with a native DLL or OPC server type of product that can run on a windows PC. This could then be translated to a TCP/IP or http type of connection by a third party program, either home grown or purchased (I've heard a lot about Kepware but never used them).

A more open solution is perhaps Modbus. I'd be really surprised if you could not find a Modbus library for the apple iOS (ipad, iphone).

I'd also look at if your PLC can do ASCII serial or ASCII Ethernet (TCP/IP) connections. The reason is that you can get wired and wireless serial to Ethernet devices from B&B really cheap (around $100 for wired). If you have a serial port builtin you are done. If it already has Ethernet then that approach works well too, just be real sure to make sure you can do generic ASCII messaging over TCP/IP (preferably multiple connections with choice of client or server on the device). If all you want to do is spit out information in a simple ASCII protocol these two approaches are very simple. It is perhaps going to be the easiest for your iPad programmer because all they have to do is open a socket client connection which is built into every modern device with Ethernet. I am doing such an approach with some data collection for our machines now, many of which are old 8 bit machines with good old RS232 ports. We are choosing to collect data to a central database and then it can be viewed by any device even when the equipment is offline. Your application might be different.

Ken

 

> Define "communicate".

> In other words:

> - Do you want to get "n" words of data (Periodically, event driven)?

> - Do you want to program the PLC from iPad (I'd hope not).

> - Do you want to read/write realtime data or are you doing data gathering/statistics/logging?

By communicate, I mean I'd like to create a few screens that can be viewed on an iPad. These screens would display integers, real numbers, strings, etc. They would also have push buttons that that alter the state(s) of bit addresses in the PLC. So, I'm talking about reading/writing realtime data.

I realize that there are some applications out there that already display a few tags, but I'm looking to create more of a custom HMI application that looks nicer and has more control.

 

Plenty of web based products out there that might be able to do this.

--
Bob

 

I'd say go with the Modbus TCP or the generic custom ASCII Ethernet protocol and write the code in the PLC to communicate with it. If you can find Modbus code for iPAD it might be easier that route. Otherwise defining a simple block send and receive is not that hard with a raw ASCII protocol.

Ken

 

I am developing a obj-c wrapper for the c modbuslibrary libmodbus. It is very easy to use..

Check out:

http://www.iutvikler.com/wordpress/?p=8

If you are in a hurry feel free to contact me..

 

Ken,

Thanks for your time/help patience so far. I'm learning about this stuff as I go.

I noticed the Micrologix 1400 claims to support Modbus TCP/IP. "Embedded 10/100 Mbps Ethernet port with EtherNet/IP, Modbus TCP/IP and DNP3 over IP support". http://www.ab.com/en/epub/catalogs/12762/2181376/2416247/9071972/9072580/print.html

Forgive my ignorance, but does that mean I can freely "pull" information from the MLX1400 as well as write values to it as long as my two devices are connected over the same network?

 

> I noticed the Micrologix 1400 claims to support Modbus TCP/IP. "Embedded 10/100 Mbps Ethernet port with EtherNet/IP,
> Modbus TCP/IP and DNP3 over IP support". http://www.ab.com/en/epub/catalogs/12762/2181376/2416247/9071972/9072580/print.html

Cool! That's a [positive] departure for AB, none of whose Ethernet products have supported Modbus/TCP before, AFAIK.

> Forgive my ignorance, but does that mean I can freely "pull" information from the MLX1400 as well as write values
> to it as long as my two devices are connected over the same network?

Maybe not, though it should still be fairly easy. There are two addressing concepts for Modbus when used with non-Modicon PLC's, ones that don't actually have their memory organized according to those addresses.

The first method is a fixed mapping between internal registers and Modbus addresses. Automation Direct uses this method.

The second method is to require the programmer to configure the mapping, so he might decide Modbus 40001 = Micrologix N20:0, and so on. The second method is the one used by tag-based Control Logix to support queries framed for a table-based PLC like a PLC-5 or SLC-5/00.

So you might have to do some configuring to decide where the data needs to go, and maybe even add some ladder to cluster all the stuff you want to poll so it's contiguous for efficient comms, or you might just have to do some research to see what the mapping is, if predefined.

 

If it supports Modbus TCP you can both read and write Modbus registers in the PLC. Usually there is a setup on the PLC where you tell it what registers in the PLC correspond with the logical addresses on the Modbus device. AB will undoubtedly have documentation for you and perhaps some examples from the factory or from your AB distributor.

Modbus is a polled scheme, so you will have a master and a slave (where the master sends out the read and write requests). Modbus is cool in a way because there is a read/write request where you can update multiple registers with one request/response pair over TCP traffic.

I'm not a Modbus expert but I've used it in one application. Typically devices are slow, in the 5ms range but if you are just getting data to an iPad it shouldn't matter. Once you get the communication going and map the registers it just kind of works for you in the background.

Make sure you can get code for the iPad and test it with the device, this should be your first step.

Ken

 

Hi Lars,

> If you are in a hurry feel free to contact me..

How did you get on with the ObjC wrapper for Modbus?