Hi All,

Is there anything wrong in installing Rockwell Softwares and Microwin Step7 Program in same computer? I was advised by one of the Siemens Trainer (local) that you could end up in communication problem. Welcoming ideas / suggestion from experts?

Regards,
Shree

 

There are often issues with multiple software packages running on the same system. Strangely, these often involve competing products:^) What is often a problem with Rockwell and anything else is that they use a background comms server that gets installed to boot automatically and is never taken down (RSLinx). You can probably run the Microwin if you kill RSLinx before you run it. There are so many issues and interactions, what with packages replacing DLLs and other rude and idiotic actions, that it is a major sanity saver to procure several hdds and isolate these poorly written and inconsiderate blobs of software as they are discovered. Unfortunately, said discovery unfailingly involves a large waste of time at best. But, until these miscreants stop writing software as if theirs was the only package that you might want to use, or we get OSS, it's probably the best solution going.

Regards

cww Who has missed every part of working in automation except the whole Windows mess. Well, also excepting the one adapter per PLC ripoff.

 

@cww: "What is often a problem with Rockwell and anything else is that they use a background comms server that gets installed to boot automatically and is never taken down (RSLinx)."

Yes and no. I believe that's the default install, but all you have to do is run Rockwell Software -> RSLinx -> RSLinx Launch Control Utility and uncheck "Always run as service". Why anyone would want it running as a service for programming (as opposed to DDE) purposes is beyond me and does strike me as a little arrogant on AB's part now that I think of it.

Plus, I tend to run all programming apps from inside virtual machines, especially since I'm an independent integrator and program with software from 25 different companies or whatever. Several may be installed on one, but any that don't play well with others get their own dedicated VM. That way AB's/Siemens'/Omron's/Mitsu's crapware isn't interfering with the other brands' software and drivers, nor is it cluttering up my base machine install. Plus it's very clean for backing up installations and moving them from one machine to another, especially since I keep the VM's on their own hard drive.

 

Oh, sorry, I responded to your post before I got all the way to the end of it. I see your solution is similar to mine. I like the VM idea better than multiple HDD's though.

 

AB will take control of the com ports. I asked a Siemens application engineer and He recommended VM ware to set up different plcs in separate vertical machines.

Peter

 

As others have said, RSLinx is usually the biggest culprit, but there can be other problems as well. Software installation on MS Windows is a free-for-all battle, with some programs blithely replacing libraries used by other programs. There's no proper library version system in MS Windows, although they have recently added some hacks to try to work around this. It's a fundamental design problem in Windows however, and you have to hope that the software vendors take care not to stomp all over your other packages.

The other (related) problem is that there's no proper package management system in MS Windows, and if one were introduced at this point it's not likely that third parties would use it. This is what is at the root of the free-for-all during installation. What many software vendors do is to simply install their own private copy of every common library they might need and link to that. However, that means that when security holes are found in those libraries the problem never gets patched.

There was a discussion here a few years ago in which a user had a problem where one major vendor would scan for software from one of their competitors and insist on it being removed from the computer before allowing their own software to be installed.

Some of the problems can be laid at the feet of the software vendors for bad practices on their part (doing things the easy way to save themselves money, regardless of the problems it causes their customers). A lot of the problem however lies in that it is probably a lot more difficult to write good quality software for MS Windows than it is for just about any other major platform out there.

 

I seldom got time for the hdds, let alone trying to set up VMs on the mandated Windows XP. IT finally got weary of tracking all the old, non-standard crap I needed to do automation and left me to my own devices. Later, they had a security drive or something and tried to assume control again. It was pretty amusing as there was even equipment running on Plan 9, which they had never heard of:^) And German versions of DOS and of course, the Linux environments I used when I had to get real work done.

Regards
cww

 

Well, at least there aren't very many of them that have to worry about writing good quality software:^) It seems like we often get TFDTTW (The first %#($ thing that worked, and sometimes, one version prior to that. Can you imagine the effect that a community effort like Fedora would have on these low volume packages? If folks could fix things rather than just live with them, they would get better a lot more rapidly. Of course, that would require OSS so the tools would be available to all. It wouldn't be everyone's cup of tea, but it wouldn't take many volunteers to double the resources that the automation companies can justify. And letting the folks who have to use the package contribute would probably greatly improve the ergonomics of the cruddier ones.

Regards
cww

 

Uh Hugh, sure they would.

The reason RA and Siemens cost what they do and do what they do is the infrastructure needed to maintain, support and R and D them, as well as the infrastructure needed to support the legality of liability etc. I prefer that infrastructure when I make these big decisions that lives depend on.

As your foray into the PLC open market proved Curt......... There is a lot more to it than clicking your heals together and saying "there's no place like home".

Your good tool user:

Dave Ferguson
Control Systems Engineer
And Tool User not Tool Maker

 

This issue is very easy, I have vmware wkstn and a vm built for Siemens S5 one for S7, one for RA Developement one for Intouch, one for GE and one for DeltaV.

While coworker machines struggle, I keep chugging along........one of the best single pieces or Sw I have ever purchased. The minimal time invested far outweighs any pain rebuilding creates....

Dave Ferguson
Control Systems Engineer

Sent from my iPhone

 

Well, the point I was trying to get across is that while the people who write the PLC programming software certainly have to take a share of the blame, you also have to admit that it's not entirely their fault. I guess you could say that ultimately the automation vendors have to take responsibility for it, but on the other hand Microsoft does not exactly make it easy for them.

