Emerson Exchange 365

Get PID block out of IMAN

I've created a simple control loop consisting of AI, PID, and AO blocks for the purpose of simulation on my DeltaV system, but I can't get the PID block out of IMAN. The only difference I can think of between this loop and others that are working is I haven't assigned any IO to the AI/AO blocks, and I've enabled simulate on the AI block.  I have the BKCAL_OUT from the AO block connected to the BKCAL_IN on the PID block and the status is GoodCascade so I don't understand why the PID block is in IMAN. Can someone offer suggestions as to what could be wrong?

vbrperry

• 26 Jun 2018 5:55 PM
• Cancel

17 Replies

• James Beall

  

  • 26 Jun 2018 6:03 PM

  Please send a screen print of Control Studio On-Line of the module. (Click on "Use rich formatting" and use tools in toolbar.) I use a DeltaV SimulatePro system for my testing and I don't recall if not having an AO channel causes this problem. However, since the AO/BKCAL_OUT shows goodcascade, that must not be the problem.
  James

  • Cancel
• JackC

  

  • 26 Jun 2018 6:03 PM

  Typically I get IMAN on the Master Loop when the Slave Loop has some BKCAL connected to it and the status is bad. Do you have anything linked to that loop or is it a stand alone loop?

  • Cancel
• IntuitiveNeil

  

  • 26 Jun 2018 6:09 PM

  In reply to JackC:

  Is the slave module with the AO function block assigned to a controller or application station.
  
  If controller the AO block behaves differently I’ve discovered between controller and app station depending if the IO_OUT is configured.
  
  Also ensure the AO FB is set for simulation

  • Cancel
• Michael Krispin

  

  • 26 Jun 2018 6:16 PM

  Hi vprperry,
  you have nothing done wrong. The AO-Block just send via the BKCAL_OUT a status that it can't handle any set point from the PID-Out because the AO-Block get itself a bad signal from its field device (which is missing in your case, open output)
  If you put the AO-Block into simulate then the PID will fall back in the target mode. So you can go with your simulation.
  
  If you have Foundation Fieldbus AO then you have the A...-Card. This FB you can't set into simulated because in microscopic view the AO works like a module in another non existing controller. The controller in that case is your instrument. There is no other way as to change the AO-Block for your testing into a standard AO-IO block.
  Best Regards,
  Michael

  • Cancel
• Matt Stoner

  

  • 26 Jun 2018 6:37 PM

  As Neil is alluding to, my guess is that you have the module assigned to workstation or virtual controller.
  
  Try downloading the module and it should resolve the issue if the status is GoodCascade on PID/BKCAL_IN.

  • Cancel
• Michael Krispin

  

  • 26 Jun 2018 7:11 PM

  In reply to Matt Stoner:

  Hi Matt, I found out that an AO-Block running in a module which is assigned to a PC (PP+,OI or AS) will not have any bad status.
  I guess he has a normal CM assigned to a controller.
  
  But my real intention is to clarify that the approach of having separated modules for AI,PID,AO is such a nonsense, you should not do.
  The point is the unpredicted execution order of that control-modules. It is always to prefer to have the AI-PID-AO FBs in one single module.
  This make sure that the input - calculation - output is always in the dedicated execution time within one cycle while different modules could be executed also in order of i.e. AI-AO-PID which add minimum 1 death cycle in the signal run time through the system. By putting the single modules as embedded CM into a EQM make the signal transfer through the DCS even more un-predictable and every tuning start into a gambling after a download, which change in fact the CM execution order in the controller. Please help me to supply this approach. There is absolutely no good reason to have all in separate modules. Even the simplest naked PID block can get an analogue Input, execute and send a value to an output just within one PID-FB in a naked CM. Why everything must be made more complicate and load producing, especially via PCSD?
  Thank You and Best Regards,
  Michael

  • Cancel
• vbrperry

  

  • 26 Jun 2018 7:55 PM

  Thank you everyone for the replies. I had my module assigned to a ProPlus. When I reassigned to a controller it fixed the problem. Any ideas as to why the module wouldn't work on the ProPlus?

  • Cancel
• Matt Stoner

  

  • 26 Jun 2018 7:56 PM

  In reply to Michael Krispin:

  Michael,

  This probably needs a different topic/thread.

  Yes the control should be better if all put into a single module where you can control the execution order of the blocks (PCSD does have a module for this but I'm not sure how often it is used) but a some reasons I think are valid for splitting out:

  1. Execution time for Master Level/Temperature loop doesn't need to execute every second while the Slave Flow requires it.
  2. Alarming to the operator becomes more difficult because now a single module has two sets of alarms which can be easily confused because of the need of standardizing names for display purposes.
  3. Displaying 'info' and Historical Trending on the graphics/trends becomes an issue where users are expecting tags for each of the items that won't exist because they have been merged into a single module.

  James Beall any comments on this?

  • Cancel
• Matt Stoner

  

  • 26 Jun 2018 7:58 PM

  In reply to vbrperry:

  Just needed a download of the module to "clear" up the problem I think. I have seen this recently in v13 where I don't think it occurred in prior revisions.

  • Cancel
• vbrperry

  

  • 26 Jun 2018 8:12 PM

  In reply to Michael Krispin:

  Sorry, I wasn't very clear in phrasing my question, but all the blocks are in the same module.

  • Cancel
• vbrperry

  

  • 26 Jun 2018 8:22 PM

  In reply to Matt Stoner:

  So I'm running version 11.3, and I downloaded the module multiple times on the PP, and couldn't resolve the issue, but resolved it on the first download to a real controller. I even switched the assignment back to the PP and downloaded changed setup data and still the same issue, the PID stuck in IMAN.

  • Cancel
• James Beall

  

  • 26 Jun 2018 8:37 PM

  In reply to vbrperry:

  This is the design basis for DeltaV. I believe one of the concerns is that someone may inadvertently assign PID controllers that are controlling a process to a ProPlus. Not only is the ProPlus not redundant, it could easily be re-booted by someone who didn't know real control was going on in the ProPlus. Interestingly, if you are use a DeltaV Simulate or SimulatePro system, you can run the PID in the ProPlus! But, there is no real process connected to it!

  • Cancel
• IntuitiveNeil

  

  • 26 Jun 2018 8:38 PM

  Okay, there was a bug at 11.3 i believe specifically this issue
  
  Please install the workstation hotfix and that should sort it out for you.
  
  Presuming you have guardian support and an active CSS license for your system ID

  • Cancel
• IntuitiveNeil

  

  • 26 Jun 2018 9:05 PM

  In reply to IntuitiveNeil:

  I may have confused my version. That was definately at version 10.3.1, see KBA NA-0900-0039
  
  But i do seem to recall it being there at 11.3, although not identified in release notes

  • Cancel
• vbrperry

  

  • 26 Jun 2018 9:25 PM

  

  • Cancel