Bacnet MSTP Polling in Jace

[AXR2]

I am getting a "Transaction Timeout: invoke ID XXX" on several polled points in a Bacnet MSTP application in a 404 using 3.4. About 24 devices on the comm port and 65 total between 3 ports in use. Default tuning policy. Defaults on everything. Normal polling rate. Should I adjust my polling rate?

This has very few polled points. Maybe 200 total. Most are COV.

[BACnet]

I'd suggest sniffing the MS/TP port during the these timeouts. We can all guess as to what the problem is but when you actually look at the data the problem generally reveals itself right away.

Also, is this Jace directly on the MS/TP port, or are there any routers in between?

[AXR2]

No routers. What do you mean by sniffing? I have the app director output showing the errors.

[BACnet]

I mean actually look at the raw data on the MS/TP line via a comm-port-based protocol analyzer. That way you can watch all of the traffic in real time including tokens, data requests, data answers, broadcasts, etc. That way you can see if the unit really is timing out or if the jace is requesting it of a non-existent unit, or if it's answering too late and causing a collision, etc.

Someone else here might have a more concise definition of "Sniffing" but it basically means that you monitor the data without modifying or directing it.

[Lapham636]

AXR2- What did you find out about the polling Rate? I am having the same issues currently, Trunk is extremely slow and devices Status are constantly going down.
Any help would be appreciated.

[MatrixTransform]

Any help would be appreciated.

poor choice of wire.
EOL.
conflicting MACs.

...no point sniffing for comms you cant get !

[Lapham636]

Wire, MAC, and EOL all Checked out. I am Using Alerton Controllers and when i hook up the Field Service Tool (Alerton FST-100) I can read all controllers no problem. As soon as i put the trunk back on the Jace-6 communication goes flat. There are no BCM's.

[amigo]

may be a baud rate issue, related to auto baud mechanism of vlcs.
similar issues were reported. solution seems to be power down vlcs and put jace on the bus and power up each vlc one at a time. may be give that a try.

[Lapham636]

That Does/Did Work...however i am not on site! Was wishing for a "oh yah just set the X-parameter to xxx, and ALL your problems are solved"

I do have VLC's that are coming in and out of communication, Previously when i cycled the VLC's once they were "on" they stayed that way.

[Igotworms]

Try adjusting your APDU timeout also. Ive noticed that helps when I have controllers going on and off line.

[Lapham636]

Amigo, I noticed that the VLC's that is giving me the biggest headache are the 444's, the 853, 1188, 550, vavih-sd and 1688 don't have to cycle power to them to get going. Any thoughts on this?
Thanks.

[amigo]

I have not used 444s, so can't really say.
As I said, your problem may be related to auto baud.
Don't think there is a quick fix for this.
what baud rate is your jace driver set to?
I would try making your poll rate policy quicker for the 444s just as a test and see what happens.

[Right Control]

What is your busy time on the trunk having the problem?? How many normal polls?? On a big site I try get the busy time below 80%. I make different tuning policy's for the schedule, and fast polls, and apply them to the points needed. You can tune your network by slowly increasing the rates of all the three choices,normal,fast,slow. Example Fast 1 to 3 normal 5 to 7 slow 10 to 12. Then reset your poll statistics and watch. Repeat the steps to decrease your busy time. I have had good luck with that process.

[Lapham636]

Amigo, Poll Rate is at Fast 2 normal 6 slow 12, baud rate is 76.8.

Norriski, I will try this... the busy time is currently Net #1 390 and Net #2 280 ( two 485 cards). avg. poll on the Net #1is 2997.6ms and on Net #2 is 69.62ms and all Controllers are currently on the Normal poll freq.

[NateClark]

I'm having a similar issue here, but wanted to run something by y'alls. We have a Trane "RTU" that was moved from the roof to the ground out back of a building, controlled by a Vykon JACE communicating on MSTP BACNet with a bunch of Alerton VLCs to our Niagara JACE. Whew! The Vykon JACE, while still running its RTU fine, stopped communicating about a month ago, and is being replaced as its comm has died. It is currently unhooked.

Is it possible that my "Transaction:timeout: invoke ID ###" errors are being caused by this 'hole' in the network?

I'm going to try it as I just thought of it, but would disabling this device on the network possibly eliminate the problem? The timeouts are only hitting 4 VLCs, and only their Schedule Status points, resulting in them always being unocc (made the unocc setpoints equal to occ values to bypass THAT issue for now). I'll let you know if it works...

[NateClark]

Well it didn't. And the Transaction timeouts are spreading, though no other schedules are affected as yet. And I've found that I have two controllers on the BACNet netork 60000 with identical object names that had identical MAC addresses (99). I have set both to Enabled: False for now. Any comments or suggestions?

[MaxBurn]

How is the comm disconnected? If it was end of line you may now be missing an EOL termination disrupting the entire network. Fix those duplicate MAC addresses, that will cause all sorts of issues if it really exists.

[NateClark]

Yeah, I also changed them to 98 and 99 for now. Down to only one unit not scheduling, but they're all still getting Transaction timeouts. Given where that unit is, it may well be the EOL too. Thanks, I'd forgotten about that entirely.