Calibration of analog inputs and outputs for TM172

[otrotabi]

There are two different folders available in Ecostruxure Commissioning Tab where each analog input and output has an associated "Gain" and "Offset". They are refered to in the hardware manual but there are no examples on how to use them. I would like to know what they mean, and how to eventually use them.

Are they "hardware" related in terms of each particular device (factory calibrated and do not touch them) or is it possible to change them to have a better reading of a value ?

One typical problem we face is calibration of NTC probes, sometimes they are placed inside a tube (for example to measure water temperature) for the sensor protection.  What we usually do is assign an EEPROM variable which can be accesed in HMI to allow the user or maintenance people to adjust them.

[Bastian_Schmitz · Accepted solution]

The values in the calibrate AI/AO folder are factory seetings for the raw values of the AI/AO.

They are adjustable in a special way. But normaly they should not be edited. 

Because if you change them you change the calibrated factory setting and you must know what you do. 

The values are based on raw values and regding to this they are not easy to handle.

From the last 5 years I know only one case with AO as 4..20mA were we need to touch this value.

In your case with the probe you could use directly calibration_AIx which is scaled to the measured value of the Input. 

These values are all retain and could directly used. 

[otrotabi]

Thanks but I do not understand completely. Except that I´d better not mess with them 🙂

I am used to using a Function block to add/subtract an offset from the value read by the PLC. It also warns me if the reading of the sensor is out of bounds. 

I understand I might use Calibration_AIx eventually instead of defining another variable (rcfg_offset) for this. Is there any built-in variable I could access to know if there´s no sensor connected ?

[Bastian_Schmitz]

If you work with REAL values, they way you have chossen is suitable in my opinion. If you want to check the analog Signal regarding to sensor failure (disconnect/shortcut) you can look on the value.

If the AI value changed to -32765 you have a misconfiguration (The AI pair is not configured proper)

If the AI value changed to -32768 you have a sensor failure (shortcut or disconnect)

These values should work in the most possible sensor configuration. But if you work with 0-5V or 0-10V you could not analyse a disconnected sensor.

[otrotabi]

As a side question, if you don´t mind @Bastian_Schmitz .

Is it better to work with INT Values instead of REAL values ? I know it takes less PLC resources (no int to real conversion are needed and less variables as well). But I find it easier to troubleshoot projects if I am reading actual values instead of INT values either in watch screen or the program debugging. 

I have not been faced with PLC limits when using TM172 but I do get warnings of "less than 10% of resources available" on the TM171 line, so I wander what is the way to go with this.

[otrotabi]

Ok. I have convinced myself INT variables is the way to go.  I do not like having to do this everywhwere if I can help it.

Let me rephrase my question. Are local variables a PLC overload ? Or they just live on Ecostruxure ? I still might include something like this when I want to have a quicker way to see real values while debugging

[Bastian_Schmitz]

I think you can´t find a general answer if it is better to use INT or REAL. 

It would be depend on you application and you hardware.

If you use TM172 you can always use REAL because normaly you get no problems with memory on this hardware.

If you work with TM171O (like you explained) you could get the problem that the memory is not sufficated.

In that case it could make sense to work with 16Bit INT instead of 32Bit REAL to save memory.

On TM172 if you use REAL instead INT you could theretically the problem if you want exchange data per Modbus that the other controller need to rebuilt the REAL value. Because Modbus support only 16Bit values. Between two SE products this should no problem. But if you read out the value with a third party product you could face the issue that the Byte and/or Word order is different. In that case you will get less problems with a 16Bit value.

Regarding to the application i prefer to work mostly with 16Bit (UINT/INT) but if you want calculate something with a division or multiplikation it would make always sense to use a REAL value. Otherwise you result will get really unprecise.

But if you have the result you could convert it back to INT/UINT with one or two points after the comma. 

The main point to use REAL is that the integrated PID FB need real. I use mostly a FC in front of the inputs which convert a INT Value to Real/10.0.