Can COM3 comm issues disrupt COM1?

[Joel Moore]

I'm having communication problems with a T100MD888+ PLC.  The TLServer keeps disconnecting with an error stating:

Bad Network Performance

Please check the following:

1. None of the slave nodes are sending data on RS485
2. Long network is properly terminated and biased

We have an ICP module connected to the RS485 port on this PLC and this is the first time we've done this.  We don't have biasing resistors on the port (simply because we can't add another power supply to our system) but regardless of the potential problems caused by that we are communicating with the PLC using the RS232 port.  Could communication errors on the RS485 port cause failures on the RS232 port?

[support]

If you pause the PLC program (say turn on DIP switch 4 but do not reset the PLC), does the TLServer behave normally? i.e. On line monitoring goes smoothly as usual? If so, then there is something in your PLC program that is causing the problem.  Most common problem of this kind is that the PLC program writes to COMM 1 using PRINT #, NETCMD$, OUTCOMM, or WRITEMODBUS.  

Second possibility is that If you have a lot of failed NETCMD$ on COMM3, especially if you run them in non-differentiated CF or have a loop that keep sending NETCMD$ command but failed, it could have taken up too much CPU time to respond to hostlink command from TLSErver at COMM1. That may make TLServer think that the PLC is not responding.

The Third possibility is if your program does a lot of SAVE_EEP command continuously, then it could result in disruption to communication. This is because when the PLC execute SAVE_EEP it shuts down interrupts in the system to prevent corrupting the EEPROM write, and some host link command characters could be lost. Continuous writing to the EEPROM should be prevented since it will shorten the life span of the EEPROM, which has 100,000 erase/write cycle life.

[Joel Moore]

It happened even with DIP switch #4 turned to ON.

I don't know if this is a helpful clue but the only way to get a response from the PLC after this happens is to close and re-open the connection from the "Serial Communications Setup & Test" dialog.  Sending "IR*" gets no response until I do this.  Maybe this is to be expected though

Our application, which doesn't communicate through TLServer, doesn't seem to be seeing these same errors.  Maybe it's just TLServer that's having a problem.

Could this be related to Java perhaps?  My Java version is 1.5.0_06

Edit 1:

Hmm.  I'm starting to suspect either my Java installation or else my PC itself.  I have a brand new laptop and this is the first significant Trilogi development I've done on it.  I'm using USB serial adapters but I used these on my old machine as well.  My old machine was USB 1.1 and the new one is 2.0 but I wouldn't expect that to matter.

I do have Java 1.4 installed on my machine as well.  Is there a way to force a Java app to use an older set of runtimes?

Edit 2:

Ok, I figured out how to force TLServer to use Java 1.4 and that didn't change anything.

I also tried monitoring a different PLC running a different program (one that doesn't use the RS485 port) and the same problem arose.

So it seems like it must be my PC or its USB ports or something.  Sorry for the false alarm.

[support]

Check the following link for discussion of USB to RS232 serial adapter. One customer has a Belkin converter that works on his other PCs, but just wouldn't work on his new DELL PC. He changed his converter to another one that is recommended at the forum and the problem went away.

http://www.tri-plc.com/yabbse/index.php?board=2;action=display;threadid=409

[Joel Moore]

Just to follow up on this, I've started using Belkin's USB serial adapters and so far I haven't seen any problems.  Knock on wood.