There are only a hand full of times that I have had to go down to the line health and packet analysis. I think that troubleshooting MSTP is typically over-complicated. There are things that you can do to make sure that the only times that this is necessary is minimal. If it is a new comm line then you should be taking note of all the resistance values between each wire, the shield, and from each wire and shield to ground. Additionally it should be noted how much resistance there is when EOLs are shorted and a EOL resistor should be added as necessary. Only add third party devices to your trunk after you know that it is in good working order, and remember that all shield wires are tied through and grounded in one spot (usually the global controller).
Troubleshooting an already broken comm trunk can be tedious if you aren't doing the leg work first. Usually the most available and quickest method is to get an MSTP router, go out in the field at the half-way point, break the trunk and scan both directions. Continue this action in the direction of the issue until it is found. It is also a good idea to keep screen shots of the scans so that you can see if you have a duplicate device instance or something of that nature. A lot of the issues that I have seen come from VFDs (not using 1.5 conductor can be a killer). Once you have narrowed down the device having the issue, or the bad run of cable, deeper analysis is sometimes necessary.
There is comm wire that is called one and a half conductor. It is a twisted pair, which are white and black, with an additional yellow wire that is not twisted in with these (and of course a shield). We use this to tie the common of the drives to the our same ground reference. You can see a schematic of this in the BACnet Protocol ACH-550 AC Drives manual (manual is freely available on the internet).
Haven't watched it yet but have you seen anywhere what type of certificates are used for SC? The white paper posted doesn't mention that at all. I know in talks I've seen unique keys for each SC endpoint etc.
Far as I gather its standard PKI certs, just as you would use for TLS. Waiting on the final review docs that should be out soon.
What they did mention here is that key management is on the radar. Too get SC out sooner its not in the initial release, but central management will be in round two.
I think this post is great. Most of the network analysis I do is on the IP side though. Worked ALC for years and most networks were ARC156 which uses a completely different set of tools from MS/TP. So I used to carry around this 16 port hub for wireshark captures. Found it at goodwill of all places cause no body makes a true hub anymore. Then i found the netgear ProSafe G5105E. Its a cheap small managed gigabit switch that also has passive monitoring capabilities. Didnt see these mentioned yet and figured i would put it out there. Been in my bag of tricks for years.
Good add unonut. That is the same one I use but had totally forgot about it as I had started this thread in regards to MSTP.
kontrol out
"Good" - Jocko "Open is as open does." - Forrest Gump "Can't we all just get a Lon?" - Garry Jack "BACnet: integration or interrogation?" - The Janitor "Interoperability? You can't handle interoperability!" - Nathan R. Jessup “What’s that? Aaa… open protocols? Don’t talk about…. open protocols? Are you kidding me? Open protocols? I just hope we can hardwire an interface!” - Jim Mora Watch it here!
More than 25 years in Building Automation. Semi-retired. Employed by JCI, Trane, York, and Honeywell. Factory trained with each of those organizations. Design, installation, service, programming, and commissioning experience with those systems, as well as a couple other commercial grade control systems.
Experienced with Bacnet, Lon, Modbus, and a couple other protocols.
The information related in post #62 is the beginning of a spot on analysis.
In the field, I have never used, nor ever had the need for an oscilloscope. It's a fine tool for the bench
Probably a matter of how you put it to use and familiar you are using it.
Just normal troubleshooting using the divide and conquer method of splitting the trunk and comparing results.
I have to wait for the software to update and maybe its intermittent so you need to see solid result over a few minutes. Can you check both ends in this same manor or just working out from an MSTP router for example. Using a portable MSTP router and discovery software to check both ends and all that BS? With a handheld scope these results are instant and you can quickly check both ends of a split and see which is the problem assuming its an electrical problem. That alone can save a ton of labor vs staring at a screen for a few min each test. Failed controller, 2 wire device without ground ref...these are things you can quickly sort out with a scope. Termination, biasing and other issues are more T&E without a scope.
How long did it take you to find an ungrounded spudder in a wad of fan powered boxes that each controller used the internal 24v? Handheld scope I can find a point, split the trunk and in seconds know what direction I need to move to without needing to look at a pc or wait for software.
Its a matter of knowing when to put it to use. We have techs that have spent full day chasing their tails. I come in with a scope get clear direction and in most cases find the problem in a fraction of the time they already pissed away. That said its 50-50 electrical issue or protocol in these cases. These cases I almost always start running a capture and dissecting with WS to first to get an idea on whats the next step. If that points to total meltdown, the scope is normally the next tool. At that point, its a very efficient tool for clear direction.
So far I love my micsig tbook scope for field work. Its small, battery powered, reasonably priced and featured. Just left in the car for when the call comes in and has saved me tons of screwing around. Well in excess of my labor rate vs purchase price. Above ceiling, sitting in a control panel, hanging upside down from building structure, super portable and well suited.
What's the test gear cost to properly certify every bit of catX cable cost? That's the next step coming. Seen many crap terminations that will link up no problem but puke under load. Chase your tail endlessly when things break under load or use the right tools...same thing.
Oh using fiber at all, what that gear cost? Or piss around endlessly with a sub that claims the fiber is good its your problem?
IMO if your using some medium, your best off having the proper tools to quickly identify issues. One off cases, sure. Daily drivers, your prob pissing time away vs the right tools IMO.
Probably a matter of how you put it to use and familiar you are using it.
Just normal troubleshooting using the divide and conquer method of splitting the trunk and comparing results.
I have to wait for the software to update and maybe its intermittent so you need to see solid result over a few minutes. Can you check both ends in this same manor or just working out from an MSTP router for example. Using a portable MSTP router and discovery software to check both ends and all that BS? With a handheld scope these results are instant and you can quickly check both ends of a split and see which is the problem assuming its an electrical problem. That alone can save a ton of labor vs staring at a screen for a few min each test. Failed controller, 2 wire device without ground ref...these are things you can quickly sort out with a scope. Termination, biasing and other issues are more T&E without a scope.
How long did it take you to find an ungrounded spudder in a wad of fan powered boxes that each controller used the internal 24v? Handheld scope I can find a point, split the trunk and in seconds know what direction I need to move to without needing to look at a pc or wait for software.
Its a matter of knowing when to put it to use. We have techs that have spent full day chasing their tails. I come in with a scope get clear direction and in most cases find the problem in a fraction of the time they already pissed away. That said its 50-50 electrical issue or protocol in these cases. These cases I almost always start running a capture and dissecting with WS to first to get an idea on whats the next step. If that points to total meltdown, the scope is normally the next tool. At that point, its a very efficient tool for clear direction.
So far I love my micsig tbook scope for field work. Its small, battery powered, reasonably priced and featured. Just left in the car for when the call comes in and has saved me tons of screwing around. Well in excess of my labor rate vs purchase price. Above ceiling, sitting in a control panel, hanging upside down from building structure, super portable and well suited.
There have always been two diametrically opposed ends to the non productive control man spectrum, the dissectors, and the piddlers. We are not scientists paid to invent, or dissect. Our purpose is to bring a fully functional system to life in as efficient and timely manner as possible. We are not out there to half ass the job either, and then rely on others to come back on warranty to do what you should have done on the first pass.
The other less than stellar place holders are those youngsters who refused to climb the ladder and learn. They insist that they can do everything from the front end. If allowed to carry on, these non producers, are a total PIA for the company, as well as their fellow Techs. You are constantly cleaning their mess and defending yourself, or your company.
There is often a fine line between quality and productivity that must be understood. A good control man always tries to run clean and streamlined. Any extra unnecessary baggage carried around on the jobsite is a waste. You can generally tell the quality of the Control Man by his tools, and how he carries them, and himself, on the jobsite. There are some minor differences between a good service man's tools, and a good construction tool set. My tool set has little compassion for piddlers or dissectors.
As my knowledge and experience grew, I eventually whittled down my load down to two shoulder bags. My laptop in one bag, the other, a tool bag. Anything else that wasn't a daily necessity stayed in the truck. A toner is a perfect example. I've watched Techs waste hours running back and forth, or borrowing, looking for something they should have already had with them. Today, I'm a huge fan of cell phones, ipads, and multi-purpose tools.
Back in the day, just as DDC was taking over Pneumatics, I was working T&B. We watched two guys pull up in a van, and start unloading large suitcases into a tiny little mechanical room. The entire jobsite erupted into laughter when we saw what they were doing. These were the Control Men, and those suitcases contained a full sized desktop computer. They spent two days in that mechanical room trying to program the system. Hilarious, especially when there were boat anchor laptops available everywhere, even way back then.
I understand the point you're trying to make, and why you're promoting the use of your scope. Regardless, if you can carry it on your hip, or in your bag, or pouch, from experience, I simply don't agree that it has much of a place on today's jobsite. There is no need for that level of dissection, when normally, a couple trips up a ladder, and a poll or two, will diagnose the issue pretty quick. You need the ladder to get up there to fix it anyhow.
The other thing is that after you've been hip deep in this stuff for a while, you tend to have a pretty good idea what the issue probably is before you get there. The tough ones are the intermittent ones though. Once, in a far far away time, some dumbass sheet rocker pinned my com wire on an elevator shaft wall, and nicked the wire with a drywall screw. Every time the building took a breath, half the trunk went stupid. Put your scope on that one.
Once, in a far far away time, some dumbass sheet rocker pinned my com wire on an elevator shaft wall, and nicked the wire with a drywall screw. Every time the building took a breath, half the trunk went stupid. Put your scope on that one.
SUCK! I personally tried the router process, and did that when I was new. I tend to use a multimeter and it gets most of my issues fixed much quicker. But for me, it seems to be more of a function of how comfortable with the process I am than the superiority of on process over another. If I am good with a scope, then that is the best option for me, if I am better with a router, then I should do that.
I try for base competence with all of them... try. And although I do a multimeter first, I have some bacnet routers I pull out on odd ball issues. I have been Oscoping everything recently, to increase my comfort level with these. For example, noise issues are conclusively proven to non technical people only with a picture from a scope... but having to prove it with a picture is not a usual scenario. Often you just need to make it go away.
Do what works for you.
For those of you using Visual BACnet, anyone tried using the built-in wiretap functionality from the JACE?
It can forward packets from the JACE's mstp port directly to Wireshark.
It's in the BACnetUtil.jar
local:|module://docEngNotes/doc/BACnetSettingUpAWiretap.html
If it works without a lot of fiddling, sounds nice to have. Seems like you just want to setup a capture filter to dump the ICMP fails and tell WS what its digesting.
If it works without a lot of fiddling, sounds nice to have. Seems like you just want to setup a capture filter to dump the ICMP fails and tell WS what its digesting.
I haven't yet. Sounds like the ForwardedMessageSink component eliminates the ICMP rejects.
I'll play around with it this week.
If it works without a lot of fiddling, sounds nice to have. Seems like you just want to setup a capture filter to dump the ICMP fails and tell WS what its digesting.
Very little fiddling.
-Install bacnetUtil-rt in the JACE (no need to reboot),
-drop a ForwardedWiretap onto the mstp port
-drop a ForwardedMessageSink onto the mstp port if you need to filter ICMP rejects.
-type in the IP address of the machine running Wireshark, it defaults to port 49000
In Wireshark, setup a capture filter such as "udp port 49000" and decode as bvlc for a display filter.
Reply
Originally Posted by orion242
