Easergy T300: adding SF6 loss signal to interlock to prevent PM6 LBS to operate

[Mikel_Beltrán]

Hello,

in a MV application where we use the T300 to control a pole-mounted LBS (load break switch), we want to use formulas in Easergy Builder to implement additional blocking conditions for switch control.

These are the DIs in SC150:

By default, DI5 is used to activate/deactivate the switch interlock, and we already use that DI for manual blocking.

But we also want to block the switch if the SF6 level is low, so we need to use another DI for that purpose. DI7, for example, as it is configurable.

We have followed the steps described in the attached Application Note and it seems to work just fine. Now the LBS can be blocked from both DI5 and DI7.

However, our concern is the following. At the first step of the procedure, in Easergy Builder, we completely replace the source of these commands:

On that 1st step, it requires us to remove the original “Cilo” source of those commands, that look like this:

And replace them by these formulae:

After doing that step and the others in the Application Note, our tests confirm that it just works fine as I said.

But we just wonder if we have caused a non-desired side effect in our LBS application by removing the original Cilo source of those commands in the 1st step of the procedure.

I would appreciate if someone with experience with this particular case share their thoughts.

Many thanks in advance.

[TomBerry · Accepted solution]

The App Note describes another step that you don't mention in the email

The original CILO sources should still be used - they should have been moved to some new variables that are used in the OR() formulas

Add new Command variables with source Cilo

Name	Description	Source	Source Coordinate
HU01_CILO1_BlkOp1_stVal	Block operation from Head Unit to SC01	Cilo	CSWI_BLKOP:SC01
HU01_CILO1_EnaOp1_stVal	Enable operation from Head Unit to SC01	Cilo	CSWI_ENAOP:SC01

I think you must have done this, otherwise the system would have reported an error when loading the configuration; and the commands would not work

[AndreMelo]

Hi @Mikel_Beltrán 

As @TomBerry well said,  you must relocate the old TAG.

However, I would suggest a simpler way to avoid all these changes, you can just use Source 2 as following:

it works like an OR logic.

Configure the DI you want in the Blocking command source 2 and it is done.

Best Regards

[Mikel_Beltrán]

Hello @TomBerry ,

thanks a lot for your reply!

Just to clarify: we followed all the steps described in the Application note, from the first to the last (I'm afraid I wasn't clear enough on that point in my previous message, sorry).

So yes, we did that step that you mention too, indeed.

I guess we can be sure that everything will work safely, then. Thank you.

@AndreMelo thank you for sharing an alternative. Since we are starting to learn how to use these configurations, it helps to understand how they work.