Emerson Exchange 365

• Not Answered

How can I use a DI block to reference dataset values brought in through a Boolean Fan.

How can I use a DI block to reference dataset values brought in through a Boolean Fan. I want to use the faceplate and functionality of the DI block but do not want to have to wire the Simulate IN that always raises an error flag -  Simulate enabled.

BrianWood

• 19 Oct 2018 5:03 PM
• Cancel

11 Replies

• Andre Dicaire

  

  • 19 Oct 2018 5:32 PM

  You cannot. The DI block can be used to reference a Discrete Dataset register. If you pack the Boolean data into an Integer, you have to unpack it with either a Boolean Fan out or via Structured Text commands.
  
  You could create a Pseudo DI block as a composite and use a Condition block to read the integer and mask it with a Bitwise AND with the value that masks all bits but the one of interest. 'Dataset register value' & 16 would set the condition True only if the fourth Bit of the integer were true. Or use a variable to set the bit number (1 through 16) and use this in the expression to the power of 2 to create the compare value. That would allow you to "tune" the condition to the bit you are interested in.
  
  If you use a Landing module to extract the Boolean value, the control module that needs this value cannot use a DI block either. You can eliminate the need for Landing modules by mapping Boolean data as Data Sets, or using a Composite to extract the bit directly in the module where it is needed. Boolean Data sets will add some DI DST licenses but you get to skip the complexities of a Pseudo DI (and Pseudo AI for that matter.
  
  For outputs, I strongly recommend mapping the Boolean values in a Boolean dataset. That allows you to have direct mapping of data from the module to the PLC register and this provides better performance and easier troubleshooting.
  
  If the data for a given Motor is mapped to holding registers, where a single integer is used for all the data for that motor, than you could pack and unpack this data in the Motor module in DeltaV, and that too would be direct and easy to trouble shoot.

  Andre Dicaire

  • Cancel
• Michael Moody

  

  • 19 Oct 2018 5:41 PM

  In reply to Andre Dicaire:

  Brian,
  
  I've done similar to what Andre stated in the past for soft inputs coming from a PLC. In some cases, the "DI" bits were packed into 16 bit integers. I fanned them out in a landing module and used custom built soft DI block with some, but no all, of a standard DI functionality. Used a modified FP and all is good.
  
  Maybe Emerson will support a soft address option in the future for such cases.
  
  Michael

  • Cancel
• IntuitiveNeil

  

  • 19 Oct 2018 6:55 PM

  Following on from the other replies, if you can get hold of the PCSD SOFT DI or SCADA DI control module classes then these would probably serve you well as they include a soft DI composite. If you can get the associated Detail and Faceplate displays that also helps, but a slight alteration of standard DI displays can also be used.

  • Cancel
• Andre Dicaire

  

  • 19 Oct 2018 7:41 PM

  In reply to Michael Moody:

  Michael, I think Emerson's change in v12 to stop counting DST based on modules, and locking DST as 1 per dataset changes the game was a major step in simplifying soft tag integration. The PCSD soft DI block still requires the user to "unpack" the integer to individual parameters that can then be referenced instead of an IO. If the discrete data was in a Boolean data set, then a standard DI can reference it directly form the IO dataset map.
  
  I personally think it is reasonable to use a "Soft DI" block that is different than a DI block, with limited built for purpose structure, rather than bloating such a block to look and behave like a DI block, as you did.
  
  Ideally, I think it would be great if the DI Block was enhanced to allow it to serve these various input requirements. If the input of the DI could be: a) an IO reference, or b) a Module Parameter reference, or C) a basic expression similar to a condition block expression that resolves to True or False. That would allow a standard DI block in a Class module to be defined per instance to work with the desired signal source. The AI block should also have the same option.

  Andre Dicaire

  • Cancel
• Pieter Degier

  

  • 20 Oct 2018 11:19 AM

  In reply to Andre Dicaire:

  I fully agree with Andre and in addition to option b there should be a bit selection parameter similar to the profibus configuration as well. In that case you can still used pack bits in to 16 bit unsigned registers.

  • Cancel
• BrianWood

  

  • 20 Oct 2018 8:28 PM

  In reply to Andre Dicaire:

  Thanks everyone for your input. I have a small system and am trying to minimize the DST count. However in my experimenting is seems like it does only count 1 DST for references to the same dataset whether DI or AI. I was under the impression I needed to access dataset registers in the same module and then reference them in other modules to minimize the DST count. However it doesn't seem to matter if I reference the datasets from I/O blocks in individual modules. I have a tight timeline project and want to make sure I am starting in the right direction.

  • Cancel
