Hello.

For analog inputs see attached. Was that what you are thinking of?

Cheers

Hi #dP,

Thank you!  Not exactly.  Someone had suggested to me that the S7-1200 AI/AO modules use the raw count to convey specific "error codes" (each error code would correspond to a different error that could be looked up in a table somewhere in Siemens documentation).  I have not been able to find any such S7-1200 AI/AO error code table.  

I suspect that it may not work this way, but rather diagnostics is done via OB82 or Get_Diag, but I wanted to throw it out there all all the Siemens experts on the form to confirm.

Cheers,

Zach

See what you can extract from:

https://support.industry.siemens.com/cs/document/42320122/

https://support.industry.siemens.com/cs/document/109483251/

Hi dP#,

Thanks again.  Very helpful stuff.  I don't see any reference to an "error code" being conveyed in the raw AI or AO counts themselves in these documents.  The documents in both links reference using OB82 and other OBs which is how have coded it to work in the past.

It's not an absolute refutation of the idea that the raw count is used to convey an "error code",  but then it's hard to prove a negative unless some with deep experience wants to come on here and unequivocally say "it definitely doesn't work that way".  

Cheers,

Zach

You have to define what you mean by "raw count". From a regular user program the input defined in the hardware configuration (analog input) is the filtered but unrefined / raw. The INT read from the %IWxxx does give you some hints as having issues. The analog output has only an output and no direct feedback.

That is different when you move away from the S7-1200 to for example distributed IO. There you have diagnostic information that can be selected to be feed back as secondary input fields.

The diagnostics for the S7-1200 analogs are limited and need to be read indirectly. The linked examples give more.

Are you sure you were not thinking about S7-1500 or ET200 type solutions?

- Dan

zstephens_aka

Hi dP#,

Thanks again.  Very helpful stuff.  I don't see any reference to an "error code" being conveyed in the raw AI or AO counts themselves in these documents.  The documents in both links reference using OB82 and other OBs which is how have coded it to work in the past.

It's not an absolute refutation of the idea that the raw count is used to convey an "error code",  but then it's hard to prove a negative unless some with deep experience wants to come on here and unequivocally say "it definitely doesn't work that way".  

Cheers,

Zach

Thanks so much for your help Dan!

Hello Zach;

An old trick for current AI channels is to set them for 4-20 mA.

When the module detects any valid signal it will show the correspondent engineering value set in the Scaling blocks.

However, any value of 0 MA will indicate a cut or disconnected wire, or a loss of power to the sensor.

In a way, you could say the channel carries an inherently error code inside the raw data... Not as specific as you might have wanted. But old tricks sometimes can help you out.

Hope this helps, 

Daniel Chartier 

zstephens_aka

A colleague told me those values are used to not only represent the input/output voltage/current, but also in case of error switch from doing that to showing an "error code" which can be then looked up in a table of error codes.  

There is nothing beyond anything that you saw on my first attachment. Even that is helpful in diagnostic analysis. As for the other (Siemens) cases - even there the diagnostics do not interfere with the raw signal. The diagnostic codes are on another "channel".

I think you realise that you need no forum expert to contradict me. The Support Request is open to your question if you wish later to take it further.

Perhaps ask your colleague again on this. Perhaps there was a library code block that did this or something like that. With all the PLC brands and different applications, it is hard to keep track of all the different ways engineers solve problems. - - This topic has peeked my interest, please let me know if you know more.

Regards.

Hi again Dan,

Thanks again for the helpful responses.  I will discuss again with my colleague and update this thread.

Cheers,

Zach