While I'll join you in demanding the kids off our lawns, I'm looking forward to seeing 120V AC run through the very last serial port. There's nothing like send

While I'll join you in demanding the kids off our lawns, I'm looking forward to seeing 120V AC run through the very last serial port. There's nothing like sending a message down the serial power and seeing nothing come back. So many wonderful ways to fail. Does this device require a null modem cable? When the manual said that all commands needed to be terminated with a '\n', did they actually mean "\r\n" and not mention it? Am I sending ASCII bytes to a piece of hardware that expects strings of UTF-16, without documenting it? Did one of the students swap the cables and I'm just talking to a deactivated motor controller? Has this particular serial cable finally bit the dust? Is the hardware expecting me to transmit data on pin seven for some ungodly reason? Did one of the students swap the the detector cable and the pre-amp high voltage line and fry the board I'm trying to talk to? These are all issues that I've had to contend with on serial communications. The big catch is that it's usually not just one of these problems, so I wind up needing to check every possible combination. Having a device on USB saves me a boatload of trouble. The devices hooks up to the computer through a single, standard type of cable. If I can see the device after I plug it in, it's a software problem. If I don't see it, there's a hardware problem. Just from the above scenarios, seeing the equipment NOT connect eliminates 75% of the phase space for the problem. If I DO see the hardware, I've cut out 96%. So much easier to debug with USB.