CPU 1512SP - wire-break diagnostics with RALRM instruction

Dear All,

I want to control wire break for module AI 4xRTD/TC 2-/3-/4-wire HF (6ES7134-6JD00-0CA1). I use RALRM for channel diagnostics. When the system is on (during run-time), then RALRM allows to catch wire break and wire restore events correctly. But if the wire is already broken by the moment of power-up then RALRM doesn't allow to recognize it. So, RALRM can catch the wire break/restore event, but not the state (broken/unbroken).

Could you please recommend a right approach to wire-break diagnostics, that allows to recognize correctly if the wire is broken or not during power-up and runtime as well.

Thank you.

Can't you simply read the raw value and compare against the values associated with wire break?

Check the documentation for that specific module to see the raw values presented when a wire breaks.

In my experience, it is very easy to tell when a TC or RTD is not plugged in or wire is damaged.

It is suddenly well outside the range of the device.

You can use an OUT_RANGE to generate the wire break alarm within normal scanning logic, and IN_RANGE to edit check the value before using it (for PIDs or display purposes).

_Pavel_

Dear All,

I want to control wire break for module AI 4xRTD/TC 2-/3-/4-wire HF (6ES7134-6JD00-0CA1). I use RALRM for channel diagnostics. When the system is on (during run-time), then RALRM allows to catch wire break and wire restore events correctly. But if the wire is already broken by the moment of power-up then RALRM doesn't allow to recognize it. So, RALRM can catch the wire break/restore event, but not the state (broken/unbroken).

Could you please recommend a right approach to wire-break diagnostics, that allows to recognize correctly if the wire is broken or not during power-up and runtime as well.

Thank you.

Dear 0_Einstein,

thank you for you comment.

Your idea is clear. But it looks like a workaround. Your suggestion implies that I refuse of using hardware diagnostics features and proceed with using only user software diagnostics. But I have PLC modules with "HF" mark, which have been bought namely for sake of using hardware diagnostics possibilities.

Moreover, in my particular project I have 60 AI modules x few channels each, so polling-based diagnostics approach, that you propose, wastes just a lot of processor time for overhead recalculations. The hardware diagnostics, which implies, as far as I understand, interrupt-based operation, as well as some internal (implicit) analysis of faulty factors and recalculations within the module hardware, is intended to resolve this problem. 

So if follow you proposal then the question arises - what's the use of HF modules then?

So, my question was - what is the right approach to using hardware diagnostics possibilities, to diagnose the faulty situations correctly (including correct check at PLC start-up).

You want to get notified "at startup" of a wire-break condition in the diagnostics buffer, which then can trigger execution of the diagnostics error OB, and then have on-demand diag handling.

Did I understand what you want to do - exactly?

It might be possible to do something like this, but I am not aware of it.

Submit that request to Siemens Support via Support Request -> Create new request.

If they know of a way, please share the answer.

From my reading of the documentation for diagnostics, only changes of state of diagnostics information gets logged in the diag buffer. During startup, the PLC establishes the "current" state from which changes can be detected.

That said, you can poll at startup for current diagnostics status for each module, and for any module with diag errors, dive deeper to find the specific channel(s) with errors. 

_Pavel_

Dear 0_Einstein,

thank you for you comment.

Your idea is clear. But it looks like a workaround. Your suggestion implies that I refuse of using hardware diagnostics features and proceed with using only user software diagnostics. But I have PLC modules with "HF" mark, which have been bought namely for sake of using hardware diagnostics possibilities.

Moreover, in my particular project I have 60 AI modules x few channels each, so polling-based diagnostics approach, that you propose, wastes just a lot of processor time for overhead recalculations. The hardware diagnostics, which implies, as far as I understand, interrupt-based operation, as well as some internal (implicit) analysis of faulty factors and recalculations within the module hardware, is intended to resolve this problem. 

So if follow you proposal then the question arises - what's the use of HF modules then?

So, my question was - what is the right approach to using hardware diagnostics possibilities, to diagnose the faulty situations correctly (including correct check at PLC start-up).

Dear 0_Einstein,

Local or Remote IO?   For remote IO, the library at this link ( https://support.industry.siemens.com/cs/document/109753067 ) might help capture the diagnostics status at startup.

_Pavel_

...

So my question is best formulated as follows: what is the right approach to using hardware diagnostics possibilities, to diagnose the faulty situations correctly (including correct check at PLC start-up).

...

Anyway - thanks for your replies. 

The original problem is they want to know at power up / startup there is a broken wire since OB82 will not get called at startup / power up if it's already broken (according to the OP). 

Hati

If it's the same rack where the CPU is is, OB82 will catch the error. I have the error catching done with GET_DIAG in OB82.

Yes, correct - OB82 is not called if any failure already exists at power-up, and moreover - GET_DIAG doesn't provide channel diagnostics

And OB82 is also correctly called when the faulty module is in the another rack from CPU (in an remote I/O station rack), there's no problem with that during runtime.

_Pavel_

And OB82 is also correctly called when the faulty module is in the another rack from CPU (in an remote I/O station rack), there's no problem with that during runtime.

 I'm not following. Any chance you can post a snapshot of your hardware so it is clearer which works and which doesn't.