MODBUS/Coms issue

[ccdubs]

I have a strange thing happening where randomly, the T100 PLC will stop communicating with a PC set up as the MODBUS master.

Rebooting the PLC has no effect. If I depower, switch DIP4 on, repower, switch DIP4 off, communications work again.

Does this make any sense?

[support]

The PC is a Modbus RTU master?

You may want to use the SETPROTOCOL command to fix the COMM port if is used only as Modbus slave port to Modbus only mode. It takes the guess work out of determining which protocol comes in. The PLC may have entered into a different protocol mode and if the PC continously send command to the PLC it does not have time to reset back to auto mode.

Of course if you later need to use the same COMM port for connection to TLServer you will need to have a way to set it back to automatic mode. One way is to use a start delay timer (say give a 30 second time out) before running the SETPROTOCOl command. This allows you to use TLServer to communicate with PLC to transfer an updated program, for example.

[ccdubs]

I used SETPROTOCOL 1, 1 as I use MODBUS RTU but I still have the same problem, even now with a different PLC program.

This is the sequence of events:

1) MODBUS is working fine.
2) I depower and repower the PLC and MODBUS doesn't work
3) I turn DIP 4 on and MODBUS doesn't work
4) I depower and repower with DIP 4 on and MODBUS works
5) I turn DIP 4 off and MODBUS still works (this is what I had to do before step 1)

The MODBUS routine in this instance simply writes an incrementing variable to DM[100] (pauses 2s) then reads DM[100] to DM[109]. Interestingly the returned values are a mix of random numbers (DM[100] is correct) which don't match with what I see from the Trilogi online monitoring.

[support]

You said while MODBUS is working fine, and when you remove power and then apply power to the PLC, MODBUS will fail to work? It doesn't quite make sense.

The only thing I can think of is that something in your 1st.Scan custom function has caused the Modbus port to change parameters. When you re-power the PLC with DIP switch #4 ON the 1st.Scan controlled CF will not execute and that's why you are able to communicate with the PLC.

Can you check the code in your first scan function? Can you temporarily disable all custom functions controlled by a 1st.Scan contact to see if the problem goes away?

[ccdubs]

The only thing in the 1stscan CF is the SETPROTOCOL command. Before adding this i didn't even use 1st scan.

The issue is definitely repeatable and I have tested it with another PLC too and the same problem.

I use DAQFactory to poll the PLC and have done so for many years without any difficulties.

[support]

Can you transfer a blank program to the PLC and then use the same DAQfactory software to see if the problem is still repeatable.

[ccdubs]

I have done this and it makes no difference and I have tried it on two seperate PLC's. I have also realised that exactly the same issue happens with TLServer coms to the PLC, so it is not just limited to MODBUS.

I was worried it may be my hardware but resetting the computer while the coms had failed made no difference.

Repowering the PLC's with DIP4 on seems to be the only remedy.

[support]

When you receive a new PLC you should be able to communicate with it without using DIP switch #4? This should be the case otherwise we will be hearing a lots of reports of similar issue from all customers.

Can you check if your EEPROM jumper is in Write-Protect position or "Enable" position? If in WP position it means that that when you transfer a blank program to the PLC it is not written into the EEPROM but only written into the RAM. So the old program inside the CPU is still giving problem whenever you power-reset the PLC. The old program may have changed the COM port settings.

One more possibility could be that the EEPROM chip is damaged, but since you reported that you have seen same issue on two PLCs it is less likely (although still possible) that both PLC suffered same EEPROM damage.

[ccdubs]

The jumper is in the ENABLE position and there is no sign of the original program running as the original program turns some outputs on automatically.

The EEPROM appears to work as when I change the program to perform a different output sequence, the PLC retains the program after a power cycle.

I tried this with a different PC today with the same result. Is there any chance it's somthing else, perhaps not PLC related? The only pieces of equipment I can't change at the moment for testing are the USB to Serial converter and DC power supply.

[support]

It does not appear to be a PLC related issue since the EEPROM appears to be working good and the jumper is at the correct location.

It doesn't make much sense for the DIP switch #4 to be the only way to communicate with the PLC. DIP switch #4 simply pauses the PLC and the effect is quite similar to having a blank program inside the PLC. If you have transferred a blank program to the PLC and still faces the same problem then you may really want to check the power supply and USB-RS485 as a possible source of trouble, although this is the first time we hear of such an issue.

[ccdubs]

OK it is not the power supply. I have run the PLC from a 12V battery and the result is the same.

[ccdubs]

I found a laptop with a serial port. Loaded all the Trilogi software on and have the same problem. This would then seem to point to the PLC.

In my second post I noted that the values being read from MODBUS and those shown by the Online Monitor were different. Is this a clue at all?

[support]

It doesn't make much sense and the only way is for us to bring in the board to test what you said.

Please contact support@tri-plc.com and provide your serial number, approximate date of purchase and the vendor that you purchase from and we can make arrangement to get the PLC back to us for testing.

[can]

not sure if it will help but maybe you can use a desktop computer system to try? I'm wondering if laptop will have problem communicating since most of them are not grounded / earthed.

[ccdubs]

I have tried this on 3 computers. Two were laptops and one a PC, unfortunately the same issue.

I think it unlikely that this is an inherent PLC fault and am concerned that there is something in my set up or processes that is doing damage.