Paulo Balbino
Member
Hi,
I am using M221 reading from 3 different sensors (modbus rs485) sharing same bus (daisy chain). I am currently using READ_VAR (in total about 9 of them) sequentially which means when one finishes DONE triggers EXECUTE of the next one. Everything seems ok the problem is one of the scenarios we need to test (as part of the pre commissioning testing plan) is negative test cases for example adding "noise": parity errors, drop of frames, insert/remove out extra characters to the frame, ignore requests, delay responses.
PLC/Ladder is properly able to handle the scenario where the requests are ignored (sensor disconnected) and when the response is delayed. But when we test introducing parity errors (CRC) or any other simulation that actually corrupts the frame, after some time (5 min to 10 min) the READ_VAR blocks get stuck and the only way to properly get the communication back is to restart the PLC.
After getting "stuck" every new read attempt on any READ_VAR (EXECUTE to 1) fails (ERROR to 1) with the following error codes:
CommError: 255
OperError: 6
How do we perform this tests?
PLC connected to a computer (using a Rs485 to usb converter), and computer running a modbus simulator.
Then configure the fault simulation (ModRSsim2)
Did you guys know about any known issue on READ_VAR communication block? I would expect it to fail during the test, but after fault simulation is stopped I would expect it to be able to read properly. READ_VARs are getting stuck.
See attachments for more info.
Thanks,
Paulo
I am using M221 reading from 3 different sensors (modbus rs485) sharing same bus (daisy chain). I am currently using READ_VAR (in total about 9 of them) sequentially which means when one finishes DONE triggers EXECUTE of the next one. Everything seems ok the problem is one of the scenarios we need to test (as part of the pre commissioning testing plan) is negative test cases for example adding "noise": parity errors, drop of frames, insert/remove out extra characters to the frame, ignore requests, delay responses.
PLC/Ladder is properly able to handle the scenario where the requests are ignored (sensor disconnected) and when the response is delayed. But when we test introducing parity errors (CRC) or any other simulation that actually corrupts the frame, after some time (5 min to 10 min) the READ_VAR blocks get stuck and the only way to properly get the communication back is to restart the PLC.
After getting "stuck" every new read attempt on any READ_VAR (EXECUTE to 1) fails (ERROR to 1) with the following error codes:
CommError: 255
OperError: 6
How do we perform this tests?
PLC connected to a computer (using a Rs485 to usb converter), and computer running a modbus simulator.
Then configure the fault simulation (ModRSsim2)
Did you guys know about any known issue on READ_VAR communication block? I would expect it to fail during the test, but after fault simulation is stopped I would expect it to be able to read properly. READ_VARs are getting stuck.
See attachments for more info.
Thanks,
Paulo
