Is it possible to send generic HART commands with 6ES7 134-6TD00-0CA1(Siemens AI 4xI?

AlfredoQuintero

Lifetime Supporting Member
Join Date
Feb 2015
Location
Yokohama
Posts
1,544
Hello:
Just posted a similar inquiry with regards to Rockwell HART master. Trying to figure out whether the Siemens offering is better.
I need to do a feasibility study for a project that needs to get process data and diagnostic data from a number of HART devices.
Would like to confirm if anybody has experience with 6ES7 134-6TD00-0CA1, especially experience with developing a program that can send generic HART commands to get diagnostic information from HART devices. The devices conform to HART 7.2 specification, so I am interested in knowing whether any variable supported by the device can be read from the Profinet controller application.
Thanks.
 
1. This Siemens forum discussion gives an example of reading the HART variables from Siemens ET200SP

https://support.industry.siemens.co...rt-variable-solved/216982/?page=0&pageSize=10

2. This Siemens forum discussion of reading HART variables in Siemen ST200iSP points out a 'bug' in method of the addressing when reading secondary or tertiary HART values:

https://support.industry.siemens.co...00isp-with-s7-1500/253623/?page=0&pageSize=10

3. An attached page lists the Siemens field devices that talk HART and methods of connecting to HART devices: Siemens distributed I/O.


4. I'm not sure where the attached table came from


5. For 30 years I've heard claims of "advanced diagnostics" available from HART (by the instrument vendors) but outside of the use of "Asset Management" software ($15-25k) at the DCS level, I have never seen or heard of an example of such. And I've looked and listened. Maybe it can be done, but it isn't clear to me, how that's accomplished.

If you manage such, please inform the community.
 
Last edited:
If you are open to a different platform for this job, Honeywell has released a universal I/O (UIO) card that can read HART variables.

The two Honeywell platforms that use the UIO card are
- the Honeywell ControlEdge PLC which uses Codesys type (licensed) development software with all 5 programming languages.
- the Honeywell HC900, a PAC, that uses Function Block developement software, no ladder, no structured text. (R7.10 or above for HART)

The UIO cards are 8 point cards, called universal because each channel can be programmed for either 24Vdc DI, 24Vdc DO or analog 4-20mA AI or AO. The analog points support HART.

The HC900 HART function blocks support HART commands 3 (read HART variables) and 48 (read status). The Function block sections from the manual are attached.

If you're looking for additional status diagnostics then it seems you need to research what status bytes the device offers and then determine how the device's bytes line up with the returned bytes in the Cmd 48 FB.

I'm clueless on the PLC other than the fact that it uses the same UIO card (and rack and power supply as the HC900). Presumably the Function Blocks are the same.
 
JesperMP & danw, thanks very much for taking the time to find this information for me. I need to go through (and I will, for sure) this documentation, but it does seem to be possible to encapsulate HART commands by means of acyclic read and writes. I do have Siemens PLC and the ET200, so for testing I only need to buy the HART master module, which I will be doing only if the customer gives me an order. I am planning to use Codesys for the project as the customer wants to have a Windows application. Codesys has good support for acyclic Profinet communication. Again, thanks very much. If I get the business I may post an example of the solution, in case it is useful for someone else.
 
5. For 30 years I've heard claims of "advanced diagnostics" available from HART (by the instrument vendors) but outside of the use of "Asset Management" software ($15-25k) at the DCS level, I have never seen or heard of an example of such. And I've looked and listened. Maybe it can be done, but it isn't clear to me, how that's accomplished.

If you manage such, please inform the community.
danw: I share the same feeling. For over 30 years most PLC applications use only cyclic communication to get process data and the acyclic stuff is for the HMI, SCADA or "Asset Management" software which commands those figures you mention. My customer needs to get data from HART IO and do some AI processing. I do not know the AI part, but I am offering them to develop a Codesys Profinet application that can get more than the PV from the slave to the PLC application. The beauty of Codesys is that the data can be mapped to its OPCUA server and do the AI with an OPC UA client. Or he can do it directly in Codesys. Being HART IO millisecond performance is not an issue, so even the RevolutionPi might do (just configured 2 of those for a customer and I quite like them). Neither this application will be performing control, just this data gathering. I am looking forward to getting this project. If I get the project and crack it, for sure I will share with the community one example. But please be patient. Have not got the job yet.
 
In the PCS7 side of Siemens, it is very easy to read/write Hart Variables. You just have to designate the memory when you add the I/O module to a project. However, I have never seen anyone be able to read anything other than PV's via the control system. You can use PDM but that is an add on, asset management type of tool.
 
I have periodically searched the Siemens user forum for 'HART' and found that the bulk of threads were PCS7 related, a few instrument related, only a couple PLC that were not PCS7 related. it appears to me to be what you (Ken) are confirming - reading any of the HART PV's is pretty straightforward with PCS7.

But that still leaves the "Advanced diagnostics" hanging high and dry.
 
But have you ever seen someone trying to read variables other than process value and not succeeding, or is it that those who need those variables use the PDM add on, without attempting to write the program?
 
Ken, Jesper and danw: I said I would provide follow-up on this issue. It seems that I will not be able get the 6ES7 134-6TD00-0CA1 so I will not be able to do the test of accessing HART variables with RDREC and WRREC commands, as I said I would. The reason is, after web call with the customer this week, I learned the application requires reading HART variables from perhaps dozens of HART devices connected to the Profinet/HART multiplexer (Siemens can support 32 slots with 4 HART masters channels). So it would take a lot of time to send the REDREC or WRREC to let's say a configuration with 40 HART devices.
We are currently thinking of using the Phoenix Contact GW PL ETH/UNI-BUS which is the only HART IP/HART multiplexer registered in the FieldComm Gr products website. I am still learning about this device and learning about HART IP protocol (of which there is very little technical information freely available). My company will become member of FieldComm Gr if we get the job and get this specification, so at the moment I have been able to learn only very little about HART IP. It seems the pass through command as supported by a standard HART IP/HART multiplexer allows for a HART IP client to request in one command HART variables for HART devices connected to different HART modems of the multiplexer. If this is doable, then it should be possible to more efficiently monitor dozens of HART nodes using a bespoke HART IP client application.
Anyways, this is the situation at the moment, and so I felt it would be a bit rude (specially to danw) not to let know about testing 6ES7 134-6TD00-0CA1. I still would like to test this product and I could if I could afford this, but it costs over EUR 600 and for a project that I still may not get, and for which I may not use this product even if I get the job, I really can't afford buying it for test. Anyways, if there is interest, I can report further on our testing of this idea if we get the job, of course.
 
HART IP protocol (of which there is very little technical information freely available).
You'd think that there'd be a couple app notes out there just to stimulate the market, wouldn't you?

HART IP. It seems the pass through command as supported by a standard HART IP/HART multiplexer allows for a HART IP client to request in one command HART variables for HART devices connected to different HART modems of the multiplexer. If this is doable, then it should be possible to more efficiently monitor dozens of HART nodes using a bespoke HART IP client application.
I had not heard that such an efficient command existed. If so, yes, that would decrease your implementation work load.

so I felt it would be a bit rude (specially to danw) not to let know about testing 6ES7 134-6TD00-0CA1.
Absolutely no need to apologize for not paying for a test stand for which you don't have a confirmed project to bill it to. We all have look at the business aspects of what we do.

Anyways, if there is interest, I can report further on our testing of this idea if we get the job, of course.
I eagerly await anything you learn about HART functions involving getting and interpreting diagnostics without an Asset Management software package.

Separate topic - HART (OPC) server
I don't know if your system architecture includes an OPC client or if your system can tolerate a Windows box to run an OPC server, but there is the HART server available that is a HART OPC server that can get the HART data and diagnostics to an OPC client. The FieldCommGroup's blurb on HART server is attached as single page Word doc.
 
You'd think that there'd be a couple app notes out there just to stimulate the market, wouldn't you?

I had not heard that such an efficient command existed. If so, yes, that would decrease your implementation work load.
Yes, one would have thought there would be some technotes so people can take interest in the technology. The only information that has some technical details as opposed to marketing mumbo-jumbo only is this article in the Wireshark wiki.
https://gitlab.com/wireshark/wireshark/-/wikis/HART-IP
In which they posted this very useful although unfortunately too short Wireshark trace.
https://gitlab.com/wireshark/wiresh...ort__/attachments/SampleCaptures/hart_ip.pcap
At the end of my post I will show an interesting HART IP "pass through" response from that very Wireshark trace.
Separate topic - HART (OPC) server
I don't know if your system architecture includes an OPC client or if your system can tolerate a Windows box to run an OPC server, but there is the HART server available that is a HART OPC server that can get the HART data and diagnostics to an OPC client. The FieldCommGroup's blurb on HART server is attached as single page Word doc.
I cannot use this because I would have to setup a Widnows PC with with 32 USB or RS232C HART modems. This is not feasible. We do need a compact, industrial-grade Ethernet based multi-HART master system. That is why we are thinking of this (P/N:GW PL ETH/UNI-BUS) Phoenix device which is actually registered in the FieldCommGr website.
Look at this HART IP reply from the trace in the wireshark wiki. Many variables from the same HART device returned in one response. That response is from one HART device. I just do not know if a multiplexer such as GW PL ETH/UNI-BUS can do the trick from HART devices connected to different HART modems from its backplane. Trying to get support from Phoenix but the local support engineers are not familiar with HART or HART IP, so it may take some days. But will keep you posted. Thanks for the feedback. (y)

2021-06-06_HART_IPトレースサンプル1.jpg
 
danw, hello again.
Quick update with information which may not be news for you, but it was something I did not know about until just a few days ago.

https://www.thorsis.com/en/diagnostic-tools-en/isnet-lite-2/

There is this company in Germany, Thor Systems, which I think used to be called IFAK. They have a very interested remote IO system which on the system side is Ethernet with support for HART IP, Modbus TCP and Profinet IO, and with a number of IO modules including HART, Profibus PA and FF. The HART module is very interesting because it is possible to configure bespoke HART master commands that can execute cyclically and map the input from the HART IO in configured Modbus addresses, so a Modbus TCP client can access this data. But more relevant to my customer's application's requirement, it is also possible to instead of cyclically executing the HART commands, have the commands triggered by the values in registers on the Modbus database, so the Modbus TCP client can trigger those commands. I am having a web call with the customer to recommend this product. I learned the Phoenix Contact device can only support one TCP port in the HART IP server, so what we need to do which is sending commands to several HART devices will take too much time. It is not possible to send HART pass though commands to different devices. All that can be done with the Phoenix Contact is send several commands to one HART device, as per HART IP specification. That would be OK if only occasionally we would need to get some diagnostic value, but this application needs to read several HART variables from several HART devices almost simultaneously. As i told my customer, something very difficult for HART.

The other big advantage of the isNET system from Thor Systems is that we intend to use Codesys which has no HART IP client. I was planning to embbed the HART IP client application from the FieldComm Gr (whihc is a Windows application) into Codesys. But with the isNet product we need Modbus TCP and Codesys has already excellent support for Modbus TCP; hence we can shed weeks of development. Very interesting solution. Let's see if we get the job and do some testing with this product.

isNet_Modbus.png
 
Last edited:
Very intriguing.

Where did you get the screen shot from? I did not see that in the isNet Line Modular manual in the Modbus section.

Off topic comment - how the world changes over time.

The Thorsis company is in Magdeburg, Germany.

I spent a couple years in the US Army on the west/east German border as part of NATO forces in the early 1970's. On the edge of town was a road that led to Magdeburg, with the typical black on yellow Magdeburg road sign, a left over from the WWII era because the road was blocked by the impassable border (watchtowers, dogs, mines, military patrols) 1/2 Km further down. My father was stationed in Berlin right after WWII ended and knew Magdeburg as the source of Soviet jamming of allied radio frequencies. When I was in Germany, it was a tense period of the cold war and I assumed my kids and grandkids would live with a divided Germany occupied by foreign military powers. Now Magdeburg is part of united Germany and a source of sophisticated process electronics. I never would have dreamed that in 1973.
 
Very interesting story. I have been to Mageburg twice, helping customers certify Profinet devices when ThorSys was called IFAK. Beautiful town. If I remember correctly, Fraunhofer has one of their labs there. Beatiful town.

I got this one manual from Endress+Houser Japan. I also got the actual software from ThorSys. It is a run only program and requires no license.and no stallation. Very similar to the Phoenix Contact tool.

If you PM me I can provide them to you.
 

Similar Topics

https://literature.rockwellautomation.com/idc/groups/literature/documents/um/1794-um063_-en-p.pdf Hello. Trying to figure out if it would be...
Replies
1
Views
1,792
Hi guys, Awhile back I mentioned in another thread that my client wants to use an existing Profibus connection between the water treatment panel...
Replies
0
Views
1,411
I have an application where I want to send text alarms from a PLC-5/40E to a cell phone. I plan on using the AB paging modem 9300-RAPMKIT...
Replies
25
Views
12,901
Hello All, I need the ability to remotely reboot a Red Lion CR3000 HMI. Due to some graphics issues when the database is updated the HMI must be...
Replies
4
Views
204
Hello The plant is running and there is no shutdown nowadays therefore I can add 1734- AENTR and its card while PLC is in Run? I do not wanna...
Replies
8
Views
332
Back
Top Bottom