• Not Answered

Trending a Boolean Fan In Output

Hi,

Looking to trend the output of a Boolean Fan In function block. Is there a way to differentiate between the inputs using the OUT_INT value on a trend? Instead of having multiple parameters to trend is it possible to view just one parameter which would indicate which input is active? I'm not 100% sure on how the Boolean Fan In operates.

Best regards,

Will1997

8 Replies

  • The BFI combines the boolean inputs into a binary weighted integer OUT_INT, and a BCD (binary coded Decimal) representation of the inputs. It also has a first out Trap that will indicate which bit became true first (FIRST_OUT). The First OUT should identify which bit became true first. In the case where two bits become true on the same module scan, the first out will select the lowest order bit.

    BOL indicates that First Out is a "Snapshot of OUT_INT" when an input becomes true. I believe that when two or more Inputs become true on the same scan, the lowest indexed input is trapped as the FO value. If it is possible that your BFI could see two or more values become true on the same scan, either through coincidence, or because some values may be caused by the other quickly enough to occur between module scans. In most cases, one will cause the other quickly, but not the other way around. (If they only aver happen together, then why monitor both?).

    If the first out trap identifies the lowest order bit as the first in, then you should consider placing the "initiating" conditions before secondary conditions. The higher bit values must come in first to be trapped ahead of the lower bit conditions. If conditions are not causal, but can happen due to coincidence, place more critical events on the lower bits so First Out traps the more important conditions.

    Running the module faster will reduce the time window for coincidental multi activations, but that also consumes more CPU. Understanding the order of processing of the block and how the process works can allow you to design the logic to give you the right information even when two or more conditions happen at "once". If the additional conditions require control action, the BFI will provide a single bit First Out.

    As for a single value to trend, the OUT_INT will represent all bits, but you will not have a trend of each bit, just one number. This could be usefull in diagnostics, but less so for an operator interested in the bit states.

    Wonder if you could use a LogEvent based on First Out. You can read FIRST_OUT in an Action block and generate a LogEvent that provides a descriptive message about the FO bit that has become active. You can historize FO and get an integer of FO traps.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Hi Andre,
    Thank you for the detailed response. I would have thought the same in that it's not really possible (or practical) to trend the output as deciphering the input can be tricky if more than one input is high at the time. I have implement a DV graphic which is already highlights when an input is active but looking to bring this over to IP21, MES, for everyone to be able to look at and it just doesn't sound ideal unless there's a graphic created where individual object can be linked to the active input. These are used for interlocks already so using this method. I would attach an image but can't seem to.

    Regards,

    Wilson
  • In reply to Wilson Halligan:

    If you click the Use rich formatting option when commenting you should then get an interface that has an insert menu option where you can pick an image to upload.

    Windows Calculator on PCs has an option to select Programmer which will show you the Binary bit pattern for the decimal number entered. I have also created in iFix for a customer to help people where you enter the number and it outputs what that is. So there are things that can be used/done to help.

  • In reply to Andre Dicaire:

    To clarify: BOL is correct. FIRST_OUT *is* a copy of OUT_INT when the inputs go from all = 0 to one or more = 1. We use this to let the operators know all the conditions that shut down a piece of equipment. Any condition that came in after did not shut it down.
  • In reply to SBPosey:

    Note: The first out trapping will only update the FIRST_OUT if ARM_TRAP parameter is 1 (which is the default) but some configurations use/update this parameter because FIRST_OUT will get updated if all the INs clear (OUT_IN = 0) and then later become non-zero again which may not be the "true" FIRST_OUT of what occurred!
  • In reply to Matt Stoner:

    Hi,

    Thanks for the info. Is there a function block that can convert decimal to Mask? or decimal to binary? Tried to script something but failing miserably!

    Regards,

    Wilson

  • In reply to Wilson Halligan:

    The BFI is an integer, and using a BFO will reconstitute the bits. But that is in a module where you already have the bits. Hmm.

    In Live, you can do a bitwise compare to check if a specific bit is true of false.

    (OUT_INT & 1) = true if first bit is true.
    (OUT_INT & 4) = true if Third bit is true.
    (OUT_INT & 8) = true if fourth bit is true.

    If you use an exponent:

    (OUT_INT & Math.pow(2, 0)) = true if first bit is true.
    (OUT_INT & Math.pow(2, 2)) = true if Third bit is true.
    (OUT_INT & Math.pow(2, 3)) = true if Fourth bit is true.

    Another way I've seen is to shift the Bit in question and & with 1:

    ((OUT_INT >> 0) & 1) = true if first bit is true.
    ((OUT_INT >> 2) & 1) = true if Third bit is true.
    ((OUT_INT >> 3) & 1) = true if Fourth bit is true.

    I'm partial to the first one as I think it is more efficient. But you have to use the weighted binary value to compare for the bit in question. There are other ways I'm sure.

    Andre Dicaire

  • In reply to SBPosey:

    Thanks for confirming. When two or more conditions go true at the same time, it is impossible to know which came first. Understanding the process and what drives these conditions can reveal that the physics dictate that one condition when true also drives a second condition immediately, and we know we would never see condition 2 cause condition 1, but condition 2 could occur without condition 1, then we know condition 1 is the cause even though condition 2 occurred in the same scan. So a FO can be implied by how order the conditions and how we interpret FIRST_OUT.

    It only matters if one condition would drive the operator to react differently than the other. Like in Programming, error handling is often more involved and complicated than the normal function we are trying to create.

    Andre Dicaire