4 to 20 mA in Cimview?? HMI?? MarkVIeS??

Hello professionals
This is 1st time i am asking something here as i go through very informative discussion on this forum in past fiew days.
I was working on MarkVIeS system and i just wonder is there any way to see 4 to 20 mA signal on its HMI or we cannot?? On DCS its possible but i dont know if i can do same on Cimview or not..
 
Just guessing the Mark* and the DCS are different systems.

If the Mark* can see a signal, then the Cimplicity HMI can see it if PROPERLY CONFIGURED to do so.
They are different system and is properly configured and i can see process variable live values in Bar, %, degree C, or whatever the PV is but may be there is way or place where we can see 4 to 20 mA also.
 
AFAIK, in MarkVIe systems the analog conversion and translation to engineering units is performed by the IO Packs. This way, the controller always acts on engineering values not electrical values (mA, for example). The conversion to engineering units is performed by a linear mapping defined by the channel configuration (high/low limits) in the ToolboxST software. Whenever you need different units for the value read, you need to perform an explicit conversion. This can be done in Cimplicity but the best would be to do it in controller logic using conversion blocks and appropriate format specifications for all signals. The result of the conversion is then made available to a Cimplicity screen through a new signal.
 
Yes, that is correct, the conversion is done directly on the IO module. you would need to write logic to convert it back to 4-20.

See below the places where you define Low input/value and High input/value.

1620744737445.png
 
ME42,

Would it be possible to use one of the "direct" TCP/TP tools (I cannot remember the name of the one GE uses) to check the value directly in the I/O Pack?

But, I think the original poster is unclear with his need and is over-simplifying the situation--at least that's my read of the request. (I've been wrong before, and I will be wrong in the future!)
 
@CSA ,
Sorry for jumping into the conversation. I think you mean using one of the WorkstationST services to check the mA value in the IO Pack. If that's the case, it is not possible as the value the IO Pack transmits to the IO Network is already in engineering units. That value is what gets to the controller and what you can monitor from any external tool (ToolboxST or WorkstationST). All data in the IO Net is handled automatically by the configuration of the controller and the IO Packs, and it's not available to the user.

I also think the post is a bit unclear but I don't want to bias the conversation. Hope the information I provide is of any help!
 
luissz,

Don’t ever apologize for offering your help and experience. EVER. We value it and are grateful for your contributions.

I was referring to a command line utility, but my mind (stuck in glorious Mark IV land!!!) is not working properly today.
 
Un_gineer,

Let's try this tack.

You seem to be saying there's a value on the DCS which comes into the DCS from a 4-20 mA transmitter, you'd like to see that value on the HMI for the Mark VIe/VIeS.

IF the Mark* and the DCS share data using MODBUS or GSM or some other protocol/method it might be possible to send the data from the DCS to the Mark* HMI and display it on the Mark* HMI. I'm no MODBUS guru (by any stretch of the imagination!) but that's one possiblity.

Another possibility is to configure an unused ("spare") 4-20 mA input to the Mark* and then run wires from the DCS to the Mark* to connect the signal in a series configuration to both the Mark* and the DCS. (That depends on the value of the dropping resistor on the DCS and the one on the 4-20 mA input channel of the Mark* being configured for this purpose; most transmitters have a maximum resistance of 500 ohms they can power before the signal degrades and can no longer be proportional.)

