Sometimes I get lazy and don’t follow my own rules. (Rule #1: Test EVERYTHING!) That one oversight cost me three hours when I could have solved a problem in three minutes. Maybe you can learn from my mistake.
The goof happened at a customer site last week. He had a Siemens MultiRanger 100 ultrasonic level transceiver, and was trying to connect to it via Modbus using Siemens SIMATIC PDM software on his Windows XP laptop PC.
Early on, the Lesman salesman who worked with this customer had connected to the MultiRanger from his laptop using PDM, but only one upload worked successfully. The rest failed. The salesman had lent the customer his “known good” serial cable that he’d used for the successful upload.
Siemens tech support had offered the customer several “Try This/Try That” suggestions, but came to the conclusion that a software program on the customers’ laptop had locked up the laptop’s internal serial port so PDM couldn’t access it. The customer’s IT guy ran a port scan program, but could find on application or service running on COM1. Plus, they’d used the serial port successfully for other connections.
I couldn’t do anything more for the customer over the phone, so I grabbed my serial comms toolkit and headed to the site myself.
Although I usually check in the BIOS to make sure the serial port is actually enabled, the customer assured me that they’d used the serial port just the day before with other software. So I skipped the BIOS check.
Ruling Out COM Port problems
I dug into my bag, found a female DB-9 loopback test adapter, and plugged it into the laptop’s DB-9 serial port. A loopback tester directly connects the transmit line (Tx) to the receive line (Rx). In a successful test, any data or characters that get sent immediately echo back on the receive line. So, if a terminal session’s window echoes back any typed keyboard characters, it would prove that the serial port is available and that the Tx and Rx lines are functioning properly.
Since it was a Windows XP machine, I went into Start>Accessories, and ran Hyperterminal. (It doesn’t exist in Windows 7, but if you need a basic terminal emulator, PuTTY is free and easy to use.)
I launched Hyperterminal, pointed it to COM1, and set flow control for no hardware handshake.
When I typed some characters on the keyboard, presto, they echoed right back at me, confirming that the serial port was active and not locked by another service or application.
Ruling out software configuration problems
The customer’s laptop already had several SIMATIC Manager ‘projects’ that included the setup for network communications over a certain PC comm port with an associated field instrument.
From the Manager’s Process Device Network View, I checked two of the projects, but changed no settings. Both were properly setup for a Modbus RTU connection on COM 1 at 115K baud, and configured as 8-N-1 (8 data bits, no parity, 1 stop bit). The network correctly included a MultiRanger 100.
Note: A field device, like the MultiRanger, won’t appear in a PDM project unless its electronic device description (EDD) file exists in PDM’s library and is called through the project settings.
The Siemens MultiRanger 100 has both an RS-232 port (index 1) and an RS-485 port (index 2), each with its own serial setup. Using a Siemens infrared handheld programmer, I checked the RS-232 port and found that it was properly configured for Modbus (as opposed to the older Dolphin protocol), 115k baud, and 8-N-1. I disabled the parameter that allowed for a phone modem. The table here is valid, except that the Index value is 1 (RS-232) in all cases, not 2 (RS-485).
I removed the loopback test adapter and reconnected the laptop to the MultiRanger 100 with the “known good” serial cable.
From an open project, I launched SIMATIC PDM, told it I was a specialist user and it came up with its standard MultiRanger 100 screen. I clicked the upload button to load the MultiRanger’s parameters into PDM. It worried a couple seconds and then gave a succession of the dreaded “No Communications” errors.
Fast-forward a couple hours
I won’t go through all the iterations I attempted over the next couple hours, but there were many.
I did manage to connect to the MultiRanger 100’s RS-485 port using my own laptop and a USB/RS-485 cable, proving that the Multi’s Modbus was functional. But neither my laptop nor the customer’s laptop would connect to the Multi’s serial port.
At one point, using Modscan 32, I tried polling a Modbus register on the Multi’s serial port and it too failed.
That’s when I retrieved my “known good” HydroRanger 200 from my car. It uses nearly identical PDM Modbus communications (its EDD file is slightly different than the MultiRanger 100’s).
I tried to connect to the Hydro 200 with my laptop, but the connect attempt failed. That was a major red flag. The connection had worked the previous day. This time however, I was using the salesman’s known good serial cable, not my own.
So, I grabbed MY “known good” serial cable. A minute later I had a valid connection from my laptop to my Hydro and minute after that, there was a valid connection from the customer’s laptop to his MultiRanger 100, each using my known good serial cable.
Conclusion: All that grief caused by a faulty “known good” serial cable.
The post mortem showed that the customer’s original serial cable’s RJ-12/DB9 adapter was manufactured incorrectly (or at least differently than others of its kind): the black and the blue wires were reversed.
The Multi/Hydro adapter needs the black wire on the DB-9 Pin 2, but the adapter’s Pin 2 was blue on that particular faulty adapter.
A little further testing showed that though the 6-pin RJ-12 cable was fine, the salesman’s serial cable was more than 5 years old and had become intermittent. I’ve messed with it: it works on rare occasions, most times it does not.
At last, the solution!
My big mistake was way back at the beginning, when I did the loopback test. The standard RS-232 serial wiring is shown below:
After the test with the loopback adapter on the laptop’s COM port, I should have pulled out a second RJ12/DB-9 adapter and connected it to the phone plug on far end of the serial cable where the RJ12 connects to the MultiRanger 100’s serial connector, like this:
If I’d done that, the cable would have failed the loopback test and pointed out the bad cable immediately. Because of my oversight, I mucked around for a couple hours until I had experimented enough to discover the bad serial cable.
Make your own loopback test adapter
A loopback test adapter can be made from a DB-9 connector.
For serial communications like Siemens’ SIMATIC PDM, hardware handshake connections to RTS and CTS are not needed. Just solder a wire from Pin 2, Tx, to Pin 3, Rx. There are five pins across the top row on DB-9. Be sure to get 2 + 3, not 3 + 4. The pin numbers are always molded into the base, but it takes sharp eyes, youth, or good bifocals (and sometimes a magnifying glass) to see them.
Male solder pin DB-9 connector (left), Female solder pin DB-9 connector (right).
Click the images to buy them online at RadioShack.com.
I also recommend having a pair of gender changers so that DB-9 connectors can be adapted for either male or female DB-9 connectors. They cost less than a buck each at Monoprice.com and can be lifesavers. Male DB-9 gender changer (left), Female DB-9 gender changer (right).
Some people will take a straight-through serial extension cable with a male DB-9 on one end and a female DB-9 on the other, and cut the cable in half. Then they’ll connect pin 2 to pin 3 on each of the halves and end up with two loopback cables, one with a male connector and the other with a female connector.
The moral of the story: Known good isn’t always enough. Test everything!
Related Articles
- Getting SIMATIC PDM to run in Windows 7
- My Siemens infrared handheld programmier is missing. What do I do?
Related Products
- Siemens SITRANS MultiRanger 100 and 200 ultrasonic level transceivers
- Siemens SITRANS HydroRanger 200 ultrasonic level transceivers for wastewater monitoring and control
- Siemens SIMATIC PDM configuration and diagnostics software
Okay, I’ve confessed.
Now it’s your turn: What was the error you learned the most from? And how has it changed your approach to testing and troubleshooting?
Lesman Tech Tips 