Thank you for allowng me to this forum.

I am reading data from a SLC500, with a program that runs on a PC, usind the DF1 protocol.

When I connect the PC to the serial port of the SLC500, I get the data I want.

But the serial port is already used by another system, so I would like to use the DH485 port that is avaialble.

Question:
What do I have to use between the serial port (RS232) of the PC and the DH485 port of the SLC500 to make the communication work, without changing the software in the PC?

Thank you in advance for your help

Tell us which SLC500 you have. SLC5/03, SLC5/04, SLC5/05?
Is there anything connected to the "DH485" port now?
You will have to reconfigure RSLinx to connect to a DH485 network or port.

I have a SLC5/03
There is nothing at the moment connected to DH485 (RJ45 jack)
I am not using RSLinx. I am using a program written in VB that talks DF1
I do not intend to use this connection for programming the SLC500, simply get some process data at regular intervals, which is working if I connect to the serial port (DB9).
Thank you.

I would recommend using the 1747-UIC device. It plugs into your PC via USB, and enumerates as a COMx port. It uses the DF1 Full Duplex protocol on the USB side, and uses the DH485 protocol on the DH485 side.

As long as your custom program uses the Destination Byte correctly in DF1, the 1747-UIC should be transparent to it.

Thank you for your reply.
Is there a similar device that would use a legacy COM port at the PC instead of a USB port?
I suspect that the USB is used so that there is power available, but the client would prefer to put the new device in the control panel (where there are several power supplies) and it will be out of reach with a USB cable.

How far away is the PC from the SLC? There is the AIC+, but you will need one at each end if over 50 ft.
And power at both ends. See link to manual below. There are specialty cards for a PC (KTX,PKTX)see PDF below.

http://literature.rockwellautomation.com/i...um004_-en-p.pdf

I've used the 1770-KF3 to do this. The box is large and klunky, but does the job.

Equustek makes a DL3500 that supposedly works for this purpose. I have never used it for DH485, but I have used their models for DH+ and they work well.

Thank you very much for your help.
I will get a 1770-KF3 box and go from there.
The literature you referred me too is very useful. However, I get a sense that DH485 is shrouded in mystery. "Based on the EAI RS485", "token passing" is all the information I get. Do you know of any publication that defines the DH485 protocol? Having several of these PC<->SLC5/03, it would be cost effective to write a driver that talks DH485 (instead of DF1) over a RS232/RS485 converter.
I appreciate your contribution. This is a very worthwhile forum.

DH485 is a proprietary and unpublished protocol based on the same command set as DF1. I had written a driver in .NET that worked with the PIC module, but it was very flaky because it could not keep up with the speed of the token passing. If you notice, when using the PIC module with RSLinx, the standard Windows serial port driver gets replaced by a Rockwell driver in order to keep up with the token passing rate.

There is an ActiveX driver floating around the internet that does a good job with it, but I cannont remember the name of it.

I would appreciate any information you may have gathered on the specifics of the DH485 protocol for the driver you wrote. I could take a stab at it in assembler. But if nothing else, it would give me a better understanding on the relationship between DF1 and DH485 and which adapter suits a given situation. Thank you.

Unfortunately I stopped pursuing that and did not create much documentation of my efforts. There may be some remnants in my code that give you an idea of what is involved. You can download my code from here:

http://sourceforge.net/projects/abdf1/

If you search the df1Comm class for the keyword "protocol", you will find how DH485 is handled versus DF1.

The interface is now working with the DF1 protocol talking to the 1770-KF3 box
I may address the DH485 protocol when I run into a clear definition of that protocol, including the structure and timing of the 'token-pass packet' mentioned in 1756-um532_-en-p.pdf.

Thank you again for your help.