note: I typed up most of this last night but (as usual) 93lt1 had already answered the basic questions before I got time to make my post ... now it looks like things are starting to get just a little bit fuzzy around the edges ... a lot of what follows just rehashes what others have already posted ... I apologize for the repetition ...
Greetings senen,
first of all ... it’s normal for the DH+ LED to flash about once every few seconds ... that’s the processor “passing the token” ... basically each time the LED flashes, your processor is transmitting something along the lines of: “I’m station number so-and-so – is anybody else out there?” ... as soon as you hook up another station (another processor or a programming computer) on the DH+ network, then the LED will light solid green ... that’s because the two (or more) stations are now rapidly passing the token back and forth and communicating with each other ...
next ... in normal (fresh out of the box) operation, the RS232 LED will usually be OFF when nothing is connected to the processor’s DB-9 port ... if your RS232 LED is flashing then your programming computer is probably running the RSLinx (communication) software package AND RSLinx is “polling the port” ... specifically, every few seconds, RSlinx says: “hey, are you still out there?” ... the LED flashes each time the processor says: “yes, I’m still here” ...
note: for the purposes of this discussion, the terms "polling" and "browsing" both mean the same thing ...
an easy test is to simply disconnect the cable between the PLC and the programming computer ... the LED will quit flashing ... that’s because the DF1 “programming” setup will NOT poll the network ... the processor only responds and transmits when something else (like RSLinx) asks it for information ... another instructive test is to click on something (anything) on the RSLinx “network” screen until the DF1 driver’s icon does NOT animate ... MAJOR idea: when the driver’s icon is animated, then driver is “polling” the network for its current status ... this will make your RS232 LED flash each time it responds to the poll and transmits its status ... when the driver’s icon is NOT animated, then the driver is NOT “polling” the network ... this will make your RS232 LED stop flashing since it will no longer be responding ...
this post contains something that might be helpful knowledge down the road:
and ... this one is so “simple” that I hate to even mention it ... but I HAVE seen it cause confusion for newcomers ... when you looked at RSWho to find your processor, were the little blue-and-yellow boxes on the driver icon “marching”? ... basic idea: if the icon boxes are NOT “marching” (animated) then the driver is not actively polling the network ... I’ve seen instances where newcomers have tried all sorts of things to get RSLinx to “see” their processor when all they really had to do was to mouse-click the driver to activate its automatic polling routine ...
continuing on ... now once you go online (communicate) with the processor using RSLogix500 programming software, the RS232 LED will flash much more rapidly ... that’s because RSLogix500 wants to know a lot more than just “is the processor still out there?” ... it also wants to monitor the status of various bits and data values in order to keep your display screen current ... more information is flowing ... and so more flashes take place when the processor transmits the requested information ...
now if you hadn’t specifically told us that your DF1 configuration was working, then we might think that your DB-9 port COULD BE set up for DH-485 communication ... basically, that type of setup will make the RS232 LED flash every few seconds even without anything connected to the port ... that’s because the DH-485 setup WILL make the processor “pass the token” itself ... but since you’re NOT using DH-485, we don’t need to go there ... but if you want to dig deeper, then
this post might help ... the last paragraph is the most important for our current discussion ... here it is for convenience ...
and one more thing ... this might help decide which driver (the “RS232/DF1” or the “1747-PIC”) you need to use ... with NO cable connected to the DB-9 port, watch the LED marked “RS232” on the front of the processor ... if it flashes about once every four seconds, then the DB-9 port is (probably) set for “DH-485” and you’ll (probably) need the “1747-PIC” driver in RSLinx ... but if there is NO flashing, then the DB-9 port is (probably) set for “DF1 Full Duplex” and you’ll (probably) need the “RS232/DF1” driver in RSLinx ...
this is what my distinguished colleague PhillipW was talking about ... however, I don’t think that a DH-485 setup is an issue here ... because you specifically told us:
BY THE WAY WE USED AUTOCONFIG TO ESTABLISH COMMUNICATION.CHANNEL 0...DF1
since you specifically mentioned DF1 - and since DH-485 doesn’t have an “auto-configuration” feature, then I’m going to assume (gosh I hate that word) that you’re NOT using DH-485 ...
incidentally, the “probably” disclaimers in the paragraph above are there because: we COULD have configured the DB-9 port for “User” mode ... in that case, we COULD be using ASCII-type instructions to periodically transmit out through the port ... this COULD make the LED flash even though we would not be in the DH-485 mode ...
if things on your screen are REALLY slow to update, then check the baud rate setting for Channel 0 (under the “Channel Configuration” feature) ... this is what my distinguished colleague ckchew666 was suggesting ... 19.2K is the fastest setting for most SLC processors ... note that (as ckchew666 said) if you change this setting, you will have to reconfigure the DF1 driver in RSLinx to match the new baud rate ... if it’s still REALLY slow even at 19.2K, then the next logical question becomes: “is your programming computer doing some other resource-consuming tasks?” ...
finally ... if you want to experiment with the “DF1 to DH+ pass-through” method that PhilipW mentioned, then
this post might help ... it would be a good idea to try this out a couple of times in a lab environment before trying to use it in the field ... the main thing is to be sure that you can reliably switch back-and-forth between the “normal” and the “pass-through” modes ... my suggestion is that you’ll probably have less trouble (until you get more familiar with such things) by physically carrying the laptop over to the processor that you want to work with and just hooking the DF1 cable right to the front of the thing ... it’s hard to beat simplicity ... but if you can do it safely, then by all means, play around with the pass-through feature ... beside the software "help" feature that PhilipW recommended, here is another hint to help get you started ...
[attachment]
hope all of this helps ... basically it all boils down to the following:
if you’re already communicating reliably, then rejoice and be thankful ... don’t worry too much about the LEDs and just get on with your life ... you’ve got much bigger fish to fry ...