• Andre Dicaire

  

  • 21 Oct 2018 3:33 PM

  In reply to BrianWood:

  Pre v12 DST licensing was per module and summed for total. This resulted in multiple DST licenses per Dataset. V12 and up applies one DST on a Dataset with first module reference.

  Andre Dicaire

  • Cancel
• Matthias Mulder

  

  • 20 Nov 2023 1:33 PM

  In reply to Andre Dicaire:

  Hi Andre, sorry to kick this old topic but my question is very much related. I hope you can help.
  
  We are going to read about 170 DI modus signals from a Siemens PLC. We have a PCSD DI_SCADA module that we can use to read the DI signals. The advantage of this DI_SCADA module is that it has a watchdog parameter which can disable the discrete alarm in case of a watchdog failure (to avoid alarm flooding in case of a watchdog failure).
  The DI_SCADA module can either read a boolean register directly or it can read an integer register. When reading an integer register you can use a bit_number parameter to read the bit you need (the module contains an ACT block using the SHR function to read the right bit from the integer).
  My question is: is it better to read boolean registers directly or use booleans packed in an integer? My feeling is that sending booleans packed into an integer register is more efficient than sending boolean registers regarding loading. But is it significant? On the other hand, when we use booleans registers directly we don't have to pack the booleans into an integer in the Siemens PLC. Are there other things to consider?

  • Cancel
• Chaitanya Adkar

  

  • 22 Nov 2023 4:04 AM

  In reply to Matthias Mulder:

  Hi Matthias,
  One thing you need to consider is each LDT can have maximum of 100 signals. So, if you send 170 unpacked booleans you will need 2 LDTs which will end up consuming 1 extra DST license.

  • Cancel
• Andre Dicaire

  

  • 28 Nov 2023 12:02 AM

  In reply to Matthias Mulder:

  Is it better to ....
  
  There are different ways to evaluate these options.
  
  First, it is more efficient to send ten 16 bit integers in one LDT than to have 160 boolean values sent across two Boolean LDT's. But that difference is negligible in the grand scheme of the overall configuration.
  
  You would use one AI DST for the Integer LDT, and two DI DST's for the Boolean LDT's, but that would be a wash in terms of cost. But if you combined those 10 packed integers with 90 other integers you also had to bring over, then you're getting the ten packed integers for free. Still, a couple hundred dollars is not a basis for choosing the engineered solution.
  
  What about trouble shooting? The boolean signals are cleaner to troubleshoot, even from DeltaV Diagnostics showing data values of the LDT, you can confirm all values are correct without any module configuration to read and parse out bit values. You also get to configure some signal information on each BIT to line out usage on both sides of the mapping. That can be quite useful down the road.
  
  You can use a landing module to parse out the bits for use in modules and for trouble shooting. That's and added step in configuration and you need to get this configured correctly. Landing module adds latency and if you run it faster to reduce this, you consume more CPU.
  
  Landing module forces use of DI_SCADA emulation block or equivalent as DI block cannot reference landing module parameter. DI block will be more CPU efficient. For 160 or 170 DI modules, that can have impact on controller loading.
  
  Landing module can have locking logic that freezes data during changes to interface link. A SCADA class using the DI Block could add such freeze logic into the DI modules, which could be running slower than the sped up Landing modules, so you end up with an overall lighter CPU load with no extra data latencies.
  
  Personally, I like the idea of Boolean LDT's with native DI Blocks reading them and having appropriate mitigation for handling a bypass to prevent spurious trips on changes to the PLC configuration. No extra modules or latencies and CPU efficient DI block rather than DI_SCADA.
  
  However, if the facility already has developed the use of landing modules and they like the approach, I would not oppose continuing with the solution and maintain a consistent approach. But if speed of data exchange is of the essence (minimal latency), then the most direct approach will provide lowest latency.
  
  We have a DI module that uses a separate interlock block to provide the DI Status to other modules. This allows the DI to be bypassed at the source for all interlock conditions that may be using it. Ai modules also use this. It would be easy to add a second bypass condition for bypassing based on planned download activity to the interface. Maybe this is a hold last value bypass feature. By using a class, you get to manage these globally in terms of logic, but you get to bypass them as a group based on the source bypass value they share. (HOLD_LDT!.CV) parameter in a PDT management Module.
  
  I think the most direct path of data is the easiest to troubleshoot. I also think it is better to consider the Maintenance and Operations personnels' needs ahead of the configuration or test engineer. The Operations and Maintenance will have to deal with the unexpected issues at 2 am in the morning on a holiday, and not during their scheduled test plan during FAT.

  Andre Dicaire

  • Cancel
• Matthias Mulder

  

  • 28 Nov 2023 4:00 PM

  In reply to Andre Dicaire:

  Hi Andre,
  
  Thanks for your reply! Useful evaluation! I agree that controller loading is an important aspect in this case.

  • Cancel