Hello everybody,

I want to connect to Speedtronic MarkV or MarkVI or MarkVIe with ethernet and read/write data from/to it with Python. I just want to share whatever I found and find a way to do this. May it will be useful for others as well.

The first step, I just want to do it and I never test it before. here is my program (get it from chatGPT) to read from a spintronic MarkVI control system with Modbus:
============================================================================================
from pymodbus.client.sync import ModbusTcpClient
# Define the IP address and port of the Speedtronic Mark V system
ip_address = '192.168.0.1'
port = 502

# Connect to the Speedtronic Mark V system
client = ModbusTcpClient(ip_address, port)
client.connect()

# Read a register value
register_address = 100 # Replace with the actual register address you want to read
response = client.read_holding_registers(register_address, 1)
value = response.registers[0]

# Print the value
print(value)

# Disconnect from the Speedtronic Mark V system
client.close()
============================================================================================


and the code to connect and write data in Speedtronic markVI:

============================================================================================
from pymodbus.client.sync import ModbusTcpClient

# Define the IP address and port of the Speedtronic Mark V system
ip_address = '192.168.0.1'
port = 502

# Connect to the Speedtronic Mark V system
client = ModbusTcpClient(ip_address, port)
client.connect()

# Write a value to a register
register_address = 100 # Replace with the actual register address you want to write to
value = 12345 # Replace with the actual value you want to write
client.write_register(register_address, value)

# Disconnect from the Speedtronic Mark V system
client.close()
============================================================================================

these codes are not tested and I don't have access to a MarkVI for now (but I will soon). I just want to prepare for testing.
Does anyone have such experiences? Is there any simulator for Speedtronic (any version)? I will appreciate it in advance if share them with me.

 

GE uses proprietary communication protocols for issuing commands, receiving alarms and operating data from Mark* turbine control systems (including the Speedtronic Mark* IV and Mark* V; GE dropped the Speedtronic label because it was copyrighted by a tractor manufacturer).

MODBUS is, at best, a work-around. Generally, at least in the Mark* world, it doesn't time-stamp alarms or data. It's possible to received changes of state of logic signals associated with Process Alarms, but it's going to take work to manually add the Mark* Alarm Text to any display method. When working with high-speed rotating equipment time-stamping is CRITICAL to troubleshooting. There are (and were) a LOT of sites that used MODBUS to communicate with a GE Mark* HMI using a plant-wide DCS system to be able to operate, collect data from and monitor operation of Mark* control systems. They were all pretty much less than adequate at best, especially when it came to trying to troubleshoot things like fuel control valve instability or steam control valve instability or load instability or nuisance and intermittent perceived problems--and they ALL insisted the DCS could do high-speed troubleshooting and that it was the Mark* that was the problem. (NOT FAKE NEWSFLASH: The Mark* was never found to be the problem in any of these cases.)

GE, until the Mark* VIe, never allowed MODBUS communication directly with a Mark* turbine control system--it was ALWAYS done via the GE Mark* HMI.

(NOTE: I'm NOT speaking of any of the hybrid perversions of Mark* IV and Mark* V and Mark* VI ("Life Extensions" and "Platform Upgrades" and the like the OEM foisted on older control system users, mostly using Mark* VIe hardware and Mark* VIe-compatible hardware. I'm ONLY referring to the original versions of those control systems.)

Some recent (post-product life) Mark* V control system upgrades have used Ethernet to ARCnet methods of communicating with Mark* V turbine control systems (because either coaxial cable or ARCnet fiber hubs were required since the communication protocol at the Mark* V was ARCnet).

Mark* VI uses Ethernet (TCP/IP) for communication--but it uses a proprietary method of communication developed by another GE division for commands and data and a different proprietary method for alarms (Process & Diagnostic) which has been reverse engineered but it's not easy.

To my knowledge there has been minimal third-party success with receiving alarms from Mark* VIe with any communication method, and there HAS BEEN a LOT of reverse engineering tried for this.

Mark* VI and Mark* VIe have both been capable of OPC communication for years, and I even think there's one well-known OPC software publisher that has developed a way to communicate with Mark* V HMIs using OPC.

The reason for this should be pretty obvious. The Mark* controls and protects multi-million dollar high-speed rotating machines, and in some cases these machines drive hydrogen-cooled generators. And, they all burn hydrocarbon-based fuels, which are dangerous in their own right. If GE allowed anyone to have unlimited access to command and control these machines and made just one little mistake (a bit set to the wrong value) the results could be disastrous, even deadly. It's as much about protecting their control systems as it is about protecting the people who operate the equipment the control systems control and protect.

