Recent Control & Safety Systems Discussions
Similar Posts
Any way to force Analog Inputs for RX3i?
Execution Order in SFC module
How is scan rate / execution order determined when using "Module Blocks"
State driven EM execution order per state
What is the best way to force a valve to CAS and OPEN?
Share
  • Not Answered

Can module execution order be forced in any way?

Hello All,

I read several other posts related to this question, but they were old (2014, 2015 i think). Has anything changed in DeltaV that allows the order of module execution to be forced to a particular order?

Brian Hrankowsky

16 Replies

  • Marcelo Sottano
    Do you mean execute diverse modules asignated to a particular Controller? Control the order the modules execute in them?
  • vmvmhatre
    Note: Below answer is based on experience up to DeltaV 13.3.

    Straight answer will be 'No, DeltaV Configuration engineer can not define order for module execution in controller'

    Controller executes module based on module priority (high, medium and low) which is based on scan rates assigned.
    But making a module scan rate fast than other module just to execute it before other module is not good idea.
    DeltaV Configuration engineer have to divide control strategy correctly in different modules to achieve correct control.
    When control modules have same scan rate, there execution order will be decided by controller and can not be predicted. If a module is feeding signal to other module, control action may be delayed by few scan rates if current execution order is not as expected. In most of the processes, this delay of few scan rates is acceptable. If in any process, such delay in control is not acceptable then assigning correct module scan rate and correct control strategy becomes important.
  • Brian Hrankowsky

    In reply to vmvmhatre:

    Thank you for confirming that no new features have been added to enable this

  • Lun.Raznik

    In reply to Brian Hrankowsky:

    I am curious, what is the use case for ordering execution of the module?
  • Brian Hrankowsky

    In reply to Lun.Raznik:

    General:
    many protein purification processes use positive displacement pumps and are completely liquid filled (no capacitance) - so startup and shutdown get tricky when you can't predict the order that things will happen and you risk burping pressure relief devices and expose product to the surrounding environment. timing of commands being unpredictable can cause conservative delay settings when deciding if process streams should be diverted to waste or forward processed based on on-line analyticals. these fractions of a % yield add up to a lot of $$$ literally down the drain.

    Specific:
    blend of product in plug flow filtering / chromatography processes requires multiple pumps to achieve turndown. pumps need to be started at the same time. literally the RUN bits need to hit the PLC tags that control the pumps (servos) in the same write. every second that the pump speeds aren't coordinated is potential yield loss and depending on which pump starts first, could allow small mounts of precipitate to form. the only way to guarantee this happens is if the writes come from the same module - keep following the logic and you get to where both pumps DC blocks need to also be in the same module. so you can't use your validated motor module and have to build a completely custom one (and no, using the enhanced DC or driving both pumps from the same DC block won't meet all of the requirements). from a data perspective, the historian tags make no sense, the name can't match what is seen on the P&IDs, you need custom dynamos, faceplate, detail, etc.

    <redacted soap box> :)
  • Lun.Raznik

    In reply to Brian Hrankowsky:

    This was above my head!

    But since you mentioned PLC and RUN bits I am assuming that DeltaV is used for starting and stopping the motors then. What is acceptable time delay between commands? Say between DC1 and DC2? The reason I am asking is that you can use PK with 25ms module - assuming the the controller is not overloaded, you can send RUN bits within 25ms from two different modules for example.

    How do you send RUN bits by the way, hardwired/serial/modbus/OPC?
  • Scott Thompson

    The only way I'm aware of that execution order of modules can be assured is to have the modules being manipulated embedded in the module doing the orchestration.  The picture below is conceptual only, not meant to be a solution to your problem but does show execution order control of other control modules.  You could add an off delay of the valve executing first to delay it closing for a scan just prior to the "bad path" valve opening when transitioning back to bad quality.

  • Brian Hrankowsky

    In reply to Scott Thompson:

    module blocks don't affect execution order.
  • Brian Hrankowsky

    In reply to Lun.Raznik:

    Ethernet/IP. the request from the process engineers was 0 seconds delay. You can't write to the PLC tags at that 25 ms rate as the minimum for the interface is 50 ms. even if you only had one tag set up in the UCMM interface. a single UCMM tag takes minimum 20ms communication. so 25 ms is pushing your luck and would be faster than the comms interface would allow. 50 ms woudl only allow one read and one write tag to be set up. AND you'd be wasting tons of controller resources to handle something that should not really need to be handled. there's a good KBA explaining the constraints with the UCMM interface.

    we'd like to use DeltaV in more areas that use PLCs at our plant, but it's items like this can prevent getting there.
  • Scott Thompson

    In reply to Brian Hrankowsky:

    It used to if all were at the same execution rate but we'd really need someone with more intimate knowledge of the controller code to confirm which is typically beyond what you'll find on a public forum. If it doesn't the modules execute in alpha-numeric order after initial total download of the controller and then the one that has the last partial download moves to the end of the list.
  • Brian Hrankowsky

    In reply to Scott Thompson:

    Andre Dicaire has a post on this topic that does a nice job explaining how this works.
  • Lun.Raznik

    In reply to Brian Hrankowsky:

    One workaround I can think of is to use a module of type SFC. Then create link composite, the execution of the composite blocks will be dictated by the steps (Non-Boolean/Non-Stored) running the embedded block.

    I am not familiar enough how DC blocks work but I can also imagine using BFI to fan two DC outs to BFI and use BFI/OUT_INT via Ethernet/IP.
  • Andre Dicaire

    In reply to Scott Thompson:

    module execution order has never been affected by the use of module blocks. Module blocks provide clarity in logic flow, and they do optimize how data is transferred so that reads are used rather than writes. but the modules themselves execute on their schedule and are not scheduled in any way based on the use of Module blocks.

    Andre Dicaire

  • Andre Dicaire

    In reply to Andre Dicaire:

    The challenge that Brian has is to coordinate the starting and stopping of multiple pump in order quickly establish the right ratios of products and minimize waste, which as I understand it, is done by initially sending product to drain and switching the flow into the process once flow ratios are established.

    DeltaV module execution is scheduled over time and modules effectively run on time. The execution time can be observed and can vary depending on how the module is designed. Conditional logic in calc blocks can increase or decrease this time, which means there is a bit of jitter in the module schedule, which is reset within the fixed time slices so as to avoid a cumulative effect. When the modules do execute, they write to the IO map in the controller. On a separate task, the IO bus or CHARM IO are processed on their separate schedule. With local IO, the bus scan time is determined by the number and type of cards connected to the carrier. This bus is typically 30 to 50 ms, but can be as low as 20 ms on M Series or S series and as high as 60 to 80 ms (though this is rare). CHARMS have a configurable scan rate of 50, 100, 250 or 500 ms, default is 250. I have typically used 100 ms as my default, which serves most applications well. When needed we set to 50 ms. 250 ms might be needed if using SDPlus controllers, but with SQ and SX, I use 100 ms.

    The only way to have separate modules write to the IO in a minimal difference in time is to run these modules as fast as you can, which is 100 ms in M and S series controllers. PK can run 50 and 25 ms, but will complain if the IO cards used are not the Plus Series DO and DI. Not a big issue for the DI, but if a 25 ms module writes to regular Series 2 DO cards, you could write to the same channel faster than the IO bus could process it and you'll get some IO out errors reported.

    The PK controller gives you much more CPU so running some modules at 100, 50 or even 25 ms is better accommodated. Although the PK as 4 times Processor as SX or MX, if you run all your modules 4 times faster in the PK, you'll eat up that CPU as well.

    The PK also has a 10 ms mimimum on the bus cycle time. That could make a difference with 25 ms modules.

    So one solution would be to run your DC motor modules at 100 ms, and if they currently are at 1 second, well that should significantly reduce the time spread of the pump starts. However, you did mention PLC's so if there is a VIM or Serial Card involved, that too has to be considered. If running the modules faster is a benefit, but CPU is not available, upgrading to PK would allow you to keep the configuration as is and cut significant delay time to below 100 ms. But that requires v14 DeltaV version.

    You could build an intermediate module that adds some syncronization logic and drives the actual outputs. SImilar to Profibus Sync command, you set a sync status that causes the output module to delay its outputs until it sees all the signals are ready. it then writes all outputs in one scan. That's a redesign and you have to figure out how to tell the module when each motor state has been defined. That is if you have 4 motors and sometimes you might be starting one or two or three in any combination or all four, you have to indicate some how that your motor states are set and the module can send the outputs.

    If you have a PLC driving the actual field, you would need to do this logic in the PLC.

    The module synchronization is only one aspect to consider. If the IO are spread across multiple IO cards, understand that each card is processed in order as fast as the bus can scan. If you wrote to two cards at the same time, but one was just scanned, the second would get its output and the other would be on the next bus scan. If your timing requirements are such that you need better than the bus scan rate, that is a pretty fast requirement. If the IO are on the same card, and you write them at the same time, the delay between the outputs activating would be minimal.

    Simplest solution, if the IO bus is adequate, is to run the modules as fast as possible.

    Andre Dicaire

  • Andre Dicaire

    In reply to Andre Dicaire:

    The challenge that Brian has is to coordinate the starting and stopping of multiple pump in order quickly establish the right ratios of products and minimize waste, which as I understand it, is done by initially sending product to drain and switching the flow into the process once flow ratios are established.

    DeltaV module execution is scheduled over time and modules effectively run on time. The execution time can be observed and can vary depending on how the module is designed. Conditional logic in calc blocks can increase or decrease this time, which means there is a bit of jitter in the module schedule, which is reset within the fixed time slices so as to avoid a cumulative effect. When the modules do execute, they write to the IO map in the controller. On a separate task, the IO bus or CHARM IO are processed on their separate schedule. With local IO, the bus scan time is determined by the number and type of cards connected to the carrier. This bus is typically 30 to 50 ms, but can be as low as 20 ms on M Series or S series and as high as 60 to 80 ms (though this is rare). CHARMS have a configurable scan rate of 50, 100, 250 or 500 ms, default is 250. I have typically used 100 ms as my default, which serves most applications well. When needed we set to 50 ms. 250 ms might be needed if using SDPlus controllers, but with SQ and SX, I use 100 ms.

    The only way to have separate modules write to the IO in a minimal difference in time is to run these modules as fast as you can, which is 100 ms in M and S series controllers. PK can run 50 and 25 ms, but will complain if the IO cards used are not the Plus Series DO and DI. Not a big issue for the DI, but if a 25 ms module writes to regular Series 2 DO cards, you could write to the same channel faster than the IO bus could process it and you'll get some IO out errors reported.

    The PK controller gives you much more CPU so running some modules at 100, 50 or even 25 ms is better accommodated. Although the PK as 4 times Processor as SX or MX, if you run all your modules 4 times faster in the PK, you'll eat up that CPU as well.

    The PK also has a 10 ms mimimum on the bus cycle time. That could make a difference with 25 ms modules.

    So one solution would be to run your DC motor modules at 100 ms, and if they currently are at 1 second, well that should significantly reduce the time spread of the pump starts. However, you did mention PLC's so if there is a VIM or Serial Card involved, that too has to be considered. If running the modules faster is a benefit, but CPU is not available, upgrading to PK would allow you to keep the configuration as is and cut significant delay time to below 100 ms. But that requires v14 DeltaV version.

    You could build an intermediate module that adds some syncronization logic and drives the actual outputs. SImilar to Profibus Sync command, you set a sync status that causes the output module to delay its outputs until it sees all the signals are ready. it then writes all outputs in one scan. That's a redesign and you have to figure out how to tell the module when each motor state has been defined. That is if you have 4 motors and sometimes you might be starting one or two or three in any combination or all four, you have to indicate some how that your motor states are set and the module can send the outputs.

    If you have a PLC driving the actual field, you would need to do this logic in the PLC.

    The module synchronization is only one aspect to consider. If the IO are spread across multiple IO cards, understand that each card is processed in order as fast as the bus can scan. If you wrote to two cards at the same time, but one was just scanned, the second would get its output and the other would be on the next bus scan. If your timing requirements are such that you need better than the bus scan rate, that is a pretty fast requirement. If the IO are on the same card, and you write them at the same time, the delay between the outputs activating would be minimal.

    Simplest solution, if the IO bus is adequate, is to run the modules as fast as possible.

    Andre Dicaire

This is the official online community site of the Emerson Global Users Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson Automation Solution's products and services. Our goal is to improve the efficiency and use of automation systems and solutions employed at members’ facilities by sharing our knowledge, experiences, and application information.

User Groups | World Areas | Community Guidelines | Legal Information | Privacy Policy | Contact Community Manager

Website translation provided by Website Translator

© 2015-2022 Emerson Global Users Exchange. All rights reserved.