1200 to 1400 DF1 Protocol

[CJD 0]

Hi, Does anyone know if there is a differences between the DF1 protocol from the Micrologix 1200 to 1400. I have two .NET applications which are reading and writing to a 1200 and a 1400. The application reading and writing to the 1200 has no problem setting and reading the registers but it does not seem to work with the 1400. The application was developed using a 1200 PLC, does anyone know if there has been changes to the protocol between the 1200 and 1400 which could cause this issue? Thanks in advance the any help. Cian

[b_carlton 61]

Can you otherwise connect to both PLCs for programming, for instance, using the same parameters?

[CJD 0]

Do you mean the comm port settings, I'm sure they are the same expect for the Baud rates, the 1200 has a Baud of 19200, the 1400 is 38400.

[Ken Roach 194]

The DF1 implementation on all MicroLogix and SLC-500 controllers is identical. The MicroLogix 1400 supports a handful of datatypes and Ethernet functions that the 1200 doesn't, but if you have a DF1 application that works on the 1200 it absolutely should also work on the 1400. Can you capture the serial traffic ? Do you know which Functions and Command values are being used by your application ?

[JeffKiper 9]

you kind of answered your own question didn't you? "the 1200 has a Baud of 19200, the 1400 is 38400"

[CJD 0]

Do you think having a different Baud rate could cause an issue like this?

[JeffKiper 9]

I haven't done any. NET apparently but any other time your baud rate is different you can't communicate. Try to change that

[Ken Roach 194]

Obviously if your computer's port is set for 19200 baud and the MicroLogix 1400 is set for 38400 baud, they're not going to work together. I always use the 19200 baud default unless I have some screaming-fast interface that I need to run large DF1 transactions across. Do you get any responses at all from the MicroLogix 1400, or do you just send bytes off into oblivion that are never heard from again ?

[CJD 0]

I think I didn't explain myself properly! The 2 PLC's are on 2 separate systems. They are connected to 2 separate PC's. I can perform some commands in the 1400 such as setting boolean's on and off. One thing which is different about the systems is the serial connection on the 1400 is connected to a Serial Device Server manufactured by a company called ORing. Has anyone used these, could it be possible that this device could cause some interrpution or loss of signals between the PLC and PC. Sorry about all the questions but the systems are on a customer site, I am visiting there on Friday and would like to have some ideas before I am on-site. Thanks Cian

[Ken Roach 194]

Now we're getting somewhere. These "ORing" products look like rebadged Moxa or vLinx devices to me, though they might be original. I presume you're using "Virtual COM Port" redirection to your PC application. Which model from ORing are you using ? Remember that DF1 Full Duplex involves a great deal of back-and-forth acknowlegement packets as well as acknowlegements embedded in replies. This works best over a real serial point-to-point network. Any TCP to Serial device driver is going to have to "packetize" the serial stream into TCP packets. Some of them do it by size, some of them are actually aware of the serial protocol's start and stop bytes, some of them do it by RTS/CTS handshaking. Most of them just do it by time; they wait until there's a quiet period of a couple of milliseconds on the serial side then go ahead and packetize up the serial buffer and send it over TCP. I would first slow down the serial data rate. Because there's packetization and redirection going on, you might have some interruption in the packets that the MicroLogix can't handle at 38400. Try 19200 if you can. If the serial cable to the MicroLogix has the RTS and CTS pins (the 1761-CBL-PM02 will) then try enabling RTS/CTS handshaking. This might help the serial server handle packetization more efficiently. See if you can get information about exactly which transactions don't work. If you have a whole category of transactions that never work (like, say "read Integer word", PCCC code 0xA2) then you might be looking at a protocol issue. If it's just "we sometimes don't get a response" then you have a network issue and you need to start diagnosing the TCP network.

[CJD 0]

Yes its the Virtual Com port config I'm using. Its a IDS-5042, 4 port device (3 barcode scanners and the PLC) I will try slowing down the baud rate and see if this helps. If not I'll try monitoring the TCP traffic. Thanks for the direction. I'm not sure if handshaking is an option with the .NET application we have, I will have to check this. thanks again.

[CJD 0]

I haven't had an opportunity to test the Serial Device Server on this issue yet, but as a point of interest have many people on here used Serial Device Servers for this sort of application. Which manufacture did you use, which ones work well? Thanks