I'm not saying it's impossible, but I am saying that without a lot of reverse engineering (which some companies have done for Mark* IV, Mark* V and Mark* VI and have worked long and hard with the Mark* VIe) this is a very difficult project, even for an AI bot.

But, hey, if you can handle the liability of developing and implementing what you're intending, and the testing which should be done to validate and prove the product, go for it.

There was a "suitcase simulator" for Mark* V, and there was a Schroff box-based simulator for the Mark* VI. Nothing for the Mark* IV and if you can get your hands on a Mark* VIe processor pack and all the software and manuals you could implement a simulator-like environment for the Mark* VIe. But, even that's going to take time to set up and get working--probably several months without any prior experience. You'd probably do better if you had working HMIs to observe and capture communications from (using various protocol "sniffing" software--which has its own learning curve).

That's all I got; I've been away from the Mark* for over a year and I have not tried to keep up with them at all. I was privileged to have had the opportunity to work with them and with the developers of the control systems, but that's all in my

 

Dear WTF?,
Thank you for your answer. I think an OPC server, like the "Matrikon OPC server" can be useful. I can read data from the OPC server (At least I hope so), And one more thing, the sample rate that I want to check about 30 "real" and "boolean" data" is "1 second" which means I want only get a few data each second, and it's not a big deal ( not 10 ot 40 ms cycle time of Speedtronic). but, the only important thing is how can I connect to the control system at the first


let's see what happens.

 

update :
I found this OPC server for MARK VI and MARK VIe. I mean the first step is to read data and tag from Speedtronic:
https://www.matrikonopc.com/opc-drivers/opc-mark-vi-direct/base-driver-details.aspx

and this for MARK V:
https://www.matrikonopc.com/opc-drivers/opc-ge-markv/base-driver-details.aspx

To read data from a Mark VI Speedtronic system using an OPC server, you'll need to follow these general steps:

1. Set up the OPC Server: Install an OPC server that supports communication with the Mark VI Speedtronic system. GE typically provides the necessary OPC server software for their Speedtronic systems.
2. Configure OPC Server: Once the OPC server is installed, you'll need to configure it to establish communication with the Mark VI Speedtronic system. This involves specifying the connection parameters such as the IP address or hostname of the Speedtronic system, the communication protocol (e.g., Modbus TCP, OPC DA), and the specific data points you want to read.
3. Identify Data Points: Determine the data points (tags, items, or variables) that you want to read from the Mark VI Speedtronic system. These could include process values, alarm statuses, operating conditions, etc. Consult the documentation or manuals for the Speedtronic system to find out the available data points and their names.
4. Connect to the OPC Server: Create a connection to the OPC server from your application or OPC client software. Most OPC clients provide easy-to-use interfaces for connecting to OPC servers. You'll typically need to enter the OPC server's address and credentials (if required) during the connection setup.
5. Browse and Read Data: Once connected, you can use the OPC client software to browse the available data points in the Mark VI Speedtronic system. The OPC server will expose these data points as OPC tags or items. Select the data points you want to read and request their values from the OPC server.
6. Handle Data in Your Application: After reading the data from the OPC server, you can process and use it in your application as needed. This could involve displaying the data, performing calculations, or storing it for further analysis.

If anyone has any experience with how to config the OPC server and what must I do on the Speedtronic side or any basic requirements, It would be a great help.

 

You WILL NOT be communicating directly with the Mark* using an OPC server; you will be communicating with a GE Mark* HMI that retrieves the data from a Mark* or Mark*'s and makes it available to the OPC server application. I believe timestamping is done using the GE Mark* HMI's time (which should be the same as the Mark* if a network time system is in use on the UDH), but that may have changed in newer perversions of the GE Mark* HMI.

And, this is not Python.... and probably doesn't lend itself to AI configuration....

 

You WILL NOT be communicating directly with the Mark* using an OPC server; you will be communicating with a GE Mark* HMI that retrieves the data from a Mark* or Mark*'s and makes it available to the OPC server application. I believe timestamping is done using the GE Mark* HMI's time (which should be the same as the Mark* if a network time system is in use on the UDH), but that may have changed in newer perversions of the GE Mark* HMI.

And, this is not Python.... and probably doesn't lend itself to AI configuration....

Thanks for your response,

I will check it and share it here. I know that Mark VIe can create a custom OPC server that any client (python or any programming language) can connect to it. I didn't test it but I read it in the MARK VIe manual.