RS232 port close time

[ccdubs]

I have a F1616 PLC that is polled via modbus on COM1 (RS232) from a master device. The master reads and writes data.

Is there a recomended delay between a read and the subsequent write commands(and vice versa). I have the problem where I sometimes fail to write and I assume it is because there isn't a long enough delay.

[support]

Since if you are using COMM1 on the PLC it is full duplex and there is no turn-around issue that happens on RS485.  We have no report that a delay is needed between read and write.

Is your Modbus master a commercially available product? Did you test with other modbus host such as Modbus poll software or SCADA software, or just another F-series PLC (using a crossover cable) to see if the problem still occur.

[ccdubs]

Maybe I have my com port numbers mixed up, I am using the DB9 port with RS232. NOT RS485.

The master is a PC running DAQFactory. Due to the way the sequences are written, the situation can randomly occur where a write is commanded very shortly after a read. I have put in a delay of 100ms before the write command. While this has improved things I still periodically get a write error.
 

[support]

Sorry that I did not make myself clear. Yes, COMM1 is RS232 on most of our PLCs except Nano-10. So in your case your communication is via RS232 and not RS485 so there is no turnaround issue.

100ms delay is more than sufficient and you shouldn't encounter write errors. How much data do you write into the PLC each time? There is a limit to the serial buffer size on the PLC and the software may have attempted to write more data than could fit into the serial buffer, which result in corrupted command?

[ccdubs]

I am only writing to a single DM. The value is a heartbeat that increments with each transmission to allow the PLC to determine if there is a loss of coms with the PC. The timeout for this alarm is set to 60 seconds and the alarm activates every now and then. The PC updates the heartbeat every 10s so it takes 6 consecutive failures.

There is no indication that there is a fault with the PC or SCADA and eventually, the heartbeat will reset. The coms monitor on the PC shows that only the write command fails and it does this for a finite random period, then at some point write coms resumes and runs happily. It looks like during this time reading continues without error (reading polls at 3 seconds and returns 30 DMs).

The SCADA is sequential so a write command shouldn?t be actioned until the read command is finished and there has been a 100ms delay.

[support]

Did your comm monitor report what kind of comm failure? Is it wrong CRC or no response from Modbus slave?

We will try to run some Modbus COMM test this weekend to check the issue.

[ccdubs]

Timeout error every time (this is set at 500ms)

[support]

We carried out a series of tests using Modbus poll software running on a PC to communicate with F2424. We found that Modbus poll can send Modbus function 01, 02, 03, 05, and 06 to the F2424 for tens of thousands of messages without a single failure. But when we ran Modbus function 16 test (multiple word write) on the F2424, we found that indeed 1 in approximately 250 commands sent resulted in a no response. It doesn't matter if we select a polling period of 1ms, 10ms or 100ms. The statistics is similar.

It appears that there may be a bug or imperfection in the firmware code that handles the Modbus function 16. This will be reported to the firmware development team for a fix for future firmware release.

For your existing application, you may be able to tolerate the occasional missing comm reply by reducing the time out period. The PLC would normally reply well within less than 100ms. So you can choose a time out of 100ms and the disruption should be brief and the DAQfactory software can resend the Modbus write command.