Control.com - Nerds in Control

Thanks in advance for any help.
I built an automation system using VB6, serial port communication with mscomm32.ocx and TWinCAT I/O. Unfortunately I should restart my program to working properly every 48 hours! If I don't restart it in this period the serial communication can't send recieve the bytes correctly (in 200 and 10400 baud rates). the target of this question is finding that the source of error relate to Windows XP SP2 settings or it is in my program.
This question relate to my previous question that still remain without any reply in the link below.
http://www.control.com/thread/1026243430

Regards,
Najafabadi

Does the serial port driver return any errors? You might have to modify your program to have it log errors to a file (with a time stamp) so you can see what sequence of events leads up to the problem.

You said that rebooting the computer corrects the problem. What happens if your program simply re-initialises the serial port?

I doubt that the problem is related to any particular operating system settings or else it probably wouldn't work at all. However, from my own experience I believe that the "mscomm32.ocx" and MS Windows serial port drivers are not very good. There's not much you can do about it except try to make your own program as tolerant of errors as possible, and try to make it recover from errors automatically.

Also have a look at the basic information about the system as the program is running. Use the OS system monitor to see how much memory or CPU is being used on a regular basis (e.g. once every hour or two and also when the problem occurs. Is the memory usage steadily increasing? Is the CPU usage increasing?

Thank you very much for your guidance. I will check the MSCOMM and IPC memory conditions again, but the two things that increase my doubt about the operating system are first I haven't any error in the program when serial communication with ECU fails (in this case, other part of programs such as menus, ADS.ocx communications with TWinCAT working properly, and communication with PLC from Profibus line working correctly), and second, when I exit from my program in this case and run it again, the problem still exists and is only solved by restarting the IPC.

Many thanks in advance for any other help.

I believe there are some registry issues with mscomm32.ocx

I have two suggestions... based on Michael Giffin's replay dated: Feb 11 08

1. Try registering mscomm32.ocx using the following command
go to start -> run -> regsvr32 mscomm32.ocx

Unregistered mscomm32.ocx could reset the connection periodically...

Suggestion 2: SP2 for WinXP does not have all required updates... as mscomm32.ocx issues for WinXP are there for a long time.
Place Windows XP setup disk in the drive while the PC is already running Windows XP. Try reinstalling WinXP with Setup disk in UPGRADE mode...
NOT UNDER NEW INSTALLATION MODE AS IT WILL DELETE ALL YOUR FILES.

Nanda
Sr. Systems Engineer
nandakumar.gopal@gmail.com

Thank you Nanda very much for your guidance. Your guidance generated another question for me. As you know the VB6 hasn't any I/O port access capability so I use a DLL that I found on the internet for communicating with I/O ports. The DLL name is "inpout32.dll" and I copy it in the Windows\System directory (please notice I copy it in System directory not in system32 directory). It is working but refer to the explained problem. Should I register this DLL for correct working in Windows registry? If the answer is yes please let me know how can I do it.

Many thanks in advance for your help.

Najafabadi

I was under the impression that if an MS Active-X control wasn't in the MS Windows registry, you would get an error message along the lines of "You do not have a license to use this Active X control" (or something similar to that effect).

The mscomm32.ocx is what Microsoft calls a "licensed control" which means you have to have an "enterprise" license to re-distribute it. There is a long rigmarole to get it and various other "licensed" files to install properly on a target computer. What many people ended up doing is installing their copy of Visual Basic (Enterprise Edition) on the target computer and then un-installing VB.

If the program is running at all without giving you error messages complaining about missing files or Active-X controls, then it's probably not because they weren't registered. I suppose it's possible that some Active-X controls would decide that they're a pirate copy and quietly stop working after a few days, but I've never heard of this. It's more likely to be a bug in Microsoft's software.

The mscomm32 file has a long history of bugs, plus there are multiple versions which are not all compatible with all versions of VB. Active-X controls were supposed to have unique ID numbers, but I suppose that rules were made to be broken and Microsoft broke that rule by issuing multiple incompatible versions with the same ID codes. This means you need to know where the mscomm32 you have came from, and whether it really is compatible with the version of VB you have.

The suggestion from Nanda to re-install Windows and hope the problem goes away isn't a bad one. Many IT professionals spend lots of time and money on Microsoft product training just to learn that. While you are at it, re-install the your VB program together with its Active-X and dll files. If there are multiple programs installed, one of them may have quietly installed different versions of some of these Active-X or dll files which are not compatible with your program (the classic Windows "dll hell" problem). If you need to install several programs, install your VB program (and it's associated files) *last*.

