Modbus Hangs

[chanchungfat]

Hi,

It's our first project using DAQFactory. And finally we come to the part of Modbus.

There are 48 serial RTU slave flooding detection device based on pic16f876a.

Each device has 4 points to be read. 1 = flood 0 = no flood.

We create 48x4 channels to read the devices.

An ethernet-RS-485 converter is employed.

DAQ is running on Windows Vista.

The problem is every time the system runs for a few minutes good. It then hangs up.

And we notice that every hanging up is associated with a double receiving message, like this:

TX(17:39:53.398): \x30\x03\x00\x05\x00\x02\xD0\x2B

RX(17.39:54.791): \x30\x03\x04\x00\x00\x00\x00\xDA\xF0

RX(17:39:54.791): \x06\x80\xC1

The system hangs up at that point.

However, we press a command button which is executing the command device.ModB.ConfigureComm(), the system resumes.

The command/alert window do not show error messages except normal timeout.

We have added a sequence constantly clear locked port but it does not work.

We understand the problem may be originated from bus noise or the converter driver.

Is there a means to reset the system automatically after encountering the above situation?

Thanks

[AzeoTech]

Well, first I'd solve the noise problem, because who knows what else it might cause. If the difference between flood and no flood is just 1 or 0, then you are talking about 1 bit out of place. The RTU CRC should catch it, but its not 100% and looks like you have a lot of noise.

You can automatically reinit the port using device.ModB.initcomm(). You should not use unlockport() when just using modbus since this is done automatically by the driver.

Do all your channels have the same Timing and Offset? They should if all your channels are on the same 485 bus.

If you are getting a mixed frame response, it might be that your timeout is too short. DAQFactory times out and sends another request, but then in the middle of the frame the first device finally responds. LockPort() only protects from multiple threads in DAQFactory, it does not protect against crosstalk caused by a slow device responding after DAQFactory has moved on. This is likely your problem actually.