I was wondering what parameters users typically bring in from these overloads. We're going to be installing an MCC, it appears the Allen Bradley E3's will be compatible with DeltaV, I was planning on bringing in the trip cause (16 bit word) and average amperage (16 bit word), for run confirm/monitoring, combined as a single 32 bit word (to save tags), split it into the bits for trip cause word and break the second word out as the amperage, and output only a single bit for the run command, for each E3 overload. Also do the A/B E3 overloads require any configuration with RSNETWORX out of the box, or do they come with cyclic I/O enabled & you just set the motor FLA & 3 phase etc as appropriate? I noticed the User Exchange had an E3 'example', but it had no module to download, only the EDS file. I was curious what other users do for MCC's. Also, if I set up a fault reset on operator graphic only, wherein they push a button, can button VBA use frswritevalue, to directly write to the devicenet signal to reset the trip & thereby save a tag? Trip reset from DeltaV isn't sufficiently valuable that I want to consume 1 DO per overload, so I was wondering if this would work? I've configured numerous Powerflex drives, Flex I/O, and a scale with devicenet but haven't worked with the overloads and so am seeking some input.
Frank,
I can speak to some of your questions. DeltaV has enhanced the support for DeviceNet in v11.3 with the Diagnostic calls, which allow you to read in supplementary data via Explicit Messaging without mapping this data to the IO Signals. This data can be brought into the DeltaV control module and does not consume a DST. This is intended for diagnostic data, and is polled one device at a time in the background at a slower rate so as not to impact the cyclic data polling rate. This is explained in Books On Line but you need the device specific information to know how to address the data you are looking for.
In v12, DeltaV licensing of DeviceNet and Profibus Devices will follow the FF model introduced in v10. That is, one DST for the first 16 signals configured/referenced into DeltaV. So instead of using a 32 Bit word as one AI signal, you can keep the data separate as two AI signals. If you have 2 DI, 2 DO and two AI signals, the DST license needed is one AI. If you had a VFD, with an AO and an assortment of AI's, DO's and DI's, this would be one AO DST. In general, you will have either an AI for MCC's, and AO for VFD's (the drive speed setpoint). With this change, you will not need to complicate the IO signals for MCCs and Drives in order to minimize DST Licensing. You can engineer the IO so that it makes sense and use the values directly in the modules.
You can certainly reference device signals directly in a Graphic and bypass the control module. this is called a SCADA tag, though it really is a DA (data acquisition) tag. In v12, you can reference these in the module so they have a context in the system and easier to manage. You cannot write to IO signals directly. Only control modules can write to IO output signals, channels or registers. So your reset would have to be done through either a bit in a command word (AO signale) or a discrete signal (DO Signal). In v11, each signal needs a DST as explained above.
I did some work with an E3 in our demo room and loaded the ESD into the system, created a device placeholder with signals and connected the device and downloaded. There are some configuration parmaeters in the ESD that DeltaV can configure in the device and upload. However, if you want to configure some additional logic in the device to make use of its local IO internally to the device, I think you need to do that with a configuration tool.
Andre Dicaire
In reply to Andre Dicaire:
Thanks much Andrew. I'm running 11.3 but I cannot find anything in the BOL regarding explicit messaging; if you can point me towards the documentation on that, I think I can figure out how to configure it easily using the information in A/B's manual on explicit messaging. If so, my strategy should probably be to bring in everything except the run confirm that way, so I'll use 1 DO to drive contactor, 1 DI for run confirm, and amperage and trip cause/status word can be brought in via explicit messaging. I will have about 30 devices I'd like to do this with. What sort of scan rate might I expect w/devicenet running at 500kbps on the explicit messaging?
It seems like that would determine whether I could even bring run confirm in as a diagnostic call (I don't care if it takes 5 seconds to indicate energized). I looked at the DIAG function block and also the Devicenet section of BOL but it did not seem to address explicit messaging?
I wasn't aware of the change coming in v12; previously I've attempted to consolidate tags into as large a word as possible to reduce DST count. Consolidation of I/O has the disadvantage of not being able to readily view it in Diagnostics so I can certainly see this is an advantage of v12.
It sounds like I will not need RSNetworx to configure the E3's, then, as from what you've described, this would only be required if I intend to run control logic on the E3's themselves.
Also I'm still interested in what parameters typically bring back in. I'll likely bring in average voltage as well as amperage if it doesn't cost a tag, or at least have a status faceplate where I can view it as a SCADA tag.
In reply to Frank Seipel:
Please ignore previous, I did not realize this feature was called 'Access Intelligent Field Device Diagnostics', and that an E3 module template is included. I have read the relevant BOL section. I see now that while diagnostic data can be read, at 1 scan/sec per port, if I have ~30 devices and read only trip state, average current, and % thermal load (3 parameters), it will take 1.5 minutes per update approximately. I'm now leaning towards just using 1 DI and 1 DO, the DI for running feedback, 1 DO for commanded state. I can then set up the polled I/O to send the average current, amperage, and/or % thermal load, and display it on detail and/or regular faceplate simply using SCADA tags. Reading the device status word using the 'field device' method seems prudent, because then I can fire a LOG EVENT to log the cause of an overload trip. If that's the only parameter I bring in it will update every 30 sec which is acceptable since a contactor is likely going to stay tripped for several minutes. Also, I should consider including a 'reset' of the E3 overload from DeltaV, because that will only involve a pulse write to a SCADA tag from a faceplate, and thus, not consume a tag because a module will not need to write to the reset bit.
Unless you want to use the new diagnostics external reference in a module for alarming/logging, it seems it's better to just configure the values as devicenet signals and display them as scaled SCADA tags (faster updates).
It is unfortunate Emerson has not provided the capability to enable/disable the diagnostic parameter reads dynamically/programatically; due to the slow scan rate, I'd much rather check if device is tripped (1 bit), and only then read the detailed diagnostic data, since it would be returned in 1 sec instead of >30 sec (assuming no other devices tripped), thereby providing faster feedback to the operators.
I see now that upgrading to v12 will actually result in tag savings if you use much devicenet with the new DST licensing scheme.
A couple of comments:
A RUN Confirm is not a diagnostic parameter. The Diagnostic parameters are intended for periodic verification or even trending, such as bearing temperature, or oil pressure etc. DeltaV exposes these in diagnostics, based on the defined parameters in the ESD. So rather than consume DST licensing, the data is available for free. SCADA tags also offer access to values, but you need to define the path via the hardware, and not with Device Tags. One way is to add a string parameter in your control module that holds the Device Name, or even the hardware path to the Device Signal you want to display in a detail display. When the Detail display is called up, you can use this string to build the path to the signals of interest using iFix variables. You could then have a common Detail display for all these similar devices.
Using the Diagnostic parameters moves this to the control module rather than into Detail display scripts. The data will be available immediately, but will update slowly.
V12 helps solve this by allowing you to have signals added to the module for fast changing values without incurring the DST.
Please note that you cannot issue a command from the Operator interface to a SCADA tag. You can read data directly from the IO location into the Operator interface, but to issue a command to the output, this must come from a control module.
Turning on Diagnostic monitoring with Dynamic references:
The diagnostic parameter is an external reference. I'm thinking you might be able to use a dynamic reference parameter. In a CALC Block, if your Tripped condition occurs, set the $REF field to the /&device_name/C/A/I path. Waith for the parameter.CST to go to 0 and then you can read the data from the parameter. This would allow you to enable/disable diagnostic parameter reads dynamically/programatically. I'm not sure if this will work as the dynamic reference was intended for Moduel to Module referencing, but if it accepts the reference path to the diagnostic parameter, this should do what you want. You can clear the $REF once you'r finished with it.
Let us know if this works for you.