If all that doesn't work, then I'm out of suggestions.

Thank you Michael for your complete response. I'm wondering why such a basic and common application (serial communication) hasn't any standard and robust condition in PC based automation, or maybe it has a standard way that I don't know. By the way, is there any web site that I can use as a reference for Windows XP PC base application in industrial field?

Is there any standard and robust way for serial communication in industrial applications in Windows XP?

Many thanks in advance for your help.

I just thought I would mention that, if it were up to Microsoft and Intel, you wouldn't have any serial ports. They deprecated them to be replaced by USB. That may be why their support might be a little weak. They have also deprecated the parallel printer port, also to be replaced by USB. And because it is aimed in the opposite direction from automation needs, using Windows XP for industrial applications is like training your English Sheepdog to catch mice. Yeah, it can be done, but there are a lot better choices. Something smaller and more agile will catch a lot more mice and won't cause nearly as much collateral damage. The thinking goes like this in big automation: We need to do very important things in a predictable amount of time... Let's start with 45 million lines of the least reliable,
least secure code we can find. The transparent frames and sound effects are really neat! And we'll maintain full employment with the churn.

Regards

cww

So your point Curt is that we stay in 1980 and pass bits at 19.2 k for the rest of our lives?

We are on year 10 of the rant against Microsoft and in the meantime we have 95+% of the Automation vendors supporting MS and nearly 99+% of customers comfortable with supporting it. Yet you keep insisting that it is dead.

Again, as I have repeated for the last 10 years (and running) the rest of us will continue to solve problems with the tools that most want while others are busy arguing that the hammer we are using is garbage.

It is getting old... my Grandfather used to say that "Everyone hates the rich guy, yet He is the only one handing out jobs." The target is always on the back of the market leader... by a mile.

And as usual, I do not think MS is the perfect but it is the most perfect thing we have that is accepted by the most people (again by a mile, not an inch, a mile).

PS: if you want an old serial port, buy one for $9 and add it. But why...?

Dave Ferguson

Because I use all kinds of automation gear that use serial comms and it is a better fit for that equipment than the other choices.

Distributing dozens of barcode readers and label printers could cost 10 times more using anything else, for example. Most of the automation protocols is use are on top of serial comms.  Displays, keypads, scales dataloggers, building controls, etc.,etc.

I'm not sure what facet of industry you are in, but I use my serial ports all day, every day, and we have miles of serial links doing their thing 24x7x365. And very few could be economically replaced with anything else.  Almost all are beyond USB reach.  I have no automation stuff that uses USB. I do use a stick drive and a camera, but that's about it.

That would be why.

Regards.
cww

In reply to Curt Wuollet: If you look at PC motherboards intended for commercial/industrial use, they still typically have 4 serial ports, although they don't bring them all out to the edge (you have to plug cables in and bring them out on a separate plate). They still use serial ports in a lot of POS applications and that market is a lot bigger than industry (big enough to target as a specific market).

My POINT Curt, is that the fact that PC makers and motherboard makers and customers (non-industrial) are not using serial ports any more is Microsoft's evil plot?

How are you going to talk to a serial bar code scanner in Linux in 5 years with a PC, e-bay?

Everything that happens in this world is not Microsoft's evil doing as you seam to think.

Part of your plants 5 year strategic plan should be to either stock up on these soon to be, or already, obsolete parts, or plan an upgrade. Part of our strategic 5 year obsolescence plan is to look at this and come up with some sort of plan (if your company is forward thinking). But blame consumers and blame hardware manufacturers (mostly based on supply and demand) but quit boring us with the endless MS bashing.

Most of our equipment that is "running" the plant, is not tied into a serial port on a PC, it is brought into some "industrial control" and then data may be passed. And yes we are having and going to have issues with serial port and parallel port obsolescence, but not any more than DH+ going away or ISA slots or any other obsolescence plan. Those are going to be costs of doing business. But once again, not an evil MS plan to get even with Curt.

Your credibility goes down when everything that happens in the world is based on something evil Bill did.

PS: Give me an old 340 Mopar motor with no controls on it, or a 289 or a
302 Chevy, easy to work on and 12-13 miles per gallon. Damn Microsoft !

Dave

Hi Dave

On Feb 17, 2008 3:40 pm by Dave Ferguson wrote:
My POINT Curt, is that the fact that PC makers and motherboard makers and customers (non-industrial) are not using serial ports any more is Microsoft's evil plot?

