TI 565 upgrade question

Hi folks, I have an older TI565 w/128k memory card, that is reaching its limits. (Everything except PLC base is 505 hardware vs 500) We have had to play with loop and SFPGM timing to prevent excessive overruns. Scan time is around 200-250msec.

Around 2 years ago we approached Siemens about upgrading, after all the migrate to S7 hype, we finally got a recommendation. Move up to the 555-1105. We then asked if our program would migrate without any changes, and could we still use our Quickbasic batching system (uses task codes to pass data to plc), we got a blank stare and a maybe answer. We emailed a copy of our program to Siemens so they could check it out for compatibility issues. Never heard anything back. Kept calling , but always got the "we're working on it" answer. I believe they just ignored us since we refused to go with S7. So we dropped the upgrade.

Now we are finding 565 parts harder to locate and we may need to expand the system sometime soon. So we are once again looking to upgrade the processor. Has anyone done something similar, where there any compatibility issues. My main concerns are with SFPGM's (we are currently running 228 of them) and the task codes.I have a copy of the 575 task codes,and they appear to be the same as the 565. I'm hoping nothing major has changed over the years.

Any and all comments will be greatly appreciated.

Ken

Ken

The upgrade to a 555 is relatively simple - I can't understand why Siemens were so reluctant to support you on this.

You mentioned you're using 505-series I/O. Does this mean RS485 RCC/RBCs or good ol' coax RF? Although you would have had this choice in a 565, the 555 can only support RS485. There is an RS485/RF modem which can be installed in the 555 base if you need to convert the incoming coax cable to something the 555 CPU can take. It has two ports: one coax; one RS485. RBC cable comes in to the coax port and you use about 5cm (couple of inches in imperial units) of twisted pair out of the RS485 to link to the CPU I/O port. Well, that's the hardware dealt with.

There are a couple of things you must check in your program. The split between retentive and non-retentive C-'s in the 555 is different from the 565. If you have specifically written your existing code to make use of these different types you may need to do a search-and-replace with appropriate numbers to ensure the functionality stays the same. For many people the split is irrelevant and their code takes care of restarts in any case. The other issue is timing, and you can only test this at recommissioning. The 555 is a very much faster CPU than the 565, but it does only have the one microprocessor. The 560/565 pair were slower, but were genuinely dual-processor (As an aside I do remember seeing a 560/565 Hot Backup system: two chassis each with a 560 logic card, a 565 SF card, 4 Remote Channel Controllers and a Hot Backup Processor card. Every one had its own microprocessor which meant fourteen Motorola 68000s all churning away together!!) If your scan time is up about 200-250mS I would expect the 555 will beat that comfortably, but whether that fits in with the way you've constructed your code only you can tell. You may find little bits of interlocking between SF and RLL need to be reviewed or changed entirely. The 555 could be too fast!

In terms of the Comms Task Codes for the 500/505-series I don't believe they've been changed in years. They will have been updated and expanded to accommodate the new functions that a 555 has that a 566 never knew about, but all that means is that a bunch of previously 'reserved' task codes will now have tasks assigned to them. The existing ones will not have been changed. Reading or writing V-memory for example has used the same task code since the days of the 520/530.

Go for it. Once you've got a 555, you can start thinking about new I/O structures using Profibus devices. The world's your oyster! Who knows, Siemens might even want to sell you some Profibus I/O.

Regards

Ken. (The other Ken M)

For spare parts you may want to checkout: www.plccenter.com

Thanks for the response Ken M

Your answer kind of fell in line with what I expected to hear. But was looking for some re-enforcement before I took the plunge. This 565 system was installed near the end of the 565 life cycle, so we have the RS485 RBC's . The retentive C's are not an issue. We already utilize a start up procedure that handles that. There has been some discussion about migrating this system to ControlLogix, but for process control the TI 505 cannot be beat. If I upgrade the CPU, I should be able to extend the life of the system by several years.


BTW
The 565 is almost never shut down intentionally, and we routinely hotswap I/O cards, I know you're not supposed to do that, but we would rather fry a card than shut down the process.
Anyone else hotswap 505 cards.

Ken Moore,

