AB past issue

[BobB]

Oh boy!!! Upload and compare with the file on your hard disk is something I think most of us have wanted for a long time. It cannot be that hard to do. The latest Omron CX-Programmer has this feature. ABOUT TIME!!!

All PLC software packages should have a selection of what YOU require to upload/download. For example, I/O table, program, various memory areas etc etc.

Why can't AB supply a conversion feature from CPU to CPU in their software as standard? Very fiddly having to change miles of logic from a 5/03 to a 5/05, as mentioned by jshiepe. Particularly as the processors are in the same PLC series. It cannot be that hard. Omron have this as a standard feature. For example, from a C200H (now not supported) to a CS1. Just change the processor and the software will update the program to the newer PLC. They also have an import function from older Omron packages included (CSV files). So do Mitsubishi, with a few limitations. I have been caught with Mitsubishi and have had to re-write programs before.

I suppose one of the great limitations AB would have is the variety of software packages they have available for different PLCs. Omron, Mitsubishi etc have one programming package for all models that allows this sort of interaction as part of the package.

To all those sensitive AB users, I am not knocking AB PLCs, only the people writing their software. AB are not the only manufacturers making a lot of money out of selling a different software package for everything. Others are also guilty such as Schneider etc etc.

Why can't we have one package for ALL PLCs in one brand with add ons or plug ins for additional features, Device Net and Profibus configuraters for example.

Omron, for example, have the one package for all modern PLCs, INCLUDING NETWORKING. It is quite inexpensive and a really good package. BUT, you have to buy a separate Device Net configurator. WHY? Why not have an additional plug in that allows you to purchase this as an addition to the main package?

Here we go, my pet hates about software again. Unfortunately the manufacturers do not appear to seek from the programming community what WE want in the software. The only thing that appears to matter is making money from selling us a separate package for everything they make and not a package that makes our lives easier. Shades of Bill Gates?????

Sorry to have wandered off to my pet hate about software but I do think it is relevant to the post.

And yes PhillipW, I do know where you are heading with this

One of the key things most AB PLC's do differently is that their memory allocation is allowed to be freely allocated between both logic and data. ie if you have say 1M of free memory it can be used for 900k of logic and 100k of data, or vice versa.

Pretty well impossible to change that on the fly, one would think. The ability to change memory allocations is certainly a strength in the AB armoury.

Mitsubishi have the same problem with trying to change retentive memory areas to non retentive memory areas on the fly. That method of being able to change the format of memory areas is one of their strengths.

 

[jshiepe]

Bob,

Just to clarify my situation a little better, you should know that the program conversion I did(from a logic standpoint) was more out of desire or need for streamlining than it was out of necessity. There were some instructions available in the 5/05 that were not in the 5/03, and I wanted to take advantage of them. When you change processors, RSLogix does do some conversion of data tables, but your logic will remain the same. Nonetheless, my logic changes were large enough that they would have been impractical to try and do during the machine downtime, thus the desire for the "synchronize" data option so I could just move the old data to the new program.

Philip,

You as the user may well intend to use the technique in one set of circumstances where it would work,. eg. put the processor into program, upload, sychnronise, recompile, download, and then return to run mode...but I am not sure that there is any easy way to ENFORCE such a procedure on all users.

I can understand your apprehension, but doesn't this start to lean toward a long running concern of just about everyone on this forum?......that concern being that PLC programming should only be done by qualified professionals who understand good programming practices, those of which include protecting the process within which you are programming. Some years ago on a similar forum, I took offense to someone who stated "ladder logic is so easy that any high school grad could program in it". While this may be partially true as ladder is inherently intuitive for the most part, what really triggered me about his comment was this vision of these runaway high school hackers throwing some code together to run a process without really understanding what was behind it. For the most part, I think the greater majority of us here can testify that the industry wouldn't stand for this, although others (as seen in other threads) have come across some programming from some these self-proclaimed prodigies.

Anyway, my point is that, just as with any other product or device out there that is intended solely for use by professionals, the developers need to satisfy their power users and just be sure there are proper legal disclaimers in place for features that may damage the process. There are a number of AB/Rockwell products out there on the market right now that have such disclaimers......I can recall seeing several warnings in some of the hardware and software manuals relating to "unexpected machine operation may occur" or "bodily harm may result"...etc....

The bottom line is that as professionals and power users of this costly software, we understand that there is a certain amount of liabilty that goes along with this trade. Why would the addition of other features that threaten the process make us any less aware of this liability?

 

[PhilipW]

Bob.

Just to clarify your question re file compare...yes RSLogix500 has had this tool for some time now, and it happily works with offline and uploaded files. What I don't think it can do is compare an offline file with an active online processor in run mode...after all the online data would be changing and make the comparison impossible.

All PLC software packages should have a selection of what YOU require to upload/download. For example, I/O table, program, various memory areas etc etc.