cww:
No, serial ports were deprecated in the joint MS-Intel Direction document they publish from time to time to tell us what they are going to let us have. No plot about it, but it is evil because
only Windows on desktops has no use for serial ports. Among their other bright ideas are hdds and other peripherals that have on board security
so they won't work with content not approved of by MS. I'm not making this stuff up. It's way too high handed for that.

Dave Ferguson: How are you going to talk to a serial bar code scanner in Linux in 5 years with a PC, e-bay?

cww: The Linux market will have seen to it that monopoly control over hardware doesn't happen. Vista was to have tied together Platinum and other OS specific excesses, but Vista didn't go as planned and their power is slipping when Walmart is selling out of Linux machines. Expect
Vista to be the new ME, something they would like to forget.  I'm not overly concerned because I can run Linux on whatever hardware does have serial ports.

And I can gain a win for implementing on Linux by simply showing cost data for say 16 barcode scanners and 16 barcode printers on the various platforms. The PLC way would be laughably
expensive and the Windows way would need 16 more PCs and Windows licenses because the MS partner deprecated RS232. My point is that you have to have a better replacement before you shoot your mule.

Dave Ferguson: Everything that happens in this world is not Microsoft's evil doing as you seam to think.

cww: Not everything, but most things that are anti-competitive or make things difficult for Open Systems have their origin in Redmond. The whole IP protection scam is just a way to lock up everyone's data with MS holding the keys, as
is the whole Open Document scandal.

Dave Ferguson: Part of your plants 5 year strategic plan should be to either stock up on
these soon to be, or already, obsolete parts, or plan an upgrade. Part of our strategic 5 year obsolescence plan is to look at this and come up with some sort of plan (if your company is forward thinking). But blame consumers and blame hardware manufacturers (mostly based on supply and demand) but quit boring us with the endless MS bashing.

cww: It's stupid to buy hardware that doesn't
have the features you need now. A better plan is to migrate to other platforms if one is going in the wrong direction.  It's really dubious planning when I hear: "My new laptop from IT doesn't have a serial port, what do I do?" My response is to suggest to the highest level you are responsible to that they fire the IT staff
for their abject and total failure in needs assessment. They may not do that, but your laptop will have a serial port.

Dave Ferguson: Most of our equipment that is "running" the plant, is not tied into a serial port on a PC, it is brought into some "industrial control" and then data may be passed. And yes we are having and going to have issues with serial port and parallel port obsolescence, but not any more than DH+ going away or ISA slots or any other obsolescence plan. Those are going to be costs of doing business. But once again, not an evil MS plan to get even with Curt.

cww: That's a laugh, they can't get Curt.
I can do anything I need to do without any MS products and have for many years. They can however screw things up for my employers, customers and their legions of slaves.

Dave Ferguson: Your credibility goes down when everything that happens in the world is based on something evil Bill did.

cww: Yours is a little suspect when you can't see what's going on. You aren't typically convicted for anti-trust violations in several  countries without reason.  I don't blame you, I think it's the Stockholm syndrome.

Dave Ferguson: PS: Give me an old 340 Mopar motor with no controls on it, or a 289 or a
302 Chevy, easy to work on and 12-13 miles per gallon. Damn Microsoft !

cww: I'm rather fond of the 396, I stuffed one in a '69 Camaro. But I fully appreciate my stock Neon 2.0 liter with 1 horse per cube and 33 mpg. And it will run 250,000 miles.  And pull more G's cornering than the Camero. Progress isn't all bad. But if it weren't for competition, we'd still be stuck in the 70's.

Regards
cww

On to year 11....................................

Dave

In reply to DAVE FERGUSON: Where are you seeing the $9 serial ports? PCI is obsolete (or nearly so), and the PCI Express ones that I have seen are in the $50 to $100 range. The price of these things seems to have gone up dramatically now that the market for them has shrunk. I didn't see any PCI Express serial boards at Digi. Startech seems to have some, but only at the price mentioned above. The single port boards are now not much less than the multi-port boards. Some of the surplus stores have cheap serial boards, but only PCI or even ISA. Support for this hardware seems to be drying up.

It's not a lack of serial support in XP, but a problem with Visual Basic supporting serial ports in a robust manner. I would suggest using native
windows system calls from visual C++.

Well, I didn't say this was a problem inherent to PCs, I said it was a problem with MS Windows. In addition, you are using an "Active-X control", which is a separate piece of software, adding another place for things to go wrong. And while the serial communications in MS Windows is not very good, most people don't have problems to the same degree that you do.

