TI 575 PLC indicator lights

Hey guys, we had a VME backplane holding 6 of these 57 processors take a dump on us about a week ago. After a lot of guesswork and commonsense troubleshooting, we ended up with a now functional VME backplane and the line is running again. However, we are now looking at the one PLC module that is no longer in the rack and trying to decipher exactly what it's issue is, as well as make sure that all the spare modules we have are healthy, just in case. The module in question when installed in a rack all by itself will display a red IOA light and a green PCG light. I have found in the manual that the PCG means PLC good. However, I haven't found anything on the IOA indicator. Beyond that, "new" modules that we have act the same way when installed in a spare rack that we have. I'm now unsure whether there are issues with our spare rack? Or if perhaps some of our "spare" processors have issues as well. Also to note is that when we install more than one PLC in the backplane, they seem to fault. Does anyone have any insight on how to troubleshoot these things hardware wise, or where to get some info on the status lights. I have found a 545/565/575 manual on Siemens website, but it is not very detailed about some of the indicator lights. I've never troubleshot hardware this old before, so any insight is welcome. Thanks.

Russ

Let me preface this by saying that I don't know anything about the TI 575 platform. Howerver, if the 575 does use a true VME implementation then some general rules should apply.

My guess on the 'IOA' LED is that it stands for 'I/O Access'. The plc is looking for a memory address it can't find. If you have only the plc in the rack then this is to be expected.

Think of the VME bus more as a large form factor memory bus and not so much as a communication bus. The bus specification defines both address lines and data lines as well as control lines. So every card on the bus sees all the address lines and all the data lines. This implies that if you have two cards on the bus with the same base VME address then both will attempt to respond to data access to that VME address range. This will cause a problem.

In addition, only one card on the VME bus may act as the bus system controller. The system controller handles bus arbitration as well as other bus control items. If you have two system controllers on the same bus then bus failures will result.

I suspect that these two items are what are causing your PLC faults. Both plcs are probably configured with the same base address and/or both are system controllers.

In short I don't think you can make any specific judgements about the spares based on your test set-up. Your best bet may be to test the cards individually in a working system during your next machine scheduled downtime.

Keith

Thanks

Keith,

Thanks for the input. I was aware of the system controller issue, and you're correct, that may be possible. Our task now is to create a redundant rack of proven processors in case the worst should happen. Right now management is in an uproar because this line is in a nutshell the life of this facility, and as of the moment it hinges on old processors with which only 29 NIB replacements are available. I have found repair shops who will repair these, and offer a 1 year warrantee on their work, which would just about get us through our migration to AB. However, I'm reluctant to send a processor to them until I can prove that I am sending them a truly faulty one.

What we saw was the VME backplane fault and kill all the modules in the rack except this one in question, who's only light was a green blinking PCG light. Since we weren't sure if the issue was the backplane, the module, or what, we started from scratch until we had 6 processors which indicated good status. Then downloaded our latest program versions and went on our merry way.

Several times during this process we had the module in question in and out of the rack. Every time the backplane faulted with the module in, and was fine without. However, I haven't seen this behavior in the extra backplane, which is now making me less sure that this module was the culprit and that it truly does need to be repaired. I'd surely try you suggestion, but the fact of the matter is that the line runs too often and is such a critical process that I highly doubt we'd be allowed to compromise a working system for the testing of hardware.

I am hoping that someone ese out there can shed some light on the LED's and even possibly give some pointers on how to troubleshoot hardware. I would agree with the IOA diagnoses you gave, but I am still curious what the other LED's mean and what their desired status could/should be in a new backplane.

Issues are back

Hey guys, we are having the same issues I spoke of earlier in this post only now it is on a larger scale. We are having extreme difficulty establishing a stable VME backplane with all 6 CPUs powered up and running. We do have new hardware, but the new 2105 processors we have chew up 2 slots due to a wider faceplate. Because of this, the CPU's cannot be installed in the VME backplane in consecutive slots. Should this matter? It appears to, as we have only been able to get the rack to work with 1 of these guys installed, and that is only when the new 2105 with the wide face is installed at the far rightmost slot used. We're thinking that there has got to be a way for these to work without them being installed in consecutive slots starting from the far left, but have been unable to determine how. Any input is appreciated.

A worried little worker....

Russ

Put the CPUs back where you found them!!!!

The VME back plane has a priority scheme that allows only one bus master to access the bus at a time. Only the slots where the bus masters go will be jumpered or wire wrapped to support priority arbitration. Therefore you must put the bus masters back where you found them. Some bus masters may need to be a higher priority than the rest so you should make sure these go back in the high priority slots. It is best to put the bus masters back exactly as you found them.

Yes, usually it was the left slots that had high priority.

Thanks Peter

We have made some progress. We concluded Friday that we were not going to be able to create a valid system with the new processors and the old VME backplane. We did have a newer style 16 slot VME backplane, so we opted to move to it. This backplane did have dip switches to allow for CPU's to be placed at random. The system has been stable for about 4 days, but we have called in one of the hardware developers from Siemens to take a closer look at our problems. The real fear for us has not been the idea of a failure, it has been the failure mode. It appeared as though data to and from the global addresses was not being relayed correctly, and real world I/O which was stable in a particular state appeared to be changing at random in the "A" processor. Naturally this caused the erratic and unpredictable behavior, which has us worried how to prevent this from happening again. We were lucky that the only things affected were conveyors and fans and that no oven loops or solvent pumps were triggered. I'll post more as we learn over the next couple of weeks.

Russ

Russ,
If you use PLC WorkShop for Siemens 505 from FasTrak SoftWorks, Inc. for your programming software, feel free to contact FasTrak for support on some of these questions. We know the hardware very well.

We used the 565 and started having problems with the backplane. This continued to get worse.

We fought this untill we upgraded to S7. You may just need to do some cleaning, the contacts get bad on the old systems.