- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
But surely an application that has asked the OS to open the port for its own explicit use is not going to have the OS interpreting the incomming data as that is none of its business.
Perhaps the app in this case regularly opened and then closed the port, instead of keeping it open, giving the OS a window of opportunity to do its plug and pray stuff?
Admin
But surely an application that has asked the OS to open the port for its own explicit use is not going to have the OS interpreting the incomming data as that is none of its business.
Perhaps the app in this case regularly opened and then closed the port, instead of keeping it open, giving the OS a window of opportunity to do its plug and pray stuff?
Admin
I'm surprised that nobody checked the microsoft knowledge base for this yet. Here it is: http://support.microsoft.com/kb/283063
Admin
Yup, at one of my old jobs a similar thing. We were writing a serial interface to an EPoS (Electronic Point of Sale or 'shop till/register' to the un-acronym-friendly) and every time Windows was rebooted whilst the EPoS was connected it would cause the EPoS printer to spew out communication failure printouts.
Never did figure out why though, so I guess I guess I'll know what to try and disable next time :)
capthca: waffles ... yum
Admin
Uh, I don't think the problem was due to Windows recognizing the data link as a mouse. If it did, then the cursor would be going all over the place all the time, not just when you move the mouse.
There is a bug in the PC that can cause the mouse to go all funny-- somewhere in the depths of the interrupt handler there's a small window of opportunity where the interrupt controller 8259A-work-alike chip can get confused about what interrupts are pending and which are idle. You see the PC design starting with the AT, mistakenly overlaid some of the hardware interrupts with some of the CPU memory management error interrupts. So sometimes a page fault gets misinterpreted as a serial port interrupt and vice-versa, and things go really haywire.
We first saw this in the good old days of 16-bit DPMI applications. An app would be running just fine, then the mouse would go all wobbly. I still see it on Windows XP every month or so.
Admin
No that's been around forever. Anyone who has tried a Windows upgrade with an UPS connected to the serial port and did not have /noserialmice in boot.ini probably learned the hard way. It can cause an APC UPS to go on-battery.
Admin
Are you always this big a jerk?
Doesn't seem that long to me for him to figure it out. Let's see. A mouse replacement, a network cable disconnect, a reboot, a virus scan, another mouse replacement, a cup of coffee, a solution. That's not very long, especially when you're diagnosing a problem in non-standard hardware to begin with (the test rig he assembled). Not quite the same low level of complexity as, say, your monitor not working.
Admin
Admin
Well, I have no serial port on my laptop, but have a serial device I need to use occasionally. I bought a USB to serial adapter; when I plug the cable for it into a USB port, Windows detects that I've installed a serial port. I guess that makes it plug and play, right?
Admin
Microsoft not only has the KB article linked earlier, they have a tool you can install that will allow you to set which serial ports you want to have off limits for serial mouse detection.
http://support.microsoft.com/kb/819036
I use this all the time as my company has a program which reads a serial data stream and occasionally (not too often), Windows will detect the incoming serial stream as a mouse. Then the cursor will randomly jump around the screen and click on things until you unplug from the serial port. At that point you can use the utility I linked from Microsoft to disable the detection on that mouse port, you can manually edit the registry to make the same changes or you can do the device manager workaround (disable, but don't delete the mouse). I have found the above utility to prevent the problem every time.
Admin
2000, apparently: Serial Device May Be Detected as a Serial Mouse in Windows 2000
Admin
bif, serial isn't all that bad. Just make sure you read the documentation for the device you're talking to and make sure to set the right number of stop bits and set your parity bit correctly. Also make sure you're leaving the right amount of dead time between messages if your device requires it. (some use dead time to detect the end of a msg)
If you were simply seeing rotation in the wrong direction, or off by some factor it sounds more like you were dealing with a misdocumented API and not serial issues.
Admin
C'mon, I really don't think i'm being that unfair...
Seems painfully clear that if things start behaving strangely with one device, perhaps it's got something to do with that new piece of hardware you just connected. maybe - just maybe - that's a lick more likely than "oh noes, we're being haxed".
Admin
GPS devices cause this problem all the time...
Admin
Are you sure? This is a pretty small intuitive leap we're talking about here. More like an intuitive hop.
"Hmm, I plugged in this [presumably] uncommon device into my serial port, and now my mouse is acting up."
Sure, a weekend elapsed in between plugging in the hardware and discovering the problem, but it sure sounds like he couldn't have forgotten that he had this odd piece of gear plugged into his machine since that was the reason "he eagerly went over to the testing PC".
Admin
Things are changing, but slowly. By popular demand, newer gear tends to have USB ports, since the average PC these days comes with 8 USB ports and only one or sometimes zero RS232 ports. Admittedly, the USB port is really just a USB-to-RS232 dongle built inside the case of the device, but between USB and Ethernet interfaces, the writing is on the wall for RS232.
If you have a soldering iron and don't mind voiding the warranty, you just have to remove the USB chip and solder in a voltage converter and a DB9 or DB25 connector.
The Windows drivers for these devices are basically USB serial drivers that use vendor-specific USB device identification instead of the standard device/interface classes for serial ports. Obviously the USB device can't reveal to Windows that it's really an RS232 port, since Windows cannot be trusted to leave those alone. Users of other operating systems are simply told (or left to discover by themselves) that patching their kernel's existing USB-serial driver so it recognizes the device ID's as standard serial ports will more or less work.
Admin
Me too. But I am going better on the task ;D
The machine often generate simptons, so the real cause is elsewhere. So you learn to link what simpton mean what problem.
Theres also humans. Humans generate horrible poor bug reports. Change words, so left can be right, up down, conected mean unconnected. Don't work mean it work, but not on the expected way, etc.
Thats our job, and is cool. :DDD
Admin
The moment i saw rs232 and mouse it was immediately obvious what was happening. Come on, you don't have to be a frickin genius to figure that one out... and I'm not even a hardware engineer.
Admin
I'd think the entire testing PC -- not just the hardware being debugged -- would qualify as "the new piece of hardware you just requestioned for the test rig". I somehow doubt each engineer has their own personal horde of testing hardware without any sort of common pool.
With that in mind, accidentally remoting into the wrong box for debugging being a not-to-uncommon occurrence doesn't seem all that far fetched, when boxes are getting swapped around all the time.
With that in mind, neither is the possibility that the last person to have had their hands on a newly requestioned box be one of the walking talking WTF generators that this site oh so loves to discuss, and are responsible for oh so many breaches of PC security.
So, no, you're not being unfair if the guy is an RS-232 expert surrounded by coworkers who are all completely competent with computers, each with their own horde of testing machines, all toiling in perfect harmony in candyland. But you'll forgive me for not seeing the slightest shred of evidence that we can assume any of those things are the case here. Being a pessimist (an outlook further reinforced just by being on this site), I would in fact assume the very opposite for all of the above.
Aside from the clicking bit, my mouse also regularly spazzes out as described originally. The culprit is invariably a loose piece of hair confusing the optical sensors.
My experience with RS-232 has thankfully been limited to updating a couple shell scripts that talked directly to a couple of label printers. No concurrency management -- queue two large print jobs and the printer would completely spaz out, ruining the contents of both. I wonder if I have a copy of the source of that laying around my hard drive...
Admin
Back in uni, I had a course on industrial automation - At one lecture, the teacher proclaimed that RS-232 was going away rapidly and soon to be replaced by USB. I recall being somewhat sceptical about point of view, as I knew (from my part-time job as an embedded software-engineer-wanna-be) that RS-232 still was a pretty big deal.
Fast forward 5-7 years. I know (from my full-time job as an embedded software-engineer) that RS-232 still is a pretty big deal.
I do agree with ParkinT that RS-232 is old, but I am pretty sure it isn't going away anytime soon. Hey, every half-decent PC-motherboard/cpu-board still has RS-232.
Admin
*too *Yes, you are being fair if...
As I've just wonderfully demonstrated, some people have trouble with even basic English before their coffee as well.
Admin
It's not DAQ, but DAC. (Digital to Analogue Converter).
Admin
Most of that problem is that people can't seem to build RS232-compliant serial ports to save their lives. The problem is even worse on modern PC's, where 99% of serial ports are used to talk to mice and modems, which are (by evolutionary necessity) extremely tolerant of all kinds of crap from their DTE peers.
I did a survey of ~30 computers at my workplace a few years back. There was one (1) compliant serial port out of 30 machines I tested (several whiteboxes, several Dells, the occasional HP desktop or IBM laptop). The others had too little voltage or too much slew. This is a problem when you're talking to 1980's hardware, or even 2000's equipment with ultra-precise input discrimination ("-2.996 volts on your RS-232 data pin? Too close to zero to be valid, no bits for you.")
Ironically, the one compliant serial port was actually a USB-to-RS232 dongle that I only tested because I'd just finished testing two and a half dozen machines without success, and I thought "what the hell?". No wonder the thing cost almost $70, its outputs were just beautiful on an oscilloscope...
Since RS-232 does not specify a packet format or (much) error detection, the occasional lost bit just corrupts data, and usually gets ignored. Thus, "rotate 45 degrees"--which is usually written as something like "rotate 12500 encoder units"--often gets corrupted as "rotate 1250 encoder units" or "rotate 52500 encoder units". It gets even worse when the command protocols aren't ASCII strings--most equipment will raise an error when it sees "rotate !2500 encoder units", but not when it sees "0x52 0xB0 0xD4" instead of "0x52 0x30 0xD4".
I've noticed that too. Things like "VB API" modules that actually implement "write line" and "read line" in a C++ DLL. This isn't too much of a WTF except that "read line" blocks, it's mutually exclusive with "write line" (so don't bother trying to work around this by creating two threads) there is no "data is ready" API nor any timeout facility. This means that if you want to read a response to a command, you had better be sure there will be data coming back from the device or your application will hang. Of course, several of the commands may or may not return responses depending on the state of the physical hardware. It's the kind of useless "API" that you read, say "WTF?", and throw away in under five minutes.
Admin
Nope. Still no go.
"Gee, I just installed a piece of hardware on the COM port, and my USB mouse started misbehaving three days later. Do I automatically make the jump that it's a Plug and Play issue with a serial mouse?" No. I eventually (and probably fairly soon) make the jump, but not immediately.
Admin
Two of those days being Saturday and Sunday.
After trying three different mice. And rebooting several times.
Was it Einstein, or Franklin, that said insanity is trying the same thing several times and expecting different results? Probably neither. Still an interesting thought...
Admin
Admin
quantum physics?
</ignorance>Admin
Admin
These kinds of problems are always <sarcasm> FUN </sarcasm> to troubleshoot.
Imagine an off-brand UPS being detected as a serial mouse. ;)
Hmmm, I wonder if disabling Universal Plug-and-Pray would help a situation like this?
Admin
Re: Mixed Messages 2007-08-28 13:23 • by Grant P. Steve H.: Grant P.: Was it Einstein, or Franklin, that said insanity is trying the same thing several times and expecting different results? Probably neither. Still an interesting thought...
If that's insanity, what is it called when you try the same thing several times and actually get different results?
quantum physics?
Actually, since the environment you are doing the "same thing" in is different, you can count on occasionally getting different results.
Admin
Must be nice when you're not aware of other possibilities...</sarcasm>
Admin
I'm sure it was a combination of me doing everything you mentioned wrong at least once, and my total inexperience. It was enough to scare me away for good, though! We also had this remote relay board that worked a frustrating 80% of the time exactly as it should, and did absolutely nothing the other 20% of the time. The time and cost effective solution was to poll the device on the other side of the relay to see if it was on/off as necessary, rather than getting a more reliable board. Like I mentioned earlier, my hat is off to you guys who do this stuff day-to-day, I'm sticking with Java, HTML, and SQL!
Admin
If you post "fist" then your comment gets deleted, but if you post something as stupid as this your comment gets to stay?
Admin
First off, this is quite possible. I develop FPGA hardware, and often the simplest way to get data out of an embedded soft processor is a serial port. I ran into a very similar problem a while back after rebooting the development PC I was using. I discovered, after a couple of hours, that if I left the FPGA board running, and rebooted the PC, Windows would think that the board was a mouse.
It's not something you run across every day, and Windows will do this with a USB->RS232 converter as well as a real COM port. I'm ashamed to admit, it took me a couple of hours to realize that was what was going on the first time it happened to me.
Apparently, the mouse auto detection system in Windows isn't too hot.
Admin
Admin
you're just jealous.
Admin
I usually know where to look for other people's problems... comes from realizing they are using something for a purpose for which it was not intended.
Captcha: dubya ... WHAT?
Admin
I know that "gee, maybe Windows thinks my hardware diagnostics machine is really a mouse" wouldn't be very high up on my radar.
Admin
Personally, I guessed this one straight away. But that was probably cause I'm reading it on DailyWTF and was expecting something funny... not sure I'd have caught it in real life.
Admin
That's almost irrelevant. What's important is knowing that serial mice were common enough at one time to be supported by Windows "out of the box".
Admin
Admin
"Cuz if you do what you've always done You've always get what you've always got. Uh, could that be nuthin'?"
I doubt they coined the phrase, but people in AA use it, too, in reference to an alcoholic trying over and over to just drink a little bit without keeping on going til he's baked.
Admin
So did Nick ever figure out what was wrong with the automated sorting machine after debugging his test rig? There was an awful lot of setup in that story to leave us hanging like that.
Admin
Admin
Ummm... Today? :-) Seriously - we have an old machine that runs interactive voice software for a phone system; it's still running Windows 95 and has both a serial mouse and a PS/2 keyboard attached.
Agreed. Completely. That was my initial point to Grant P., who seems to be clairvoyant about these things (and oblivious to any other kind of logical thinking). Maybe the clairvoyance is related to the original article giving away the solution, so Grant P. could figure it out.
You know, kinda like when you point out something to a child that they should have known already, and they don't want to admit they didn't know? "Duh! I knew that!" I guess Grant P. hasn't outgrown that yet.
Admin
Yes this does happen with Windoze. I work in the instrumentation field. I had a project once in which one of the data streams was from an RS-232 port. I couldn't use the mouse until I went to the device manager and disabled that "mouse" that windows had detected. Crazy!
Admin
Admin
Hear, hear!
Admin
That's important is it? I must remember to add that to my list of 'important information'.
Admin
Nope, only one. MX5Ringer is from New Zulland.