drop a ForwardedMessageSink onto the mstp port if you need to filter ICMP rejects.
Had to look at this again since it didn't add up.
Jace in the field with MSTP, you setup this to capture. Its spewing this traffic to another machine running WS. The machine running WS is generating the rejects if anything.
So your not putting this sink on the jace, your firing up a niagara station on the machine running WS and adding this just to catch the crap the OS wouldn't otherwise expect? You need two stations for this right? Why the heck wouldn't it be default otherwise.
If that is the case, cap filter in WS would be less hassle than firing up a local station. Cap filter syntax is totally diff than working within WS, but anything that doesn't meet it is also never captured. Aka reduces the load if nothing else. 1k faster than just launching N4.
This note is a bit confusing:
NOTE: You do not need to run a station on your computer. You can add the ForwardedMessageSink
component to any location in the station
Something else I found recently... in the bacnetUtil there's a Tokens object (under Metrics) that you can drop on any mstp port of a JACE.
Seems like a pretty useless metric as far as tokens per second goes, other than if you have something greater than 0 you at least know the token is being passed around.
However, if you then go to the slot sheet, you can unhide a bunch of other metrics:
Known about that as well, haven't used yet. Used to string a ton of ms/tp to the jace, now its mainly IP routers even though thats just another headache.
Tokens per sec is a good metric depending on how they implemented it. Aka does it call out how long each mac held it, or is it just round trip to the jace? As its just one number, have to assume it the later. Nice, but not that great.
Looking at the pdf, initial sniff looks like a lot of fluff with a few gems.
MIF, MaxMasters, Mac Adr, just what its set for on the Jace I assume? Kinda useless if so.
queuedmsgs, useful
valid/invalid frames, keeper
CRCs, good though how does differ from the above?
To be honest, seems barely on par of what's available on the low end router.
There's a bit of documentation on the tokens/sec metric here:
module://docEngNotes/doc/BACnetTokensPerSecond.html
What I was told by tech support is that in 4.9 they added a new feature called TxThrottle (hidden slot under the MstpPortx\Link slot). It accepts a value from 0-20, and they default it to 10 in 4.9
Apparently older BACnet devices (protocol revision 4 or earlier) have a problem with this setting at 10.
I successfully upgraded about 48 JACEs from 4.2 to 4.9, and only one site had mstp problems post the upgrade - at this point it's a mere coincidence and we're still troubleshooting. Some of the pics I got back from the site show metal shavings on top of the JACE... but you know, it was working before I touched it, they say.
One, I started using JCI's bacnet analyzer tool and it has been a decent tool. I have yet to see it's full potential as a troubleshooting device, but has confirmed general health of a comm buss and verify devices where I didn't have a supervisor on sales calls before.
Two, if you're having problems with RS485 communications on a Jace, get yourself a separate bacnet router. I've found that a contemporary controls router, BASRT-B, was able to communicate with a few comm loops that an FX80 wasn't able to on a trunk full of devices we our company doesn't support. No matter what I did to my timeout settings, poll scheduler, ect, I couldn't get comms to work on the FX80 but I saw them right away with the BASRT. I had it explained to me later that Niagara uses different drivers than other supervisory controller developers. I don't know enough to say now accurate this is, all I can tell you is when I tested comms on my own field controller products, the FX80 didn't have a problem, but was unable to talk to the trunk of existing controllers directly via RS485, and had to instead use BASRT routers with routing...quite a shame really, there was no way we would convince this customer to reinstall new comm buss to replace a bad installation.
Yeah, the mstp driver on a JACE is a low level driver that runs under QNX before the Niagara station is even up.
Timing requirements must be a real challenge for a host tasked with many other things. Add multiple ports and a the challenge is multiplied.
I have no idea whose stack they're using if not their own.
A device dedicated to handling token passing like CC's router is much better at handling that task, because that's all it has to do.
A device dedicated to handling token passing like CC's router is much better at handling that task, because that's all it has to do.
This is a much better explanation than the one I was given, which was "yeah the Jaces drivers aren't the same as the drivers on the BASRT". I guess to me, the whole advantage of an FX80 is it's ability to handle serial communications, otherwise I'd be pushing our company to do strictly niagara servers with MS/TP routers. Only thing I don't like about that idea is how much I distrust windows, and I further distrust the IT people within our client's organization to not FUBAR the thing.
I've found that a contemporary controls router, BASRT-B, was able to communicate with a few comm loops that an FX80 wasn't able to on a trunk full of devices we our company doesn't support. No matter what I did to my timeout settings, poll scheduler, ect, I couldn't get comms to work on the FX80 but I saw them right away with the BASRT.
I most often see this when there is an electrical issue. For example, a guy was trying to get a bunch of ungrounded controllers with a 2 wire trunk to talk to a grounded AS-P, after letting the trunk of ungrounded devices run for a few days.
No comms whatsoever. Ding dong patches in with an RS485 adapter and YABE, it all looks good. For 2 days he tells Schneider their stuff sucks, they say they would be happy to fly someone out to fix it for him, and charge him for the trouble. Ding Ding doesn't like that, as he used speaker wire for a comm trunk, and does not want Schneider to know.
I am expressly forbidden from being on the site, so I go after everyone was gone. Took 15 min to find the ungrounded controllers were running Bacnet on a 24v sine wave. The grounded AS-P couldn't read that. But the YABE software talking through an ungrounded laptop on a battery could. It could follow the trunk wherever it went electrically.
So it may be electrical. Routers can be run on a 2 wire whip ungrounded. And see things a grounded JACE cannot.
Again YABE is fantastic but I ran into a problem with a specific Trane unit;
When I try to export a device DB XML for this device the application locks up. No file written for export.
-Server 2016 version 1607.
-Device identifies as: Horizon UC600 v8.2.9 [10106]
-Function get properties name works correctly and fetches the names of all points, attached screenshot.
-Function Export Device ID locks up YABE and nothing further is possible, application must be killed via task manager.
-I have no issue with Export Device ID on other controllers by Automated Logic on this same computer.
Something unique to this Trane unit is creating problems within YABE. I've sent and email to create a sourceforge help discussion but I've never done that before and not sure how that works.
Oh, by the way; ALC can't discover points in this unit at all. What the hell is trane doing here?
On an AS-P, You really have to ground the controller itself if you want to have a good MSTP bus. There is a point for this. Many never connect it. If this isnt grounded your shield (Which is connected to the RET terminal of the bus connector has no where to drain and any signal on the drain wire is fed into the ground plane of the controller itself.
Depending on the install, you may see no problems at all or nothing works at all.
Sounds like a good tool to have. I did a GOOGLE Search but came up empty. We installed a CC BASRT Router and are having some devices going on/off line. We have two comm busses connected in parallel but that hasn't been an issue before. The first and last device on each buss is an ABB ACH580 with 20 JCI PCV's and two PCA's in between them with the EOL turned on at the last Drive.
We are going to try switching the EOL off at the drive and only connecting one buss at a time and the also possibly adding a 120 Ohm resister and see what that gets us.
If you can't fix it with JB Weld, Duct Tape, and Ty Wire it has to be replaced.
No good deed goes unpunished.
If you want to take off friday to go fishing then make sure you train your helper right.
We are using this wire for MS/TP comm runs and it came up in a discussion that the 300v rating might not be appropriate in some VFD communication as the voltages in those would generally be in the 480v range nearby in that enclosure. Does anyone have thoughts or recommendations on that issue?
I know much further up in this thread someone mentioned 1.5 pair wire (+shield) was important for VFD. Has anyone compared that to the regular pair + shield wire and seen an improvement?
Never had a problem using shielded wire. Bo your best to keep it away from the line/load voltages.
If you can't fix it with JB Weld, Duct Tape, and Ty Wire it has to be replaced.
No good deed goes unpunished.
If you want to take off friday to go fishing then make sure you train your helper right.
Has anyone found that a time domain reflectometer useful for troubleshooting cable faults in RS485 type wiring?
Back in my RF days these were pretty handy in pointing out cable breaks, bad terminations, bad junctions, cable pinches, etc. Only downside is I'm pretty sure you can't have anything else transmitting on the line when you use it.
Has anyone found that a time domain reflectometer useful for troubleshooting cable faults in RS485 type wiring?
Back in my RF days these were pretty handy in pointing out cable breaks, bad terminations, bad junctions, cable pinches, etc. Only downside is I'm pretty sure you can't have anything else transmitting on the line when you use it.
Gonna bet @s2sam is the only one who uses this all the time, and will be the best one to comment on it. I know they are a little pricey, but I have wondered the same thing honestly.