markV rungs


Thread Starter


LZZ is used in many rungs asblock output,but it is not a coil.Is it a C language tool for creating header files?.could u please clarify my dout.
-L14HM---L2W---L14HS----*TMGV_4 40*-----(LZZ)
*TMGV_6 60*
* *
* *
LZZ is a "place-holder," or, in digital-speak, a "bit bucket." You will never see any contacts associated with LZZ as its status changes many times during the execution of the CSP (Control Sequence Program); you SHOULD only see it used as a coil.

It is used when it is not necessary to know that a block has been enabled or disabled (sometimes it might be necessary or helpful to know that a block has been enabled or disabled...). So, LZZ is used when a coil name is required, but contacts associated with that coil will never be used anywhere else in the CSP. (It saves a logical memory location from having to be used for no "logical" reason--no pun intended!).

And while we're on the subject of "-speak" (we are, aren't we?), the definition of "doubt" is "a lack of certainty; a lack of trust; to be undecided or skeptical about..." When discussing Mark V issues, use of the word 'doubt' when one has questions or needs an explanation is discouraged. Please just ask for an explanation or say, "I have a question."

Thanks for your explanation.I understood the application of LZZ.Is it aacronym or code?.could you please explain me?


Rahul P Sharma

There is also a LTRUE and LFALSE which is used in rungs... What are the likely places in the rung where one might expect these logic signals and what is their importance??

au revoir,
<p>The signal could have been called LDEAD or L_UNUSED or anything; LZZ has no particular connotation or meaning.

<p>(You may also find a signal called BIT_BUCKET on some applications, which was an analog signal "placeholder" or dummy variable for analog writes. It would be used when the output of some block operation was not required elsewhere in the CSP but an output signal must be supplied for the block to operate properly.)

<p>LTRUE is a logic signal which is ALWAYS a logic "1"; LFALSE is a logic signal which is ALWAYS a logic "0". You SHOULD NEVER find a LTRUE coil or a LFALSE coil, since they are written to in the operating system of the Mk V; writing to a coil in the CSP with the name LTRUE or LFALSE with some logic will cause all kinds of problems!!!

<p>LTRUE and LFALSE were used as contact "placeholders" and to enable or disable (depending on how they were used) rungs and blocks.
----| |-------....-----------------( )

The above logic would be enabled.

----|/|-------....-----------------( )

The above logic would be disabled.

----| |-------....-----------------( )

The above logic would be disabled.

----|/|-------....-----------------( )

The above logic would be enabled.
<p>The choice to use a normally closed LTRUE or a normally open LFALSE contact to disable a rung/block was left up to the engineer writing the code--there was no standard. Similarly, the choice to use a normally open LTRUE or a normally closed LFALSE contact to enable a rung/block was also left up the engineer.

We have used LTRUE to deactivate a low priority alarm group to our operations center; Approximately 40 of the 177 possible alarms are included in the group (it is one of the 10 alarm groups we have)... low priority, non-critical alarms such as
"Relative humidity sensor fault"
"generator space heater trouble"
"Generator air filter cleaner pressure low"

The coil which generates the group alarm is a "1"
under normal conditions, and changes to a "0" if any of the monitored items goes into alarm. Adding a parallel rung with LTRUE prevents the coil from ever changing to "0"; All alarms are still active at the MKIV, it is only data going to the operations people that is disabled.

Carte blanche disabling of a large number of alarms is a action that should be used with much forethought and descression; Although it is a quick and easy "fix" of a symptom, doing it too often may end up with a unit tripping due to a after effect of a "non-critical" item... (there are conflicting schools of thought on alarm monitoring...)