Emerson Exchange 365

Well the first problem you have is the BFI is running before all the conditions blocks so the interlock is a scan behind.

Change the BFI to be executed after all the CND blocks and retest.

In reply to Matt Stoner:

Hello everybody

our customer changed the CND execution order.

Unfortunately the same Problem appears again.

As Information the Valves have no feedback switches.

As mentionned in my first post ... in the past (DeltaV 10.1) it worked well.

Have you another ID?

Thank you.

In reply to LostEngineer0:

The execution order is essential to avoid signal overlapping and therefore is mandatory to get it correct.
Does it stopped working after migration to DV13 or only after customer changed the execution order on whatever reason?
It would help much better if you can show also the crosswise IL cnd-expression of each of your valve, scan rate of the CM, maybe valves are module blocks in an EM and linked to each other?
There might be another signal delay over all involved CM which could happened after a total DL after migration.
BR Michael

In reply to LostEngineer0:

Execution order of the modules running in the controller can't be "controlled". So it may have been executing one before the other (works) and now they are executing in different order (broken). Ensure that the Close SP is given and you confirm the Valve is either closed (clearing the interlock) before writing the other valve to Open. If you are doing them at the same time it may explain what you are experiencing.

In reply to Matt Stoner:

Interesting... That means our Customer have to adapt his Software .
Have Emerson an Official Document which explain that ?
Beacause the customer will have to made "Changes", that means time and money.
Thank you.

In reply to LostEngineer0:

There won't be any documentation on how to implement interlock and code schemes. If the SPs are written at the same time, there is no guarantee of when modules are executed which means the interlock(s) might still be true. The logic has to be designed and implemented to cover cases like this, if this is the problem they are experiencing.

In reply to Matt Stoner:

I've not seen issues like your are facing result from an upgrade in the past (I've upgraded from older versions to v8, v9, v10, v11, & v13.). Timing issues can be a huge pain and sometimes we success out of luck. Later, a change "changes our luck".

What is used in the CND blocks to verify if valve is open / closed? (command, limit switch value, valve status)
What is used in logic to command the other valve. The logic shouldn't try to open Cooling valve until Heating valve is closed.
Are the valves being opened by logic or by an operator?

I would trend the Valve commands, status, interlock timer and output, etc. for each valve (1 or 2 second) scan rate and get more clarity on the timing.

In reply to Michael Moody:

Lets talk about module execution order. When it comes to the Chicken module and the Egg module, which comes first? Execution order between two modules at the same execution scan rate is simply alternating.

Each of these valves is interlocked to the other, and if if both were closed, and both commanded to open at the same time, one would open and the other would be interlocked, unless the interlock is on the PV and there is a delay in the confirmation. Then both might open, but once OPEN is confirmed on one, the other would interlock.

If you used the SP_D as well as the PV_D for the interlocks, each valve would interlock on the SP_D under normal operation. This is internal data so when one module has SP_D = Open or !=Closed, the other cannot Open. If a valve jams Open, the PV_D keeps the interlock in place.

The key is I don't want execution order of modules to have any influence on my logic. SP_D gives same scan reference and PV_D delays permissive.

So saying HEAT Valve = Closed is not enough. I need to see if you are looking at PV_D = Closed, SP_D = Closed, or whatever.

Andre Dicaire

In reply to Michael Moody:

Lets talk about module execution order. When it comes to the Chicken module and the Egg module, which comes first? Execution order between two modules at the same execution scan rate is simply alternating.

Each of these valves is interlocked to the other, and if if both were closed, and both commanded to open at the same time, one would open and the other would be interlocked, unless the interlock is on the PV and there is a delay in the confirmation. Then both might open, but once OPEN is confirmed on one, the other would interlock.

If you used the SP_D as well as the PV_D for the interlocks, each valve would interlock on the SP_D under normal operation. This is internal data so when one module has SP_D = Open or !=Closed, the other cannot Open. If a valve jams Open, the PV_D keeps the interlock in place.

The key is I don't want execution order of modules to have any influence on my logic. SP_D gives same scan reference and PV_D delays permissive.

So saying HEAT Valve = Closed is not enough. I need to see if you are looking at PV_D = Closed, SP_D = Closed, or whatever.

Andre Dicaire