Given the design of MS Windows, the history, and the industry practices that have grown up with it, I'm not sure there can be a good solution to any of it. It may be that we all need to think about this situation when evaluating products. Being able to run the software in a VM might become the accepted common solution, although there will probably be cases where it won't work (especially with USB devices).

As it is, now that Microsoft is selling their own VM software the other established VM vendors are concerned about whether Windows will be changed in ways intended to shut them out of the market. That would be how Microsoft would have done things in the past. Then what do we do? Will we need a VM to run our VMs? I'm not really convinced that VMs are the complete answer to this.

 

In reply to Dave Ferguson: Are you using the VMs when going on line with the Siemens PLCs, and if so what type of programming adapters are you using?

 

I use Step 7 inside a Virtual PC with the RS232-MPI/Profi adapter and it works fine. Virtual PC doesn't virtualize USB ports so the newer USB-MPI one wouldn't work unless it (like a lot of USB automation stuff) already virtualizes itself to a serial port at the host OS level. If it does that, you can pass that virtual serial port in to the guest machine and it will work OK. The USB-485 converter for Hitachi drives works that way and has no problem with the software running from within a VM.

 

"Being able to run the software in a VM might become the accepted common solution, although there will probably be cases where it won't work (especially with USB devices)."

VMWare supports USB to some extent, and I've always been interested in trying it with automation software for that reason, but haven't done so yet. I use Virtual PC and have a lot of effort invested in creating VPC VM's, but one of these days, I'm going to test VMWare for this purpose.

"As it is, now that Microsoft is selling their own VM software the other established VM vendors are concerned about whether Windows will be changed in ways intended to shut them out of the market. That would be how Microsoft would have done things in the past. Then what do we do?"

So? Is there a reason to believe we can't run our stuff in MS's VM software? That's what I'm using, though I've been using VPC since before it was an MS product. Or just run Windows in a VM on Linux or a Mac. That's probably where I'll end up eventually. Besides, by then maybe some of the automation vendors will be coming out with Linux versions.

 

I am actually in the middle of converting the last S5 in the plant to Controllogix (actually tomorrow) so my VM for that is just being used for offline programming. I do remote access a box and get online so that one is not realistic. But after all this last conversion is over 22 years old. What computer technology is not defunct or close to it after 22 years.

The S7, DeltaV and Plc5 and CLogix are all Ethernet accessed or enet to Dh+, Controlnet (mainly drives) etc. My main access is AB and DeltaV We have a millwide control network tying the entire mill and all controls together with dedicated servers and automatic PLC backup systems etc in place. We have gateways with numerous ways to connect via ethernet to dh+ etc. The one real issue we do still have is GE series 6 stuff and the old Wazi cards but these are again 25 years ish and being replaced.

Now I will say that we are a little off base to think that 25 year old systems should still run on new equipment in the first place although I will say, AB has maintained the best backward compatibility. I still access via gateways almost all of their stuff from anywhere via VM.

The other major advantage of vmware is snapshots and cloning. No more new version crashes or drivers crashes etc. And at least with RA there are now USB adapters to access directly to Dh and Controlnet if you do not have the Ethernet bridging structure in place.

I am more nervous about the lifecycle costs associated with newer hardware and the just in time hardware chips etc than pc access. I have always found ways to access the software, but many are telling me the half life of today's hardware and how the chipsets lifetimes are very short. It is going to be interesting to tell a manager that his 8-10 year old hardware is defunct because the low bid offshore chip maker is gone and noone makes your I/O chips But then again by then I will be on a beach with an umbrella drink....another blog

Dave Ferguson
Control Systems Engineer

Sent from my iPhone

 

Actually, of the choices offered, I too prefer RA. And they do it better than most. They suffer mostly from an unfortunate choice of platform. But, as often happens, you misread my message. Suppose you keep RA as they are, with all their lawyers, etc., etc. Then suppose you find a way to add an army of developers who are deeply interested in automation and knowing what things they would like to see improved. There are a great many RA users that would be in a position to contribute.

I'm going to ignore the slight of OSS developers as most of the hottest, fastest and best new products are now being done with OSS by those same developers.

RA would perhaps benefit less than some others, but everyone knows a programming package that could really use some work. A package or two that just doesn't seem to be getting any better or at best advancing at a glacial pace. A community effort would tremendously benefit those that don't have the resources of a Rockwell and I think the benefit would far outweigh anything that could be lost by opening the source for a mediocre package.

Regards
cww

 

> Besides, by then maybe some of the automation vendors will be coming out with Linux versions. <

We can only hope!

Regards
cww

 

My two cents. I work with S7/Simotion on VMs. I use Systeme Hemholz
NetLink Pro.

Jacek Dobrowolski

 

Dave Ferguson said:
"I am more nervous about the lifecycle costs associated with newer hardware (...) It is going to be interesting to tell a manager that his 8-10 year old hardware is defunct because the low bid offshore chip maker is gone and noone makes your I/O chips."

I think the best answer to that is networked I/O using open protocols. Replacing I/O hardware is never guaranteed to be painless, but at least that way you are unlikely to have to replace everything all at once. If the protocol is open you have a better chance of getting third party I/O hardware if the original vendor stops making it.

 

Michael, here's an example of something that doesn't work in a VM: DH+ to a PLC-5 Classic from a 1784-PCMK/A card in a laptop. Fortunately all my customers that have older 5's are migrating to something more current, but if I wanted to support that configuration from within a VM I'd have to break out the old KF2 and see if I could remember how to make it work.