df1 control logix vs df1 SLC an micrologix

There must be something thats different in the handshaking
between df1 on the control logix (Logix 5550) and the SLC micrologix product line. I ran into a problem with the USB adaptor I normally use with the SLC and micrologix products this adaptor works grweat with those products however did not work on the control logix. I've since ordered the AB recommended

The only difference in the default DF1 protocol configuration between ControlLogix and SLC/MicroLogix is that ControlLogix uses BCC error checking and SLC/MicroLogix uses CRC error checking.

"Handshaking", using the CTS/RTS and DSR/DTR lines of the serial connection, is not used by default on either controller.

And the DF1 framing (start of transmission, DST/SRC, Transaction Word, End of Transmission) is identical. It's the contents of the data packets (PCCC versus CIP) that is different, and that should make no difference to a USB adapter.

The serial data streams might be longer on a ControlLogix than a SLC, which might make a difference to a USB adapter with limited buffering capability or specific behavior for string length.

What brand and model were you using ? What sort of problems did you encounter ?

Up until Last week I had gotten by with the Omron CIF-31 adaptor this worked well for the micrologix and SLC's as well as the host, toolbus and sysmac protocols on the Omron. For the RS 485's on AB I use the 1747-UIC. Rarely ever having to connect to anything other than SLC's and Micrologix I was unaware there was a problem with the particular adaptor I was using, I've ordered the 9300-USBS adaptor from AB. RSn linx simply would not find baud or parity for the Omron CIF-31 until I tool a desktop PC to the machine I was using the 1756-cp3 cable

Autodetection of baud and parity is one of the functions that is sorta hit-and-miss with USB converters.

The way it works is that the RSLinx DF1 driver sends DF1 Echo commands (10 05) and listens for an understandable response at each baud rate, parity, and error checking mechanism it attempts.

Rapidly changing the framing parameters for the port is something that works fine with onboard serial ports, but you can see how it might be driver-dependent with virtual serial ports.

It might have worked with SLC and MicroLogix just because they didn't answer as fast as the ControlLogix does, or there might be something else configured on the ControlLogix port that made this function not work.

If you can't get DF1 Autoconfigure to work, try the default settings of 19200 baud, 8/N/1, BCC Error Checking for ControlLogix-family controllers.

Already tried that last step also tried reducing the baud rate, The company has already approved the new adaptor it should be here in a week till then I can use the Enet module now that I have it working again