I am working with Micrologix1200 to control some remote pumping stations, because of the cost the customer decided to use GPRS modems.

I can´t have a reliable communication, the link between the RSLinx and the PLC has a lot of dropped messages.

I appreciate if anybody with experince using GPRS can give me some comments in order to debug what is going wrong.

cordially

 

it has to do with the latency between messages and the protocol timing. you might try increasing the timeouts or... Hopefully Lynn Linse from Digi will respond - he's the man!!

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
http://www.tsuonline.com

 

Well, that's for the vote of confidence Jeremy, but it may be that RSLinx will never be happy with unreliable comm lines. Unlike Modbus where "no response" is viewed as "normal behavior", RSLinx treats "no response" after 3 retries as very bad & requiring human intervention. DF1 uses the ACK/NAK/ENQ/retry design, so any 1 or 2 loses is recovered eventually. Thus RSLinx has a stricter view of many comm failures.

Have you tried the new "DF1 Radio Modem Protocol"? Newer MicroLogix 1200 firmware will support. I would hope RSLinx supports that - I have heard Kepware OPC also does. This would cut the data movement in half (no ACK/NAK), so could save your customer money$$. It causes DF1 to behave more like Modbus in simple poll/response; so this means "no response" is now "normal" and the requester will just retry instead of abort the connection.

Best Regards
- Lynn A Linse, www.digi.com (Ethernet-to-Serial Experts)

 

I've use Airlink cellular modems with MicroLogix and RSLinx and had similar timeout problems. I ended up extending the RSLinx DF1 Full Duplex driver timeout to 5 seconds to get reliable, though painfully slow, communications.

These particular modems take nearly 1 second to connect to the cellular data network, then another second to connect from that network to the other modem. Supposedly we would have much better communication if we used the Internet to connect to the cellular data network with our computer, but this was mostly a controller-to-controller link and we didn't have that option when we had to go online.

Your mileage may vary, of course; I was using Airlink Raven modems and you're using some other sort of GPRS modem.

I agree that DF1 Radio Modem would be a better protocol than DF1 Full Duplex for these purposes, but RSLinx doesn't support it.

 

It may not be supported, but RSLinx will work with a Micrologix network running DF1 Radio Modem protocol using the 1770-KF3/1747-KE point to multipoint DF1 driver. It seems to work very well, even on a large network, once you establish a good modem network for it to utilize. I've used it with radio modems, with NetAIC networks connected to radio modems, and with PLCs and NetAICs directly connected with a CP3 cable, for nodes 1-255, and bauds of 19.2k and 38.4k. This is with RSLinx version 2.42. And I'm talking about a direct connection from the computer to the master modem. There is no actual KF3 box being used.

I don't know why radio modem protocol is not supported with this, or a similar Linx driver. We are currently using the setup described above on a 100 RTU SCADA network - (also remote pumpstations with Micrologix PLCs). It is so much faster than half duplex that there is no comparison, but I have not seen or heard of it recommended anywhere. I found out how to do it with trial and error after discovering that the half-duplex master driver was not going to be fast enough for RSView.

Once the RTU node is found and comms are established, the KF3 driver stores it in its list of nodes that show up in RSWho, and it will stay there even if it temporarily times out or the RTU is physically removed from the network.

It would be nice to be able to manually enter node numbers in a list, as you can with the half duplex master driver. But as it is, you are able to limit the range of browsed node numbers by using the driver properties menu, and to change the time-out if you need to. You can also force the network to DF1 (master or slave), because that's what it uses once it finds the node.

This helps, especially when you are first getting the node established in the list. You know for sure, when the icon pops up, that you did establish comms with that RTU at that point. But after that you might see a red X through the node icon at times, even if the connection is still OK. You won't need RSWho by that time though, as the topic will have been established.

It would be great if Allen-Bradley/Rockwell Software would get this protocol supported for RSLinx. For what we normally do with SCADA, trying to use a master PLC with message commands to all the RTUs is far too awkward. The data needs to go straight to the PC or server anyway. Not having this protocol listed in Linx is puzzling, to say the least. Half-duplex will never be fast enough for all the data that our clients are asking for.

So for your case, if you're running a smaller network of pumpstation RTUs, you might try DF1 Radio Modem protocol on the PLCs, and lengthen the timeout on the RSLinx AB-DF1 1770-KF3 driver properties. If GPRS modems will work on a point to point full duplex DF1 driver, I would think this point to multi-point method may work as well. I found early on that radio modem protocol PLCs would connect with the RSLinx AB-DF1 SLC/Micrologix driver, but it doesn't support addresses other than node 1 so it wasn't useful for SCADA. For the KF3 driver, your modems would have to support point to multipoint with host broadcasting on the MTU modem. They would also have to match one of the baud rates available for the KF3 driver.

The modems I've used with Radio Modem protocol connecting directly through RSLinx are MDS Transnet and Esteem. Esteem explains how to use the radio modem protocol with their instructions, but MDS does not. MDS only gives a short explanation for how to use simulated full duplex mode, but I preferred the MDS as being less restrictive once I figured out how to configure it. The MDS radio IDs don't need to match the node number, so they are more transparent than Esteem in that respect.

I'm going to have to look at the Kepware OPC drivers more closely. Perhaps they now support radio modem protocol, and not just half duplex DF1 for radio modems, although this thread is the first I've seen mention of it.

cheers to all.