AB past issue

[panic mode]

Hi Tom,

I think you misunderstood what I meant. I am aware of
touchscreen functionality as I buy, install and program
about 30 of them every year. I am also aware of shortcoming
of different products including RSLogix5000 (which I use
regularily).

Although many people do not use protection for parameters,
I put it in all the times because machine settings and
recipes could create disastrous results if used without caution.
It is up to customer to choose to use it or keep the
passwords blank, I don't care. I don't want any liability in case
something does happen.

This means that settings for my recipes still can be changed
from the HMI but only by authorized personel (supervizor,
production leader, maintenance...) instead of by every person
on the shop flor.

Everyone can SEE(!) all settings but passwords are required
to make changes. Each change is logged including time, date and
user name so we can trace back all affected products instead
of recalling every piece that went through machine.
Password might be required even to SELECT different recipe
depending how sensitive process is (or how bad operators are)

...and yes, it can be used to disciplin culprit when required

 

[Tim]

Yes, the operators will be changing various data with the HMI. Its their responsibilty to have everything configured and recorded for each die. This press has the capability to roll the die in and set up everything automatically by using the previously recorded data. The data bank is password protected, BUT the operators, or teamleaders are the ones who will be adjusting it.

operaghost,
I understand what your talking about. I pretty much understood most of it before this problem occured. The original problem was that my offline file didn't match the one in the controller. If you look at the link for the original thread, I tried to do an upload and half way through the upload process I would get an error. I have two controllers on this chassis and this one was the only one that was giving me any troubles. I contacted AB and they had me do a few things, but still no UPLOAD. The final solution from them was for me to do a download and I wasn't about to do that because I had no idea how current the file was. THANK GOD I didn't because I had no idea it would wipe out or change some of the data.

I called the manufacturer in and he tried a few things and in the end he decided to try a download. After the download, he was able to go online, but he had to go through and re-record all the data that we had stored for each die. Thankfully we had all of it written down.
I was puzzled by why the data got lost, but now I understand that download puts the data back to the last successfull upload, which would have been no die recorded because this press is brand new.

At first I thought,"how weird is that", then I realized after help from you guys that this was a good way for me to have a backup of all the data. PRETTY COOL!!! I thought he was making it sound like if one of the tag values got changed I couldn't go online anymore because the file didn't match, but now with your help I know this is not true.

Now, I still don't know why I was getting the error before, but now I'm able to go online. His solution to the error was for me to regularly do an upload, so if the error came back again, I would have the most recent data saved. Last thing is does anyone know which manual clearly states the functions of download,upload and what happens to the programs and data when this is done. I would like to have it for reference.
Thanks for all your help!!
Tim

 

[panic mode]

Tim,

just another tought...
could it be that the affected controller is using most of the
memory? i've seen some weired stuff when all is left is ca 2-3k.

 

[Tim]

panic,
I'll check and see how much is left. Might be a while though because I'm on another project.
Tim

 

[Eric Nelson]

The fundamental problem is that with RSLogix you cannot separate data files from logic, and you cannot download logic without over writing the data files. This is a major shortcoming in RSLogix.

I hear ya, Tom! Your copy and paste method is about as close as you can get to keeping the data files 'current'. The problem is the time it takes to get from your step 2 to step 7. If the machine is running (as is usually the case), the data tables can be different (parts counters, etc.)...

If life were only as simple as this icon:
[attachment]

beerchug

-Eric

 

[PhilipW]

Tom The problem you are having is that you arrogantly assuming that ControlLogix is written just to suit your way of thinking.

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.

What is more you are free to online edit in new data and/or logic up to the free memory limit. If you think about this for a minute you will see that this pretty much rules out any easy way to do partial downloads, unless you are going to accept other limitations.

In order to deliver partial downloads, on line edits of UDT structures and other online manouveurs that demand complex shuffling of memory WHILE the CLX processor is still running a process, Rockwell are working to deliver in V13 a powerful transaction editor mechanism in the firmware that will allow the processor to safely apply unlimited changes to the memory structure, (AND back out if an error occurs!!!) I am told that this has been a non-trivial exercise.

