Unlike the M-series or the E10+ PLCs, the H-series PLC does not add a 10ms delay before responding to a host link command (the 10ms delay was to ensure that the Auto485 adapter has enough time to turnaround the RS485 driver). This means that when using Auto485 adapter with H-series PLC, you should only use the Auto485 adapter in ?RTS? control mode and not the ?Auto? mode. You have to write your C++ program to switch OFF the RTS line when the last bit of the command string has been transmitted.
Due to historical reason, the H-series PLCs were designed at the time when there was no Auto485 adapter and most RS232-to-RS485 adapter on the markets were ?RTS-controlled? type. Hence it was assumed that the host PC can accurately control the RS485 transmitter by controlled the RTS line of the RS232 port. Since a H-series PLC does not have a serial buffer, the CPU processes the host link command immediately as the command message is being received and almost immediately start to send its response string back to the host after it has received the completed command string. So if the host did not switch the RS485 driver back to receive mode in time, there will be a brief period that the characters sent out from the slave PLC is lost. This is what happen when you use the Auto485 adapter in ?Auto? mode. Since the adapter is not controlled by RTS line when in ?Auto? mode, what happens is that the Auto485 will wait for a brief delay period (approx. 0.5-1.5ms) after the last stop bit has been transmitted. So if the slave H-series PLC starts to send response string during this delay then the first few characters will be lost. This explains why some of the received string does not start with ?@? sign.
Thus the only way is to use the adapter in RTS-controlled mode and write your program to switch off the RTS line immediately when the last stop bit has been sent. However, note that unlike DOS or other Real Time Operating Systems (RTOS), Windows is not 100% deterministic, which means that Windows will not guarantee that it will turn off the RTS line at the exact moment when the last stop bit is transmitted. Windows will try to do it as fast as possible but it is not its highest priorities. This means that once in a while you may still experience lost characters. Hence it is important that you check the response header (first five characters) to see if it matches the command header and also verify the FCS to be sure that the response string you have received is valid. Re-send the command string if an error has occurred.
Note: In your program, you would have worsened it by adding a 110ms delay before switching off the RTS line. But fortunately since your adapter was in Auto mode the RTS line was ignored and it was the Auto turnaround that was giving trouble.
