Hi everyone, im experiencing a problem that constantly occurs and cant solve it:

I have RSLinx communicating with a MicroLogix 1500 (DF1/Full Duplex) but not using the RS232 port since PCs nowadays dont have any, so to be able to do it and be scalable without being ridiculously costly, I use a Serial to Ethernet converter device (and virtual COM port software). The main reason why I dont use a NET-ENI is because of the cost (it is not wise solution when I have several of those PLCS to communicate to).

Everthing seems to work fine until the PC reboot and no communication is available at system startup (PLC down). It creates a PORT CONFLICT error in RSLinx (configure driver section) and only way to fix this is to delete the driver and recreate it. I tested various S2E devices (Lantronix,Moxa,B&B...all saying that they support comm failure,etc), same thing everytime. I called Rockwell/mentioned brands tech support couple of times without luck. I very doubt the port conflict is the REAL reason since i tried several 'safe' ports (like COM8). I use Windows XP/RSLinx CPR9 but same thing happen on Windows2000/RSLinx CPR7... No firewall enabled. I also never had any problem when I used the RS232 wired method (and a PC having the physical port.

Please any advice/recommendation

regards

1st go to RSLinx and set all your config drivers to manual, this is shown under the config display and the button is the startup button. Set to manual


2nd issue - is the enet to rs232 a good device to use for DF1?

I use a Belkin USB to RS232 device, never used a ethernet to serial device. I found this one in the PDA interface section from any electronics store.

My experience with these devices is that if the converter is integrated into the device manager then you should have no problems using your device. When your device is operating look at the device manager under your hardware devices. If the ethernet device is good behaved device it will show it as a com port. Otherwise your still going to have problems with it when it is in use.

If your device is installed outside your computer's device manager and is not shown as a com port then you will have all sorts of problems getting RSLinx to use it as a comm port.

I agree with controlsdude USB to serial adapter is the way to go. See link below. Their cheap $34 USD

http://www.plctrainer.net/

Big thanks for the help.

Can you please elaborate more the reason of this?

With RSLinx starting as a service, all automatic drivers are stated at the time the service starts. If the hardware has not registered with Windows yet {your ethernet to serial device is a prime example} then the driver faults.

With the driver set to manual, RSlinx starts but does not activate the driver until RSlogix, Panelbuilder or some other client asks Linx for a connectionn thru that driver. In most cases by this time your pseudo port is up and ruinning ok.

What do I do when i have let's say 10 PLCs spreaded everywhere in the plant (some are very far from the PC)?

USB to serial isnt an valid option right? Or am I missing something?


btw thanks everyone for this preciosu help


best regards

I just read the RSLinx help documentation about the manual mode and it says "You must use the Start/Stop buttons on the Configure Drivers dialog box to control the running state of the driver". This is not an option if you need to do that everytime.

Are you sure you guys arent talking about "On Demand Mode"? "The driver starts when an application attempts to use it and stops when no longer in use."

???

I stand corrected. You should set the drivers within RSLinx to On Demand Mode. This plus Rslinx Service in AUto should resolve most if not all of your issues with the com port driver not being started when linx neeeds it.

thx BobLfoot, can you help me on this?

If you have many plcs with serial ports spread out through your plant and want to connect to them from central location(s), I would suggest using the DigiONE-IAP or A/B 1761-NET-ENI at each PLC. Those are serial to ethernet converters that will allow you to use ethernet for the long runs and gain access to the PLCs. Keep the ethernet separate from your business LAN for best results...

Can't get on ab.com for some reason, so the link above is to a google result...

Nevermind...it works now:

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

Paul