If you plan to go with the 555, I strongly recommend that you go for the 555-1106... not the -1105. This will also required TiSoft 7.2 (I'm pretty sure it's 7.2... I know it's not 7.1). Or the comparable SoftShop.

Along with providing more memory, and running faster, the -1106 allows SFPMs to be compiled into the ladder code... not simply on the side to be called by the ladder code... but rather, actually compiled into the ladder code. You can decide, for each SFPM, whether or not you want the SFPM compiled into ladder. Those SFPM's that are compiled into ladder will run 100's of times faster... literally! And they will not be executed on a time-slice basis. They will be executed in the same manner as a Sub-Routine. That is, the entire SFPM is completed before the scan moves to the next ladder rung.

The idea of having so many SFPMs and such a long scan time is bothersome to me. One of the main things to remember about normal SFPM's is that they are executed on a time-slice basis. The same is true for LOOPS.

Are the SFPMs providing your primary controls? If so, do you have a whole bunch of SFPM Data-Status flags in your ladder? That is, while a SFPM is executing do you prevent your code from using results that have not been completed?

For example, once you call a SFPM, if the results of that SFPM are going to be used in other parts of your program, the first line of your SFPM should SET a bit that indicates that those results are in the process of being changed and should not be used yet. Then, the last line of the SFPM should RST that bit to indicate that the results are now valid and OK to use. As long as the SFPM is executing, the results are not valid. The results are valid ONLY after the SFPM is completed and until the next time the SFPM is called.

Another thing you might look at is using "SKIP" to jump over those sections of code that are not being used at the moment. For example, If one part of your process is waiting for material from the previous section, then you should be able to SKIP all of the code for the idle section until the idle section needs to respond to incoming material.

The "SKIP" function simply does that... it skips to a LABEL. All of the code in between the SKIP and LABEL is simply not processed... the outputs remain in their last states. So that means you need to ensure that the section of code is in a good "wait state" before skipping.

If you look carefully at your process you might find that a great deal of code is executing un-necessarily. Careful use of SKIP can reduce your over-all scan-time dramatically.

Terry,

A lot (over 100) of the SFPGM's are alarm print functions, they only run when a particular alarm is active and print a message to a line printer. All these alarm SFPGM's go to the "normal" queue. Roughly 50% of the remaining ones are used for special loop controls, or routines to extract or compact bits to words, depending on which recipe is being run, they go to the priority queue.
Remaining SFPGM's are scaling functions or called by Loops, and are cyclic.

There is a LOT of analog I/O, and the process runs okay with the slow scan time. It used to be roughly 30% slower. Over the years many chemical engineers have tweaked the programming, some better than others. I've had ownership of it for only the last 3-4 years, and have put a lot of effort into getting it where it's at now. Before I got assigned to this unit , almost all the SFPGM's and Loops ran on the exact same time schedule. It was the first thing I changed. There is a rather large portion of code that was used to control something that no longer exists. I cannot get permission to remove it, so I use the Skip and label function to not execute it already.

This system has been expanded, and expanded and expanded, without anyone every considering if the processor could handle it. The attitude has been, we have room for physical I/O, so the processor can handle it right?

I've already decided to go with the 1106, the 1105 doesn't have very much more memory than the existing system. In the overall scope of the project, the price difference of the two processors is insignificant.

thanks for the reply,
Ken

Hi Ken

On the subject of scheduling SFPGMs, there is one other subtlety in changing between the 565 and 555.

In the 565 you had 3 queues for executing the SFPGMs - 'Normal', 'Priority', and 'Cyclic'. A lot of pople (though you sound too experienced for this) used to think there was something magic about the Priority queue and I've seen 565s where every SFPGM was assigned to be 'Priority'. Of course this meant that CPU bandwidth for handling 'Normal' programs was just going to waste. You could get SFPGM overruns which could be cured by deselcting some SFPGMs to be 'Normal'. Basically the 565 allocated twice as much processing time each scan to serving Priority tasks as it did to Normal tasks. Of course, if everything was Priority, then in reality nothing had priority - they were all the same. You had to get the balance right. And this 2:1 ratio was fixed.

In the 555 you have tremendous flexibility over the allocation of time to tasks. You can specify how many mS the CPU will allocate as maximum each scan to Normal, Priority, Cyclic, Loops, Analog Alarms, Ladder SF Subroutines, Comms etc. You also get a bucket more information in terms of the peak processing time for each of these: there a whole host of new variables you can monitor called xPET (Peak Execution Time) where x = L for Loop, S for SFPGM, A for Analog Alarm. So you can check, say, SPET23 to see the peak execution time for SFPGM23, or LPET55 for loop number 55. Using all of this stuff you can really tune the system performance.

But then again, if it (the process) works OK slow ...? The main thing here is that you have the choice. Have many happy hours tinkering!

Ken

Ken M,

Yes I am aware of the different queues in the 565, I learned the hard way.

In the 565 if you have a print function in the queue and the printer is off line, the entire queue comes to a halt, no more SFPGM's are processed in that queue (once it fills up). Is this true for the 555 also?

I had to check printer status before doing any print functions:

Ken

I've never used 555 PRINT functions with anything other than Hyperterm as the receiver, and even that was only for a relatively short period of time. I would assume that it does operate like a 565. In other words it does its damnedest to print that message and sticks at the task until the job's done. Except, of course, it gets nothing to tell it the job's done, so it sticks at it, and so on ... You really can't blame the little guy for trying that hard, can you?

Why is it the idiosyncracies of some CPUs make you feel sympathetic towards them, but other CPUs just p*** you right off? They've all got their little quirks and differences, but for some reason you put up with one lot and hate the others. I had a colleague once who always referred to the all the TI PM550s he used as 'she', like they were ships or something with personalities of their own. He would talk about going off to tweak one of 'her' loops, or to add a few rungs of ladder to 'her'. Strange people, these engineers!!

Ken.

One of the Kens said,

"In the 565 if you have a print function in the queue and the printer is off line, the entire queue comes to a halt, no more SFPGM's are processed in that queue (once it fills up). Is this true for the 555 also?

I had to check printer status before doing any print functions:"

Yes. This is also true for the 555. Since Special Function Programs (SFPMs) are "queued", I would not expect anything different.

In the 555-1106, with PowerMath, most SFPMs and subroutines can be compiled. However, an SFPM, or subroutine, which contains any of the following instructions, cannot be compiled:

• The data compacting instructions: PACK, PACKLOOP, PACKRS, and PACKAA
• The shift register instructions: SSR, FTSR–IN and FTSR–OUT
• The PRINT instruction
• The BCD instructions: BCDBIN and BINBCD

So you'll have to continue using your PRINT and PACK programs as you currently do.

While your SFPM checks to see that the Printer is OK before you execute the Print program (which is entirely reasonable), it does not continue to monitor the printer while executing the Print Program. Printers can just as easily go haywire in the middle of a print. That particular nut is only slightly tougher to crack.

Whenever you are doing a Print, you will get a Communication Error if a character remains in the queue for more than 30 seconds (see note on Table STW-162). It's not the fastest error reporting, but it is better than not reporting the error at all. This might seem like an excessively long time however, not all printers are created the same... some printers take quite a bit of time to execute a form feed. It would have been nice to be able to adjust the time for that particular error.

I suggest that you create and run a Printer Monitor SFPM on a Cyclic basis... every 4 or 5 seconds, or so.
This SFPM should continuously check bit-1 of STW-162. If bit-1 comes ON then the Print Monitor program can write a code to the SFEC (see "Reporting Errors with the SFEC Variable") for the current Print Program. You can force the Print Program to terminate. At the same time, you can set a bit that indicates to the Ladder that you have a printer problem.

Your Print Monitor program should be able to keep track of all currently queued Print programs. Knowing that there is a printer problem, you can force all of the currently queued Print Programs to terminate. Or you can let them self-terminate as they make their way through the queue, as your Print programs are currently designed.

Once you know that you have a printer problem, you can prevent subsequent Print programs from being queued until such time that the printer is repaired. Meanwhile, turn on an alarm that calls someone to fix the printer.

I assume that you are driving the printer from a PC... if so, why not print your alarms to a file and then have the PC manage the printing... in that way, you should still be able to record all of the alarms even if the printer stalls.

Or, since there are, at least, two print-channels available, you might be able to get away with printing directly to the printer AND to a file. If the printer faults then discontinue sending to the printer but continue sending to the file.

I already have a seperate SFPGM monitoring the printer, and sounds an audible/visual alarm on the control panel to inform the operators they have a problem. I use the "normal" queue is for printing only, so if there is a problem, the only thing that stops, is alarm printing.
The process keeps chuggging along.

I assume that you are driving the printer from a PC... if so, why not print your alarms to a file and then have the PC manage the printing... in that way, you should still be able to record all of the alarms even if the printer stalls.

Click to expand...

The PLC prints directly to the line printer, no PC involved. I once tried replacing the printer with a serial capture program as you suggested. It worked great, played a wave file on every new event, and no more printer hassles. No more out of paper, bad ribbon etc... The operators raised HELL, most of them have been running this system for many years, and the sound of the line printer firing up was used as an alert to check the process. Mangement made me put the line printer back.
I now capture all alarm events in a SCADA system, but the operators have thier line printer.

TI555-1104 to TI555-1105

dear Ken Moore,

We have problem as follow:

first the CPU used was TI555-1104,
then we try to change with TI 555-1105

when the program is down loaded to CPU there is an error message
"Not enough memory"

after checking,
the configured program is 500 KB
USER Memory for TI555-1105 is 384 KB
On board EEPROOM TI555-1105 is also 384 KB
Portable EEPROM that can used is 256 KB (max)

is the portable EEPROM can be used to added memory capacity from
384 KB become 640 KB?=>In this case we assume that we can use the both memory in the same time.
or we can only use just one of the memory in this CPU whether 384 KB from on board memory or 256 KB from Portable EEPROM only in the certain time.

Please be so kind to help us

Will not work.
The 555-1104 has 1920 Kbytes of memory.
The 555-1105 only has 384 Kbytes.
The add on EEPROM option is for program storage only, not memory expansion.

You have 500 Kb, of configured memory, are you using it all? You may have memory configured that isn't used in the program. Either trim the program or get a different processor.

CTI has new drop in replacements, looks like you need a C300 or 400.
http://www.controltechnology.com/products/2500-processors/