Can you try putting in a pause after initializing the local device, using "Thread.sleep(###)"? There may be a delay while the device waits to join the network, during which your requests might be timing out. Start with something like 10 seconds to see if this works, and then reduce the time as much as you can.

Yeah, still not the information i was hoping for. Do you use COV in your points? Also, what kind of event is raised: a device exception, or a message exception? Sorry for all the questions, but it would be great to track this down. Could you provide a chuck of the events so that i can check the timestamps for any clues?

Yeah, that's the latest version. Can you check the logs to see if there are any stack traces associated with that error message? It indicates a condition where the code is doing something it shouldn't, and it should be fixed.

Hi Iain,

What version of the BACnet module are you using? I recall that there were some recent changes (i.e. a couple months ago) that addressed an error message like this.

Mebius,

Do you have a single data source that is getting points from the BACnet device, or do you have multiple? If the latter, you might have multiple simultaneous requests going to the device, which it may not be able to handle, causing timeouts and the appearance of a slowdown.

I know at least that even the BACnet MS/TP is capable of polling for thousands of points without problems, subject to the speed of the connection. (I know you are using I/P, which should be much faster than MS/TP.)

The line is not in the CVS code. Perhaps it still is in the src jar file. Try using the repo source instead.

Check out maintenance events.

This is not a DGBox forum.

dglogik.zendesk.com

DGBox is a derivative product of Mango. You should ask your question on their help site.

Concurrency refers to message concurrency in the network. Set to "slave", messages can be sent out to multiple slaves at once, i.e. before replies are received. Obviously this will not work over RS-485, and frankly the implementation of concurrency was always a bit dodgy.

Try setting concurrency to "transport".

The version of Mango you are using does not send WhoIs to find devices. It expects to be configured to find them without WhoIs. (Except for the discovery tool, of course.)

See http://developerweb.net/viewtopic.php?id=5722. The Alerton hardware is behaving properly. In unix, you cannot have BACnet4J bind to a specific address because it then ignores broadcasts. Ironically, Windows handles this better.

Check out the sendBatch method.

Is there a way to exactly correlate a response with the original request? I recall that modbus TCP has a transaction id, but i'm not sure if it applies in this case.

Changes have been checked into the SF CVS repo.

You're not removing from the list connections that complete on their own, which could cause memory problems. I have included this in the changes to the code.

Sorry for the delayed response. This appears to be entirely an issue with timeout.

When compare the IO output from the first and second tests, the first is successful because the responses were completed in less than 300ms. (e.g. 1367509107637 - 1367509107448 = 189ms). The first few requests in the second test were ok. They only started to fail when the responses came back after the timeout. So, the system behaved correctly. (It's difficult to correlate the IO log with your program output because it's not obvious how many values were returned from each request.)

The fact that any request in any test was successful indicates that the encoding is likely ok. If you can determine from the IO log that this is not the case, please let me know.

If you can provide I/O logs of the traffic, the episodes can be simulated and we can check if there are changes to the software that may make the behaviour better. If you can create such logs with different timeouts, that would be ideal. See ModbusMaster.setIoLog.