On the basis of this functionality a number of features like partial downloads will be added with time.

Rockwell, ARE YOU LISTENG? THIS IS STUPID!!! FIX YOUR SOFTWARE!!!!!

I tell you what Tom. If you think you are good enough to write and validate the firmware needed for a system as complex and powerful as ControlLogix, then get your CV to Ron Bliss who runs the Rockwell engineering team writing this "STUPID" software. I know he will be interested.

On the other hand if you are really grizzling about the limitations of the SLC500 system that was first lanched in 1990, may I suggest a technology update?

 

[Tom Jenkins]

You know, Phillip, you may be taking this a little too personally.

First, I made it clear that I WAS talking about RSLogix 500, which encompasses programming the SLC and several models of MicroLogix. I know very little about the ControlLogix platform, and I didn't comment on that platform or the different software required.

Second, I used to be a big A-B fan, in the old days when the Bradley family still owned the company and they worked very hard to justify higher prices with better quality and superior service. I sincerely regret the period of time when Rockwell lost that, and I am very happy to state (again) that in the last 12 to 18 months the trend has been reversed.

Third, honest criticism based on fact is not "bashing" in my opinion. It is only through feed back from end users that manufacturers learn how to improve their products and services. I have had conversations on this and similar areas with both my local distributor and Allen Bradley factory representatives, and I think they consider this kind of feedback helpful.

Fourth, I refuse to believe that the vast resources of Rockwell Software cannot find a reasonable solution to this problem. I understand that the SLC platform has the ability to allocate memory to logic or data. I also know my old Apple II could identify the memory boundaries and the amount and location of the memory used. I find it hard to believe that RSLogix 500 can't emulate this accomplishment. I also find it hard to believe that if all else fails the software gurus couldn't emulate in software the "kludge" cut and paste that I and others use.

Fifth, I am not a programmer, and I do not claim to be a programmer, and I do not have to be a programmer. I am an end user, a customer if you will, and my knowledge about what I need is superior to Allen Bradley's knowledge about what I need. Their knowledge about operating systems and Windows programming environments is superior to mine. Both of these facts are as they should be.

In my opinion the fundamental problem is that the software guys don't spend as much time in contact with customers as the hardware guys. That means they are not as aware of customer needs and requirements as they should be, and the software guys are not as active in returning the company to its attitude of superior service to the customer as the hardware guys.

Allen Bradley has made visible advances in recent months in returning to the kind of organization they built their enviable reputation on. If they continue to listen to end users such as myself they will continue to improve. If they indulge in self congratulatory intellectual incest they will resume the downward spiral and doom this fine company to oblivion.

 

[Doug-P]

In order to deliver partial downloads, on line edits of UDT structures and other online manouveurs that demand complex shuffling of memory WHILE the CLX processor is still running a process, Rockwell are working to deliver in V13 a powerful transaction editor mechanism in the firmware that will allow the processor to safely apply unlimited changes to the memory structure, (AND back out if an error occurs!!!) I am told that this has been a non-trivial exercise.

I don't have a dog in this but, here goes.

I find it curious that the PLC-3 did have good things like (automatic) Run mode memory creation and, at least with the AI software, selective downloads of memory sections/DTs. I don't understand why such useful things were done away with.

 

[PhilipW]

Tom...in a less grumpy frame of mind I will attempt to respond to the points made above:

1. The PLC 3 was AB's flagship processor of the 80's. The first classic PLC 5/15,25's were intended to slot into the market under the PLC3 and as a replacement to the Mini PLC2/16's and the like.

As such the PLC5 family deliberately had fewer features than the PLC 3.

2. By the late 80's it was clear from the succcess of the PLC5's that this had been the right product and the days of the PLC 3 were numbered. Also there was a need to address the competitive issue with low cost Japanese vendors. As a result AB launched two new families, the PLC 5/250 and the SLC 500. The 5/250 was meant as a replacement for the PLC 3, and to address the new market driver for HMI's.