There was never much demand for serial communications in the main markets for MS Windows. Industrial automation is a relatively small market and there really isn't any reason for Microsoft to worry about what that market needs. The main use for serial communications for MS Windows was external dial-up modems, which weren't widely used anyway since internal modems were cheaper. People doing a lot of serial communications used multi-port serial boards which came with their own drivers. The main market for these anyway were people like ISPs (Internet Service Providers), who didn't use Windows anyway.

I've done serial communications on MS Windows in industrial applications, and I didn't have problems to the same degree that you have. The main problem I've seen with Windows is slower through-put and a higher error rate (dropped characters) as compared with the same applications on Linux. When slowed down though, the applications on Windows did (do) run day after day.

Currently VB6 is obsolete, so Microsoft doesn't support it anymore. VB dot Net doesn't support serial communications. Microsoft suggests copying the old (and obsolete) mscomm control from VB6 and using that. It's a bit of a hack to get it to work, but then Active-X always seemed like an ugly hack to begin with (which is why it's obsolete).

There are third party serial port libraries available. If you do a search on Google for "visual basic serial port library" you will find some. You don't *have* to use the mscomm Active-X control.

As for application information, do some searches in Google. Web sites other than Microsoft's are usually the best sources for useful and understandable examples.

In VB2005 they included a RS232 control.

In reply to Miguel & William Sturm: Have either of you tried the new serial control yet? I don't know anyone who is using Dot Net 2.0, as anyone I know doing work with Microsoft software has told me they have been sticking with Dot Net 1.x because of compatibility problems (I'm not sure of what sort). Does it work reasonably well?

I doubled checked on Microsoft's site just before I replied to Najafabadi a couple of days ago and couldn't find any mention of serial support. No doubt it's there somewhere, but all I could find was their advice on copying the old VB6 control into VB Dot Net. I just now had another look on third party (non-Microsoft) sites and did see a few references, including code samples. There doesn't seem to be a lot of information though.

I must admit that I am not using it either. I have a serial library from Franson that works quite well with DotNet 1.1 and I have several programs written in DotNet 1.1 and I have no incentive to spend time "upgrading" to DotNet 2.0. There is just no reason to do so.

I have read an article in Circuit Cellar magazine that was using the new DotNet serial routines to talk to Modbus. I assume that it was working...

.Net 2.0 is much better than 1.x. There is no reason to stick with 1.x wich can't edit an continue. I loved VB6 and didn't find a good reason to switch to .Net 2003 , but 2005 in finally a very good tool. 2008 (.net 3.5) is an incremental improvement of 2005 and is very compatible with it.

IIRC, Microsoft added serial comms in Dot Net 2.0.

Dear Michael,

I think my serial communication problem has the same problem as your experience, slowing communication and lost characters after more than one day of workings. Could you please let me know how you overcome this problem in your project?

In reply to Najafabadi: I don't see how your problem is the same as the one I described, as you said the serial comms was "locking up", not just being (relatively) slow and unreliable. Is it "locking up", or are you just losing characters? It makes a big difference as to what the problem might be. Can you give more details of exactly what is happening?

