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

 

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

 

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.

 

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

Regards
cww

 

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

 

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

 

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.

 

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

Dave

 

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.

 

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

 

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