HOWEVER, then the Mark* has to be configured to add this new input signal to the EGD (Ethernet Global Database) so that the HMI (and CIMPLICITY/PROFICY Machine Edition) on the HMI can get the information and then it has to be added to and configured on the CIMPLICITY CIMVIEW display page. AND, if there is more than one node/device on the GE UDH (Unit Data Highway) sometimes that can lead to LOTS and LOTS and LOTS of work, which can lead to lots and Lots and LOTS or unintended problems (especially if there aren't EXCELLENT back-ups of the HMI(s) available to use to recover from problems). AND, you need a person who is experienced and knowledgeable in the type of GE system you have at your site--and there are MANY versions/perversions of GE systems at sites and there are very few people who know all of them or could figure them out if they didn't. Because GE doesn't publish any of this stuff like they should (adding signals and configuring the systems).

So, if this is what you're trying to do--get a signal from the DCS to display on the Mark* HMI, there are possibilities--but none of them are easy (though MODUS or GSM probably presents the easiest method of the two described above--if your site uses either of those).

Best of luck!
 
Yes, that is correct, the conversion is done directly on the IO module. you would need to write logic to convert it back to 4-20.

See below the places where you define Low input/value and High input/value.

View attachment 1258
Yes I already checked this point while going through this problem. So as per my understanding we have to configure the controller as per mA or as per process variable (which is normally the case) but we cannot check both the values at the same time
 
Un_gineer,

Let's try this tack.

You seem to be saying there's a value on the DCS which comes into the DCS from a 4-20 mA transmitter, you'd like to see that value on the HMI for the Mark VIe/VIeS.

IF the Mark* and the DCS share data using MODBUS or GSM or some other protocol/method it might be possible to send the data from the DCS to the Mark* HMI and display it on the Mark* HMI. I'm no MODBUS guru (by any stretch of the imagination!) but that's one possiblity.

Another possibility is to configure an unused ("spare") 4-20 mA input to the Mark* and then run wires from the DCS to the Mark* to connect the signal in a series configuration to both the Mark* and the DCS. (That depends on the value of the dropping resistor on the DCS and the one on the 4-20 mA input channel of the Mark* being configured for this purpose; most transmitters have a maximum resistance of 500 ohms they can power before the signal degrades and can no longer be proportional.)

HOWEVER, then the Mark* has to be configured to add this new input signal to the EGD (Ethernet Global Database) so that the HMI (and CIMPLICITY/PROFICY Machine Edition) on the HMI can get the information and then it has to be added to and configured on the CIMPLICITY CIMVIEW display page. AND, if there is more than one node/device on the GE UDH (Unit Data Highway) sometimes that can lead to LOTS and LOTS and LOTS of work, which can lead to lots and Lots and LOTS or unintended problems (especially if there aren't EXCELLENT back-ups of the HMI(s) available to use to recover from problems). AND, you need a person who is experienced and knowledgeable in the type of GE system you have at your site--and there are MANY versions/perversions of GE systems at sites and there are very few people who know all of them or could figure them out if they didn't. Because GE doesn't publish any of this stuff like they should (adding signals and configuring the systems).

So, if this is what you're trying to do--get a signal from the DCS to display on the Mark* HMI, there are possibilities--but none of them are easy (though MODUS or GSM probably presents the easiest method of the two described above--if your site uses either of those).

Best of luck!
CSA thanks for the reply. I guess i did not ask the right question. let me explain it again. I have a 4 -20 mA transmitter which is connected with DEH panels (input module in MarkVIeS). In ToolboxSt it is configured as process variable as shown in @ME42 's shared ss. I just want to see that 4 to 20 mA without changing any configuration in ToolboxSt. as in DCS if this is the condition i can see 4-20mA signal in its Logic and as well as HMI. Is there any posibilty we can do same in MarkVIe?? although they are different systems and work on different protocols and configurations.
 
Un_gineer,

I'm sorry; I must seem really dense. And to be perfectly clear, I think there may be some changes to or aspects of Mark VIeS that I am unaware of since I left The General.

I think the thing which is causing a lot of confusion is your continued reference to "seeing that 4-20 mA" ----. To many of us that means you are trying to see the value of the input current, as in bits/bytes the I/O Pack then converts to engineering units (pressure; temperature; level; flow; etc.).

In my experience, and it's been a while since I've had the good (mis)fortune of working on a system with Mark VIeS, the Mark VIe and Mark VIeS "devices" (and their associated values (logic or real)) are all in the same ToolboxST "project." So, you have access to all the information using one single instance of ToolboxST, you just might have to change devices to see the values (in engineering units!) for different devices. OR, you might be able to use a Watch Window or even a Trender window to put the value on a display so you can see it in ToolboxST. To see any Mark VIe/Mark VIeS signal's value--in engineering units!--on the HMI (using CIMPLICITY or PROFICY Machine Edition or whatever is being used at your site for the graphical display of the process and data) it has to be added to (or previously added by someone) to the EGD (Ethernet Global Database). As per my understanding, data (signal values (in engineering units) and commands) are transmitted between the HMI and Mark VIe/Mark VIeS panels using the EGD protocol. Once at the HMI, ControlST (or WorkstationST, or WTFE) then makes that information available to CIMPLICITY or PROFICY Machine Edition (through different methods and protocols based on when and how the HMI is configured and what version/perversion of software is used on the HMI). BUT, the only way to see a signal's value--in engineering units!--on a GE Mark* HMI is to first get the signal to the HMI via EGD (over the UDH, Unit Data Highway), so that software on the HMI can then make it available to the graphical display program on the HMI.

Are both the Mark VIe device AND the Mark VIeS device in the same ToolboxST project? Because if they are, then you should be able to see the Mark VIeS's 4-20 mA input's engineering unit value (pressure; temperature; level; flow; etc.) in ToolboxST, and you should be able to see it with Watch Windows and Trender.

Do you know how to check to see if a signal's engineering unit value is on the EGD? Because, unlike other PACs (Programmable Action Controllers) or DCSs the Mark* doesn't communicate natively or directly with the HMIs used to monitor and control the devices (turbines; balance of plant equipment; etc). As far as I know, GE has used--and is still using--EGD to transmit data and commands between HMIs and the Mark*(s). That's why I always try to dissuade people from thinking of the HMI as THE Mark*, or even part of the Mark*--because it doesn't natively communicate directly with the Mark*. So, that means it can't access any and every signal (in engineering units) in the Mark* to display on the HMI; any signal (in engineering units) and quickly and easily display the value (in engineering units) on the HMI display.

Any signal which is desired or required to be displayed on the HMI's graphical display (CIMPLICITY, PROFICY Machine Edition) has to added to the EGD in order to be available to the HMI to then put it in the format/protocol the graphical display application (CIMPLICITY or PROFICY Machine Edition) can display it on the HMI monitor display.

In other words, CIMPLICITY and PROFICY Machine Edition cannot speak directly (what I'm calling "natively") to the Mark* to get signals (in engineering units) to display them on the monitor. The signals have to be made available to the CIMPLICITY or PROFICY Machine Edition application by "conversion" software on the HMI which gets the information via EGD from the Mark* and puts it in a format that CIMPLICITY and PROFICY Machine Edition can display it on the HMI.

I have been wrong before, many times, and I may be wrong about some aspects of this complicated method GE uses of HMIs and Mark* and ToolboxST and CIMPLICITY/PROFICY Machine Edition. (And heaven forbid someone askes about how alarms and events are handled!!! Because that's an even bigger--and very proprietary--and deeper rabbit hole...)

Again, it seems your continued used of "see that 4-20 mA" ---- (I'm using the dashes because I don't exactly understand what you're referring to--bits/bytes; the actual current; or the scaled value in engineering units (pressure; temperature; level; flow; etc.)). And, in my experience, the ToolboxST project for a site with Mark VIe and Mark VIes devices (turbines; driven devices; auxiliaries; balance of plant devices; etc.) are all in the same ToolboxST .tcw file (the "project") so you should be able to use ToolboxST to see any value of any device which exists in the same project. You might have to change devices to do so, but you should be able to use Watch Windows or Trender to see the value (in engineering units!) of any signal that exists in the same ToolboxST project (.tcw file).

If that's not the way your site is configured, we are all at a loss, I'm afraid. If you're trying to see something other than the engineering units for a particular 4-20 mA input, then we are all at a loss.

And, again--I've been wrong before, and I will be wrong in the future. I may have some very important aspects of Mark VIe communications and configuration wrong--and it wouldn't be the first time. I welcome any and all clarifications or corrections; I learn a lot from these posts on Control.com.

Hope this helps!!!

By the way, what does DEH stand for (you mentioned "DEH panels")???
 
Curious_One,

There's some history behind why GE uses CIMPLICITY/PROFICY Machine Edition as a graphical user interface. And because GE Salem didn't "invent" CIMPLICITY (which has become PROFICY Machine Edition) they didn't want to "give the keys to the Mark*" to CIMPLICITY to speak directly (natively) with the Mark*. The equipment is EXPENSIVE and the operations and processes are dangerous. If not done correctly, the results can be deadly or worse, not to mention expensive.

And, further, GE is understandably reluctant to let anyone send commands directly/natively to a Mark* using any means or protocol. (Yes they allow the use of MODBUS and GSM (a proprietary GE protocol), but those are the exceptions and not the rule. I can tell you horror stories (true horror stories--not fictional, movie horror stories, but just as scary!) about even using contact connected directly to the Mark* for commands and how that has been bungled by A/Es and DCS programmers/control system integrators which led to lawsuits and all manner of threats and shouting and near fisticuffs. GE just can't test every version of control system interface and graphical user interface, and writing a spec to allow any third-party system to control and send commands to and manage alarms on a Mark* is just very, Very, VERY time-consuming. (Not to mention when things change--and they ALWAYS change at GE Salem--the documentation would have to be updated. And THAT never happens. Engineering DOES NOT own the documentation; that's someone else's job. And it's even the someone else who has to learn about changes to document them; there's no procedure for communicating changes to anyone else (documentors; field service personnel; Customers; etc.). You find out when you find out.

Finally, there's the concept of intellectual property. Got to protect that intellectual property at all costs. Don't want Customers specifying other control operator interfaces; that's GE's entitlement (their words, not mine).

So, the whole interface with CIMPLICITY/PROFICY Machine Edition is twisted and sordid and complicated. And, because everything related to it is basically a work-around and none of it is documented when it changes (and it's always changing), it's just very hard to keep up with. When I was a field engineer with GE, I gave up on trying to keep up with changes and procedures related to HMIs. I would develop a list of all the problems I found during commissioning and a week or two before first fire I would send that list back to the factory, and in about 24 hours I would get all the fixes--sometimes even in the same day! And, I would have to have spent man-weeks trying to figure it out all by myself--and it's my belief that's NOT the field person's job to fix factory issues (and there were FAR MORE issues with HMIs and displays than with the programming and logic and parameter settings in the Mark*)--it's the factory's responsibility. I always hoped that by sending the issues back to the factory to get fixed that someone would change the process/procedures and fix them before they got to the field. But, that never happened. So, a lot of the issues I would identify would be found on many machines for many years--makes it easy to "find" problems like that. And, again, my job was to commission the equipment so the units ran without nuisance alarms and were properly protected--not to fix factory HMI problems.

Anyway, yes; some FDIs (Freaky Device Interfaces) were created when it was decided to use CIMPLICITY as the graphical user interface on GE Mark* HMIs. Which leads to lots of confusion and myths and problems. Throw in a language difference, and well, things gets muddled very quickly sometimes and take a long time to sort out.
 
There's some history behind why GE uses CIMPLICITY/PROFICY Machine Edition as a graphical user interface. And because GE Salem didn't "invent" CIMPLICITY (which has become PROFICY Machine Edition) they didn't want to "give the keys to the Mark*" to CIMPLICITY to speak directly (natively) with the Mark*. The equipment is EXPENSIVE and the operations and processes are dangerous. If not done correctly, the results can be deadly or worse, not to mention expensive.
A few corrections. CIMPLICTY and Proficy Machine Edition are different products that came in from the same company that GE bought decades ago. PME is the IDE for the former GE PLC product line, and is now an Emerson product. CIMPLICTY is now a GE Digital product, along with Proficy Historian (which may have been renamed, I lose track--it got folded into the Predix product line).

The Mark VIe as a system was designed so that it was not dependent on CIMPLICITY in any way--some product lines like Wind and Oil and Gas have other HMIs and SCADAs, and the plant DCS is often not a GE HMI.

There are good technical reasons for CIMPLICITY (or any other HMI) not directly connecting to the Mark VIe. Communications are aggregated through the WorkstationST OPC server, minimizing the number of TCP/IP connections to the controller, each of which consumes a little of the low-priority idle time on the controller. Even for the sessionless, periodic protocols like the EGD where we don't have to worry about the controller resources, WorkstationST aggregates metadata from the ToolboxST configuration that the controller doesn't have (for space and performance reasons) and provides richer client protocols like OPC UA and OPC DA. WorkstationST also normalizes communcations, aggregating data from Mark IV, Mark V, and Mark VI units in retrofit and upgrade scenarios.

Obviously not all communications can be routed through WorkstationST, so direct connection to the controller via Modbus and other protocols is also common, especially to the plant DCS. This is where a lot of the complexity is, largely because all of the metadata describing the signals are lost and have to be manually configured on the DCS side. Manual always == mistakes.

Back to the OP, there isn't a good answer. Raw 4-20 values are not typical in the Mark VIe for similar reasons to why Modbus links are bad--manual configuration of units and scaling in application code lead to human error. It is one of the "guard rails" in the Mark VIe to protect quarter billion dollar gas turbines, and tends to tick off PLC programmers who are more used to raw data and doing everything themselves. (It is called "primitive obsession" in programming). You could set the scaling for an I/O point to be exactly the same as the raw electrical input, then do the scaling yourself later. I'd re-examine your reasons for doing so first! Even if the plant DCS has its own way of scaling raw I/O inputs, isn't it better to bring in the scaled engineering value? Not my call, but it sounds like a "code smell" to use another programming term.
 
Top