Have you checked memory usage as well? Use the Windows system monitor (I can't remember the correct name for it) to check what the memory usage is at regular intervals, both when it is running well, as well as when there are problems. Is the RAM getting used up?

Mr. Griffin,
Single port serial card for $12:
http://www.newegg.com/Product/Product.aspx?Item=N82E16815166003&am p;ATT=15-166-003&CMP=OTC-Froogle&nm_mc=OTC-Froogle&cm_mmc=OTC -Froogle-_-Add-On+Cards-_-Rosewill-_-15166003

In reply to Carl Ellis: That's a PCI board, not PCI Express. PCI is being phased out on newer systems.

Dear Michael,

I will check the memory of the system very soon. I have delay in sending (or may be receiving) characters after one day. In KWP2000 protocol you should send first a wakeup, 25ms low and 25 ms high and after that send start communication string 80 28 F1 01 81 1B in 10400 bauds to the ECU. If communication correctly established then ECU response correctly. For generating the wakeup I send F0 in 200 baud and then wait for 50ms. For generating non standard baud rates I change the serial port communication's divider (IC 16550) using InpOut.dll.

Many thanks for your previos and future helps.

Najafabadi

Why don't you just compile with profiling turned on and.... Oh, never mind, you don't have source code.

Regards
cww

This is quite a different description than you first gave. A more accurate and detailed description results in a better answer.

A system gradually slowing down *may* possibly indicate a resource leak. Memory leaks are the most common type of problem of this sort. Some piece of software may be consuming more and more memory due to a bug, eventually resulting in running out of RAM. When the system starts running out of RAM, the OS will start swapping memory to disk. When this starts happening, things slow down dramatically. If the swap file or swap partition fills up, then the system can crash completely. Before things grind to a complete halt, the OS may start killing off processes (I'm not sure how MS Windows handles this) to try to free up memory.

Check the memory by using the system monitor. On MS Windows you press Ctrl-Alt-Delete, and then pick one of the options (I forget what it is called exactly). Check the memory and swap usage on a regular basis (e.g. once per hour) and *write it down*. You may see a trend where it goes up for a while, comes back down a bit, and then continues going up again. If the overall trend however is upwards, then you have a memory leak. I've seen problems like this take several days to run out of memory, so it isn't something that you can be sure of just by checking once or twice.

You said you are using TwinCat I/O on the system. Is your software using OPC to communicate to it? OPC drivers have a long history of memory leaks. If you do find that there is a memory leak, see if you can stop (exit) the OPC driver and then check memory usage to see if that is the source of the problem. Do the same one by one for any auxiliary programs that are running.

You might also want to check your VB program for anything that it might be using that would accumulate over time. Is it creating any temporary files that it keeps appending to? Is is writing to a database where something isn't getting flushed out and closed regularly?

As for timing in general, not only is MS Windows not a real time operating system, it isn't even very regular or repeatable when it comes to timing. I've seen delays of 50ms to 100ms when MS Windows decides it has to do some clean up work on the hard drive. Is the hard drive light flickering frequently when you are having problems (i.e. is it doing a lot of disk IO)? Try to see what other symptoms you may be able to spy.

If this is the case, switch to .Net 2.0. It solves the memory leaking problems by the garbage collection. Twincat comes with a specific DLL to comunicate with .Net. No reason to use OPC.

I have a Twincat-VB2005 application running for more than a month with no visible leakage.

In reply to Miguel: At this time we don't know if there are any memory (or other resource) leaks. It is just speculation at this point based on the recent statement that the program gradually slows down over several days. There are other things which can cause this symptom, but memory usage is the easiest to check and OPC has a history of leaks. The description of this problem has gone through several changes, so I would be hesitant to propose any major changes to the software yet.

VB Dot Net is not compatible with VB "Classic" (VB6 and earlier). Porting a VB program to VB Dot Net is exactly that - a port with some research, rewriting, testing, and debugging to do. It's not something you want to do without a good reason. On the other hand, it is true that VB "Classic" is obsolete and unsupported. But that's one of the problems you decide to live with if you use one of Microsoft's proprietary languages. Their proprietary languages come and go according to their current sales strategy just like any of their other product lines.

As for garbage collection, it's not a magic answer as the garbage collector in MS Dot Net is not very sophisticated. People still get memory leaks with Dot Net programs, they just get them in a different and less obvious way. Garbage collection does save the programmer some of the manual memory bookeeping type work. If you are not careful how you write your program though, the garbage collector algorithm can't detect that an object is no longer used. This causes "dead" objects to build up in memory just like forgetting to do a "free" with C.

Najafabadi,

The thread seems to have wandered off your topic. I recently purchased a Dell laptop for the exclusive use of Rockwell software. Because of a previous bad experience installing RSLogix I had the local rep deliver it with software installed and running. I found it very slow, and sent it back. After a week their conclusion was the version of XP that came with the laptop had too much garbage attached. After re-formatting with regular XP and Office the PC is fine. When I spoke to the rep months later he told me they now recommend to re-install XP with new PCs. I expect other PC vendors likely ship their hardware with some form of hybrid MS as well. Could that be part of your problem?

Regards,
Roy

In reply to Roy Matson: Dell, HP, and other major PC manufacturers get paid to install what is commonly known as "crapware". These are usually demo or trial versions of third party software, or software that delivers advertising by one means or another. The amount the PC vendors get paid is significant, as this is an important advertising and sales channel for companies selling software or delivering targeted ads.

This software does cause a lot of problems, but it's usually fairly consistent, not something that builds up over time unless it has bugs. If someone is looking for problems there, then they should also look for any viruses, spyware, etc. that might be present.

Large companies usually wipe the hard drives on their new PCs and do a fresh install, so this usually affects people who use the PC as is. Unfortunately, that includes a lot of people in the automation business. Small local PC shops who build their own PCs usually deliver them with a stock MS Windows install. You can buy a retail copy of MS-Windows and install it yourself, but that can be expensive and time consuming, and you are essentially paying for MS Windows twice. I think that Apple delivers some demo versions of their software on the Mac, but nothing as obnoxious as what gets delivered on an MS Windows PC. This problem doesn't exist at all with Linux.

As a side note, Microsoft has noticed this revenue stream and plans to incorporate advertising delivery features into future versions of some of their own software. These will display adds on the MS Windows desktop and on unused areas of the MS Office menu bars. I think they are in fact already doing this in some test markets. Some versions of the old Eudora e-mail client used to do this, so it's not a new concept.

Hi everybody,
Thank you all for your useful guidance. I check the memory usage by using task manager. I noticed that the system cashe is increasing and also kernel's memory. Now I am trying to find that is this in the nature of Windows or my program's problem?
Please help me to find an easy way to find the leakage source.

Best regards,
B.Najafabadipour

You need to be looking at the amount of RAM plus swap that is being consumed. I don't recall the terminology that Microsoft uses. They have a tendency to make up their own names for things instead of following industry standard terminology. However there will be one or more numbers which indicate how much RAM has been allocated for applications, how much swap, etc. The swap won't be used until RAM is almost fully consumed, at which point some RAM pages will be swapped out to free up physical RAM. This process will continue until the swap is full. If you see an increasing trend leading to the system crashing or programs being killed off, then you probably have a memory leak.

MS Windows has had memory leaks. However, these are most commonly found in application programs. It is very hard for any of us to suggest where the problem might be as we don't know the details of *all* the software which might be on your computer.

The first thing you need to do is make a list of all the software you have added to the system. If you are using any proprietary software, then you can try contacting the vendors and seeing if they have released any fixes for this problem. If they have not, then you are in for a hard time because it's very difficult to diagnose this problem and impossible to correct it without source code.

If all the software which was added was written by you, then you need to do a code inspection. Start looking through the source code for any places where you are allocating memory but not releasing it. VB programs don't typically do dynamic memory allocation (I'm not sure it's even possible), so it's not as difficult as it sounds to do a thorough job on this.

If the above steps don't yield any results, then you need to set up a test system. This means setting up a system which duplicates the conditions of your production system. Then, start setting up software tests which exercise each software component until you find one which causes the same symptoms. If any of the software components are proprietary products with single use licenses, then you are pretty much out of luck unless you happen to have a spare license, or you can afford to shut down the production system for several days.

This is just like troubleshooting a machine. Try to measure the problem, then start making changes to the system until the problem goes away. When the problem goes away, make additional tests to confirm that that change actually caused the improvement rather than it being just chance.

I have lots of experience writing serial communications software for the PC and experience with firmware on the other side of things.

While Windows comm stuff may not be perfect, you can definitely get things working in it. If you're doing stuff in C++ (whether it's Visual or C++ Builder -- my preference as it's not MS), you can simply use the Windows API calls: CreateFile, ReadFile, WriteFile, and CloseHandle. Along with some initial calls to GetCommTimeouts, SetCommTimeouts, GetCommState, BuildCommDCB, and SetCommState to get things all setup before doing your comm.

I've done stuff that works on standard serial ports, and with the timeouts set properly it will work on other emulated ports, such as USB-to-serial ports, ethernet to serial ports, and even BlueTooth serial ports.

For those systems that don't have standard ports... get a USB-to-serial converter. That way you keep things serial but use USB. Just don't buy a Belkin one (as they have problems properly functioning -- they can't send "break" signals and can otherwise lockup your entire system). You will have to allow for some longer delays in your comm (which USB introduces), random delays up to 150ms at times (generally between packets), but it'l work fine after you overcome that. With little to no code changes (besides timeouts). With the right drivers you can even bump that Baud rate up above 115.2k... I've successfully written stuff for 921.6k Baud without problem... nice and speedy for large serial transfers.

So... getting around to the topic of the post... your problem isn't Windows XP SP2, it's just the communications component you're using. Or, it's something else un-related as you have already discussed, such as a memory leak or system resource issue. Although that seems like it may be somewhat unlikely.

Also, when doing comm, especially if you're doing it in a separate thread from your UI stuff, you probably want to bump up the priority, so nothing gets dropped (so serious system usage doesn't affect the com)... it should be of higher priority than a normal process/thread.

Just my 6 cents.

Ian