1794-it8 readings inconsistant

Maybe someone else has had a similar problem.And a possible resolution.

master----panelview----remote----remote
rack1-----"""""""""----rack2-----rack3

Communications is blue hose. The problem is that there is two It8 modules in rack 2 and 1 It8 module in rack3. The module that resides in rack three gives consistant readings with the actual thermocouple readings. The modules in rack two has channels that read up to 20% high at times. But here's where I'm getting lost. If i switch modules around between all three slots the problem always resides with the modules in rack2, but the channels the problem is on changes with the modules.But when any module is in rack3 it reads consistant and accurate.

Now a little history. When the machine was new rack2 would fault every couple days. There was some disagreement as the actual problem but whenever I would dissassemble that rack and reseat all the "backplane" plugs the system would be fine for a considerable time. Dayshift was trying to tell me that the blue hose was bad(they replaced it only to get more faults on rack2) but rack 3 also used this section of it and it never had a fault. The last time I got the fault I went over every pin on the backplane connectors to ensure a reliable connection. But i'm not sure if dayshift have done anything else.

The panel that rack2 is on has a fair amount of vibration and considerable heat fluctuations(over time). Where rack3 is the temp is relativly consistant and minimal vibration. all areas are in an area with "airborne oil" (part of the process is spraying oil on a machined wheel to produce a product)

I finally talked my "superiors" to get me a new module (I wanted 2 but......)Now that its installed in rack2 I still have the same problem (and feel like a shmuck).

Starting to wonder if i'm going nuts...
Then again I think we are all nuts just some of us have been caught!!!
But i'm feeling much better now!!!!!!



Thanks
Drewcrew6

I actually had the same problem with an slc remote I/O rack.I changed cards several times to no avail,this was also in an area with a lot of vibration.In the end up i replaced the rack itself and this cured the problem.

Just to check the obvious -

Are you sure that the outputs to the modules in rack 2 (e.g., the configuration) are the same as for rack 3?

And that there's no code that is changing those outputs (check cross-reference, and indirect addresses) so that the logic would change its configuration, and thus it's scaling?

Did you swap out the Terminal Block base, or just the module? (If just the module, you should have done that before asking for a new one - lesson learned.)

I've searched for anything that would change the configuration, and have not been able to locate anything, although I need to dig deeper in to the program for some other issues. I have not changed the bases around, was hoping to not have to mess with them given the problem when the machine was new. But I guess thats what my next move is , unfortunatly we don't have new ones of them so all I can do is swap modules around.

The biggest problem is that when the rack faults it shuts the machine down and production is down about 2-3 hours till everything is cleaned and set back up. So I can only work on the machine when its not in production, and I'm not swamped with breakdowns (the two don't usually happen at the same time).


On my first chance I will try swapping bases around and see what happens.


Thanks
Drewcrew6

I think you already know this, Drew, but be sure to pay attention to the fact that the terminal base for the 1794-IT8 is different from any other FLEX module.

This is because of the nature of a Thermocouple device, which relies upon dissimilar metal junctions to generate tiny voltages relative to temperature. The 1794-TB3T base has special terminals for hookup of "Cold Junction Compensator" devices, which are very precise RTDs that give you a base temperature to compare the thermocouple signal to. If the CJCs are bad, missing, or miswired, you'll get inaccurate readings from the 1794-IT8 module.

That won't explain RIO network faults, though.

Thermocouple modules need to be carefully wired; you can get induced noise easily with grounded thermocouples if they are installed on different ground-potential machine elements. You also need to have a separate 24VDC supply for the analog modules, often totally separate for the thermocouple module alone.

See if you can write a logic trap to compare the number of completed block transfers to the number of faulted ones to the thermocouple modules in Rack 02. This might indicate whether you have a constant low-level noise problem or an intermittent problem.

If we are talking about FLEX I/O then I have had the same problem. It has been my experience, that a bad flex I/O card in a rack will cause another flex I/O card in the same rack to appear bad.

I noticed that when you put the non working card in another rack, that it worked fine. And when you placed a working card in rack two, it stopped working. The problem didn't follow the card, but remained with the rack.

Verdict: Another card in that rack is causing the problem.

Solution: Replace all the cards in rack 2 (easiest). Take each card from rack 2 1 at a time and place it in another rack to see which card from rack 2 will cause a problem in another rack.

Ken

I'm not 100% shure but if I recall correctly I saw a block transfer counter already in the program and didn't see anything abnormal. But a double check never hurt!!! I will double check the terminal bases. I wasn't sure how the bases dealt with thermocouple connections but it makes sense that its a special t.b.
Now that I've had time to reflect on what I did I was starting to think that maybe its the same tb's as other i/o and the cjc's took care of inaccurasies (?) dew to disssimiliar metals .

SIDETRACK- how do the bases and any t/c cards term strip account for dissimilar metals when the t/c type changes
I.E. type j-iron/constantan type k-chromel/alumel
Is that what the cjc's do? Or do they adjust for temperature at the tb?

ONWARD



ganutenator
That makes sense to what I've seen so far also. I will give that a look and try some swapping of the discrete i/o.


When I get back to work and get a chance to at least check some things out I will post where I stand with this.




Thanks
Drewcrew6

SIDETRACK: (by no means comprehensive or perfect)

Because the voltage/temperature relationship for thermocouples is a highly nonlinear function, measurement devices use "normalization tables" that are defined (in the USA) by the National Institute for Standards and Testing (NIST).

Because the module designers know what offset is introduced by the terminal block itself for each type of thermocouple wire, those effects can be accounted for in the particular thermocouple type's V/T function. That's why you have to select a Type of thermocouple when you set up the module, so it knows which table to use.

A thermocouple must have a known temperature for one of the junctions to be useful in measurement. Back in college, it was an icewater bath.
As I can never remember to add ice to the beaker in the mornings, we instead use a high-precision sensor to detect the temperature at the terminal base. That's the Cold Junction Compensator, which is just a precision thermistor.

If you don't have a 1794-TB3T terminal base, or the CJC's are miswired or missing, you will definitely not get accurate thermocouple readings.

OK

Here's where things are at. The equip. manu came in and was stumped he tried all kinds of (in my opinion) stupid things. and he managed to make things worse now the temp readings are very inconsistant ( bouncing 50 degrees or more) as the panelview updates. Right now all I can do is watch what he gets done on dayshift (not allowed to touch machine). I was informed that they fixed the problem today and now the temps only bounce about 20 degrees ( they found duct tape covering the tc wires on one of them-a little far fetched I think)
I did check to verify the correct bases. Which brought up a question.

(I am told he made some prog changes but since I can't work on the problem I have to wait to see what he did.)

In rack 2 with the 2 tc modules and where the problem is the worst. they used exclusively tb3t modules even on the discrete i/o ( there are 3 discrete modules and 2 tc modules). In rack 3 they have 2 tb3t bases and one tb3 bases. Analog and tc modules use the tb3t bases and discrete on the tb3 base.

Is that creating the problem in rack 2 by using the tb3t bases on discrete?

update to problem

I know its been a while but the problem came up again today and now the factory tech is gone so i have another shot at this.

Could not locate anything in program that is overwriting the channel configuration or writing bogus numbers into the input scheme. I took a handheld tc probe and tied it in parallel with every tc on the rack and they all read nice and stable, but I'm not sure if it responds as quick as the plc.
I checked the shlds on the tc wires and found there was considerable resistance to ground so i ran a ground wire to that point on each base. The temps settled down a little (instead of bouncing 20% they only bounce about 15%) still out of acceptable range. Started again with the fluke vom and found that the 24vdc flex power supply negative was Floating around and not tied to ground so I tried grounding at that point also.
As soon as i installed that ground the all the temps stabilized and has been running with no problem. Does anyone know of a reason that the flex logic power supply should not be grounded.


Thanks
Drewcrew6