3. At that time AB (primarily a hardware company) was VERY unconvinced that HMI software like Wonderware running on Windows 3.1 was a valid path forward. The 5/250 as a platform was strongly integrated with the Information Processor running VMS, and as a concept had some merit. But as time progressed and PC based HMI's gained some stability, the 5/250 proved to be a false start and was pulled back from. Lessons learnt from this were applied to the ControlLogix design.

4. By contrast the SLC500 was a runaway success, and what was intended to be a fairly limited low end offering has been greatly enhanced over the years. However it always came with some limitations as a result of it's original intended scope.

5. The biggest of these is that whereas the PLC 5 family was essentially an interpreted code machine, the SLC 500 is a complied code machine. ie On the PLC 5 you download ladder code and the firmware interpets it, on the SLC, RSLogix compiles the ladder and downloads processor code.

6. This meant for example that the processor could not accept online edits to enlarge data tables, because the processor FIRMWARE never had it within it's scope the ability to online compile the changes. Remember that when you are editing online it is the PROCESSOR that is doing the editing, RSLogix is merely acting as a front-end. Therefore you cannot do anything online that the processor firmware cannot cope with. And the ability to fully recompile ALL of its memory, logic and data, AND keep running the process just wasn't possible.

7. The problem of downloads overwriting data table is easy to underestimate. You tend to think just in terms of how annoying it is that a minor logic edit in an unrelated file has the consequence of overwriting data in a totally different file. But look at it this way, unless you specify beforehand that a specific file is defined as static, how can BOTH RSLogix AND the processor both know to protect that data from being recompiled before a download?

8. Grumbling that making a data file static and therefore protected from being overwritten by RSLogix AND then being unhappy that RSLogix cannot edit it doesn't make a lot of sense to me.

9. Tom. You ask why the software gurus could not emulate your "cut and paste" kludge? Again you aren't thinking through what you are asking for. What if the data you want to protect is changing rapidly? What if you have done an offline edit that completely changes the properties of that data file. Offline editing doesn;t have ANY restrictions. An offine RSLogix doesn;t know that you have a working version of the program running in a processor that you want to do a download to later on. Offline you can change the logic AND data files to your hearts content....and then you expect the processor firmware to protect the data files, WHILE accepting ALL the new changes you could possibly have made offline. Nothing is impossible, but it is a big ask really.

10. Yes other vendors went down the path of having separate logic and data memories. It made partial downloads easier, but came at the cost of other inflexibilities.

 

[Eric Nelson]

What if you have done an offline edit that completely changes the properties of that data file.

Thank you, Philip. That one sentence finally allowed me to understand why the data tables must be overwritten each time... :nodi:

I keep forgetting that the data tables sizes are variable. If you change the SIZE of the data table while off-line, then yes, that would definately require a complete download.

I think what Tom and I (and others) are looking for would be for RSLogix to compare the size of the online and offline data tables when starting a download. If they are equal (i.e. no change to the SIZES was made), then provide the ability to do a partial download WITHOUT overwriting the data table values (I think mainly the N:x values). Something similar to the "Do you want to save existing data table values?" prompt when uploading.

beerchug

-Eric

 

[Doug-P]

Ah so!

5. The biggest of these is that whereas the PLC 5 family was essentially an interpreted code machine, the SLC 500 is a complied code machine. ie On the PLC 5 you download ladder code and the firmware interpets it, on the SLC, RSLogix compiles the ladder and downloads processor code.

That explains a lot. Thanks!

 

[Allen Nelson]

What I mean by Partial Download

I'm not so concerned about being able to do a pertial download on the fly. I can readily accept the SLC's limitations of not being able to change a data table's properties while the process is still running.

I understand that it can't be done while the SLC is running. That's OK. When I choose the "Download" option on a SLC, I understand that the process will stop. It always has. If I need the process to keep going, I go online and use online editing. It's not fun, sometimes, making major changes, but it's a price that I'm willing to pay.

