Setting of Windows XP SP2 for industrial applications

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
[email protected]

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

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.

IIRC, Microsoft added serial comms in Dot Net 2.0.

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

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?

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 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?

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.

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.

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).

Mr. Griffin,
Single port serial card for $12:
http://www.newegg.com/Product/Produ...-Froogle-_-Add-On+Cards-_-Rosewill-_-15166003