Um yes...but again why not just upload the whole program and use what ever tools you prefer to manipulate the files you are interested in. Again I make the point that anything you do offline is ASYNCHRONOUS to the online processor, so uploading just some files or the whole program really makes no difference.

And the ability to download whatever changes you have made (and remember that offline their are no limits to the changes you can make) on top of existing code in the processor, and expecting both to always seamlessly integrate is just asking too much.

Why can't AB supply a conversion feature from CPU to CPU in their software as standard? .

Bob I think you have misinterpreted the deal. Converting from one AB processor to another within a family is trivial, and converting between families (and there really are only three, PLC5, SLC500/Micro, and ControlLogix programmmed repsectively by RSLogix5, RSLogix500 and RSLogix5000.) is very achievable.

Of course instructions and addressing modes, or features available in one product but not in another MUST be handled manually as the software has no way of mind reading your intentions about how to handle these differences.

Omron, for example, have the one package for all modern PLCs

Yup...but the key point here is the term "modern PLC".

The PLC5 was first launched in the mid 80's, the SLC 500 in 1990 and ControlLogix in 1998. I guess we could quibble this point endlessly but given that PLC5 and SLC500 are very different machines under the hood (interpreted versus compiled code) and at the time of launch they both programmed in DOS packages (6200 and APS), I think it can be understood why they did this.

RSLogix 5 for the PLC 5 was introduced only in the late 90's to replace the old DOS packages. By comparison I don't think Schneider produce a 32bit Windows package for their original 984/884 Series (someone correct me if I am wrong), and maybe you can tell me what Windows support Omron have for their 1980's mid-large PLC5 equivalent?

ControlLogix is really AB's "modern PLC". RSLogix5000 supports a range of processors. I've just opened up mine and counted 15 different processors/platforms and there are more in the latest version.

Again the significant "under the hood" technical differences between SLC500 and ControlLogix more or less preclude any integration between RSLogix 500 and RSLogix 5000. Anyone who has used both will concede that point.

What this boils down to is that Rockwell have three major logic packages because it has a massive installed base of product spanning three decades and getting all of that product into one package makes neither technical nor commercial sense.

 

[PhilipW]

Anyway, my point is that, just as with any other product or device out there that is intended solely for use by professionals, the developers need to satisfy their power users and just be sure there are proper legal disclaimers in place for features that may damage the process.

An interesting line of thought js. You are probably right, but reality is that there are a VERY wide range of people out there using PLC's.

One of the merit of PLC's is that they can be effectively used by folks doing everything from the simplest functions replacing a few timers and relays, to ...well the sky is the limit.

And the guys developing programs like RSLogix have no way of mind reading the technical professionalism of any given end-user and so I guess they produce software that covers the middle of the road and covers their legal ***.

Unless of course you want different versions, like RSLogix for Dummies, RSLogix Standard, and RSLogix for PowerGeeks. ooops but then Bob would be grizzling about how vendors love to rip everyone for all these different packages..sighs.

 

[BobB]

and maybe you can tell me what Windows support Omron have for their 1980's mid-large PLC5 equivalent?

Actually not a problem Phillip. Syswin covers all the old girls, enevn the old C20, C120, C500 etc with the exception of the original steppers and the S7. Very few of these had any communications capabilities at all. I still have some old software for the M1R, I believe, but that is not covered in Windows software at all. Can't remember when I last saw one. CX-Programmer covers all the rest. Both packages have import functions from Omron produced DOS packages in built. This does not include the old favourite CAPS as this was produced by a third party developer.

This appears to be a bit of a rariety in the PLC field. As mentioned, I have been caught with Mitsubishi. I used SC software for some time and programs from that software do not appear to have the ability to be imported into GX Developer. Had to extract the program and re-comment completely.

Syswin 3.4 is now available for free, Jay Anthony has posted a website address where this can be obtained. CX-Programmer only costs about $1400.00 AUS and about $350.00 per upgrade. Very reasonable.

You are correct, I did misinterpret the deal.

but given that PLC5 and SLC500 are very different machines under the hood (interpreted versus compiled code)

Fair enough.

ooops but then Bob would be grizzling about how vendors love to rip everyone for all these different packages..sighs.

I will always grumble about that issue. I cannot understand why manufacturers charge so much for software. The hardware makes money for them or they would not produce and sell it. I understand that it costs a lot of money to produce usefull software but the software should be reasonably priced as an enticement and tool to use the hardware. Ask an experienced marketing man about that issue.

Unless of course you want different versions, like RSLogix for Dummies, RSLogix Standard, and RSLogix for PowerGeeks.

Please NO!!!! It is bad enough now.

Don't you think plug ins would be a good idea? It is possible with all sorts of software these days and just makes sense to me.