But a price that I don't like paying is loosing data table information when I only have ladder logic changes to make.

What I'm looking for is something along these lines:

In RSLOGIX, select various Program and Data files to download.

RSLogix then UPLOADs the current program from the SLC, replaces the existing program/data files with those that I have selected, compiles, and does a FULL download of all of this to the SLC.

Are there potential problems with this? Certainly. The old program in the SLC is now gone, with no record, and new program in the SLC does not match the file that I have on disk. If I accidentally connected to the wrong SLC, the results can be disasterous.

But I can do this in RSLogix5. Why not RSLogix500?

The thing is, using RSLogix500 Pro, I can almost do this NOW. It's just a matter of having a macro export the current program to a .SLC file, do the upload, export THAT to a second .SLC file, parse the two files to merge the selected data into a third .SLC file, import that one, and download the PLC.

The only hard part is the file parsing. That's pushing my skills to their limit, but shouldn't be that hard for true programmers that Rockwell has.


I also don't see what's so terribly hard about doing a partial data download even while running. Again, I'm willing to live with the SLC's inability to change data table sizes. But how is it all that different than when I have an offline copy of RSLogix, select a range of data, Ctrl+C copy, open the same data table online, and Ctrl+V paste?

Again, I understand the limitation: If I've made a mistake, there's no going back. The old data is gone. And I woould fully expect to be prompted by annoying "Are you SURE?" dialog boxes, just like those when testing and compiling online edits.

But they're still features I'd like to have.

 

[Tom Jenkins]

One last fact, and then I promise I'll shut up. The Modicon Concept software also compiles the program, and allows on line editing, and although it doesn't have a file structure liek the SLC I believe it does vary memory allocation between variable and logic memory, and it allows logic downloads without data downloads.

It isn't impossible, and I think it should be done. Let's face it - the SLC platform will be around for a long time and a lot of PLC programmers would like this option available.

And, as truth in advertising, I should confess that I very definitely prefer RSLogix over Concept for almost everything else!

 

[jshiepe]

As with most others here, I can live with the limitation of not being able to resize SLC500 data tables online. But it would be nice to just have a "synchronize" option for data between two programs, perhaps a feature that could be added to the program comparison tool of RSLogix.

For example, in my situation stated earlier regarding replacing a 5/03 with a 5/05, with this added functionality, I should be able to follow this process for doing this upgrade:

1. Go online with the 5/03 and upload the program and save.
2. Use the "compare program" feature to open up the old 5/03 program I just uploaded and the new 5/05 program that I spent hours updating offline with new logic, etc.
3. The "compare" will obviously show me the differences between the two, but I should then be able to choose certain data tables that I would like to synchronize, and in which direction the synchronization should take place.
4. After sychronizing, save the new 5/05 program with the data from the old 5/03. Power off the machine and replace the 5/03 with the 5/05.
5. Go online and download to the 5/05 and I'm in business.

This would be such a time saver over the cut/paste option, especially when you know that you only have limited downtime with a machine.

I also agree that going online periodically and uploading and saving is very important, so much so that it is a preventative maintenance task generated by our CMMS system.

Jeff

 

[PhilipW]

I understand what you mean by a "synchronise data table" option, and like anyone who has used SLC realises, I agree it would be cool thing to have.

But I still need to ask... how synchronised? After all given the method you propose there is always a time delay between uploading the existing data table and downloading the new program.

If the data is changing rapidly due to the process (eg state and messaging data), then it is very likely that programmers would fall into the trap of THINKING their on and offline machine states were synchronised....when in fact they weren't....and then a consequent hazard that would very likely occur.

Yes it is possible to do, but it would have this inherent trap in it. 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.

The best way around this issue is to use the dynamic and/or static data file protection options. It may come with some minor niggles, but it is certainly the method I use to protect setup parameters, calibrations, accumulators and the like.