By the way, Omron is obviously my favoured brand but I am a self employed intergrator and use whatever my client requires, at the end of the day. But as such, I need to get in and write the program and commission it quickly so tha I can make a bob. I just find some packages cumbersome and lacking in usability compared to others. NONE of them are perfect. I guess in a perfect world we would all get what we would like in these packages. Mmmmm. Isn't that a pipe dream

 

[PhilipW]

Bob. So AB and Omron are not so very far apart after all. Omron has two packages, Syswin and CX Programmer and AB have three versions of RSLogix. If we allow that AB had to create separate package for PLC5 and SLC500 for technical reasons, then it all evens out.

RSLogix 5 and 500 are both 32 bit Windows packages that are still very much current product and have new features added at quite regular intervals eg the most recent RSLogix 500 version includes:

"What's New in RSLogix 500 version 6.10:

Added support for the 1769-SM1 module, including additions to the message instruction (MSG) to allow "CIP Generic" type messaging with this module
Added the Modbus Master driver to the MicroLogix 1200 and 1500
Added the Store and Forward Node Table for the DF1 Radio Modem driver—SLC and ML1200/1500
Added the Active Node Table for the DF1 HD Master driver-SLC and ML1200/1500
Added support for the 1762-OX6I module
Added support for the 1762-OF4 module
Added configuration applets for 1746-NO8I and NO8V modules (Class 3)"

I only quote this as evidence that the SLC family and it's programming software are NOT dead and will continue to see enhancements added for some years to come. And also why Rockwell continue to see RSLogix5/500 as viable commercial products.

If we allow Syswin to be the equivalent product, then although I am not well informed about it's history, I do know that here in NZ a lot of it was given away for free, so it would be very difficult for anyone to attempt to charge for it now.

I cannot understand why manufacturers charge so much for software. The hardware makes money for them or they would not produce and sell it. I understand that it costs a lot of money to produce usefull software but the software should be reasonably priced as an enticement and tool to use the hardware. Ask an experienced marketing man about that issue.

I hesitate to bite off this old issue. There is merit in the idea of giving the software away to encourage hardware sales. However I respectfully suggest that this arguement is counter-weighted by:

1. If the hardware subsidises the software, ie each processor has x% margin that goes to the software house, then why should the guy who buys 1000 processors pay 1000 times more for his software than the guy who buys only 1? Maybe you feel this is ok, but it will not be perceived the same by everybody.

2. Corporatations are hard pressed to justify investing cash into products that don't have a clearly defined income stream. Without a clear commercial identify within the corporate the software division tends to become stagant and no longer attracts the right people.

3. Twenty years ago PLC's were mostly a hardware device with a simple software interface that programmed them. The value was mostly in the hardware. Nowadays the value of a PLC is mostly in it's firmware and tightly coupled programming tool. Margins in the business reflect this. Look at the wider non-automation market...companies making money SELL their software and services, hardware is almost a commodity. Therefore Rockwell made a concious choice years ago to establish and protect the real value of what they sell (firmware and software) by charging for it.

4. And finally...from a purely selfish perspective I would not mind if they charged TWICE as much for software...it creates a barrier to entry to my market (the same as yours Bob)...to my low cost "one man band" competitors. (No this is not a good reason, but it true anyhow )

 

[MisInformed]

I guess I'm looking at this problem with data tables being overwritten a bit too simply but I can't seem to grasp the real problem. I've learned from past experience to always upload the current program from the controller and rename it before I do anything else. I am not the only person making changes to our PLC's (SLC's and ControlLogix) so the only way to be sure I have the latest version on my computer is to do this. Is it the best way of doing it? I don't know but it works for me. And it doesn't take much time to do it either. It's not like an upload takes an hour to do and the machine will be down the whole time. Most uploads are done in a couple of minutes. I also try to upload from all my PLC's at least once a month and store that data on our network. Bit of my paranoia about not having a working copy when I need it I guess but it has saved me a few times. The only time that this becomes a problem is if we lose a processor, which has only happened once to me in the last 9 years, and then I have to hope that I have a backup copy ready to go. With my current system I may lose a couple of operator changes but not many.

 

[jshiepe]

Mis,

Re-read my post a little closer. The problem is that I am not only swapping out SLC's, but downloading a completely modified program to the new SLC. The important part is that I need to use the most recent data tables(via an upload at swap-out time) from the old 5/03 to make sure all user settings are preserved in the new 5/05 with the new program. The copy/paste method mentioned earlier in this thread is currently the only way to accomplish this.

I hope this clears it up a little.

 

[panic mode]

Maybe a small utility that can read and write PLC data
(and save it as a file for later use) would do the trick.
Some people use Excel and DDE, other write
their own applications...

 

[kspano]

I think that the Logix only assumes that you want to use the offline file of the project with the same name if there is an offline file with the same name in the directory that YOU setup as the default directory for the software to look. In other words, don't save your projects in the xxx/projects folder that the install creates. Use Save As and put it anyplace else.