https://community.element14.com/technologies/industrial-automation-space/ en-USTelligent Community 12https://community.element14.com/technologies/industrial-automation-space/f/forum/57027/e14-community-recommendation-for-modbus-tcp-client/236227Wed, 24 Jun 2026 21:58:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:e210b9d9-ab8e-4354-9486-57290c70e809colporteurI will close this post by first saying thank you for your input. Sounding out the problem and getting suggestions was helpful in arriving at the solution. I culled a link for oceancontrol windows GUI client from the link beacon_dave provided. shabaz python client established a connection, I just didn't invest in generating a query. It did confirm it was working. BigG input reminded me of net cat a network test tool I had used many moon ago. I confess net cat was the one I used the most. Since I was only looking to confirm a connection through the firewall, net cats ease of use made it ideal for quick testing. Supported on windows and linux was bonus. I had to learn the syntax for Windows:( It is not the same as linux. With a confirmed modbus tcp interface available it is off to configure and test a VPN end to end solution that will connect the company and vendor. Thanks again for you input.https://community.element14.com/technologies/industrial-automation-space/m/managed-videos/151491Wed, 24 Jun 2026 05:05:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:b57a77e7-9496-40a7-84b7-3d758c2d3fd8CatwellSony AI's research project, Ace, is the first AI system to compete with and beat elite table tennis players under official rules. This short film follows the research team behind the project—from the earliest experiments in 2020 to the moment Ace ...https://community.element14.com/technologies/industrial-automation-space/b/blog/posts/ai-robot-ace-plays-table-tennis-against-human-players-winning-a-few-matchesWed, 24 Jun 2026 05:04:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:3ad57587-4918-497e-9949-422f1bb38006CatwellSony AI’s Ace robot playing table tennis against a human player. (Image Credit: Sony AI/ YouTube ) Sony’s AI robot Ace played a few matches of table tennis with elite players, often coming out on top. The achievement shows the advancements of AI and robotics, particularly in fast-paced environments involving real-time reactions and precise control. Robots haven’t mastered the art of table tennis as the sport requires rapid motion, spin, and split-second adjustments. This makes Ace’s ability to track and hit the ball even more impressive. Playing under official competition rules, Ace performed at a high level, handling tricky spins, recovering difficult net shots, and executing a backspin stroke that a professional deemed impossible. The AI robot won three matches versus elite players and lost two professional matches, winning only one game across seven contests. Usually, programs are trained on games like chess, poker, Go, and Breakout for decision-making in complex situations. And it’s more challenging to develop an intelligent robot, as those decisions must be turned into physical action by the machine. Ace overcomes some of table tennis’s difficult challenges by using an eight-jointed arm attached to a movable base. This means the machine doesn’t need two legs for balance. It also uses multiple cameras surrounding the court, tracking where the ball goes and its spin from various directions. The AI robot uses an end effector with a racket and a cup that holds the ball. (Image Credit: Sony AI/ YouTube ) “To match the speed of professional athletes, the robot hardware includes two prismatic and six revolute joints optimized for rapid lateral movement and striking precision, an end effector equipped with a racket, and a cup to hold the ball, facilitating one-armed serves,“ Sony AI wrote on its webpage . Zooming in on the logo printed on the balls allows the camera system to calculate its spin and rotational axis within milliseconds before reaching Ace. The AI robot was trained to respond to different spins and choose the best shots. Researchers trained it on 3,000 hours of simulated gameplay. Meanwhile, it mastered certain techniques, such as serving, by adapting strategies of human players. Ace got better at table tennis over time. At first, the robot struggled with slow, low-spin shots. It would hit them without much force, which resulted in a penalty during the match. Despite that drawback, it excelled in other aspects. For example, if the ball clipped the net, the robot reacted almost instantly when the trajectory changed. In one rally, Ace pulled off a surprising move. It hit the ball early and performed a backspin. Kinjiro Nakamura said he didn’t think a move like that was possible. But now he’s convinced that human players could learn from the robot. Playing against Ace is also pretty challenging. There’s no eye contact to make with the AI bot, and it doesn’t have body language and won’t crack under pressure, especially under tense moments, such as a 10-10 tie. Players usually look at their opponent’s eyes for cues. And since Ace has cameras around the court, they don’t show intent or emotion for players to pick up on. According to Sony, this is just the start for Ace. The company believes it can use Ace to develop smarter machines to handle real-world tasks, which includes helping people every day and supporting rehabilitation. www.youtube.com/watch Have a story tip? Message me here at element14.machine visionsonyaiping pongai vs humaninnovationhttps://community.element14.com/technologies/industrial-automation-space/b/blog/posts/getting-started-with-rs-485-modbus-rtu-multi-channel-thermocouple-measurementSun, 21 Jun 2026 03:00:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:31463c20-932e-4eae-a8d7-0ab42861f3c9shabazTable of Contents Introduction What Is Modbus RTU? What is Modbus TCP? RS-485 Refresher Multi-Channel Thermocouple Adapter Product Description Product Specifications Default Communication Settings Input Registers (Temperature Values) Holding Registers Testbed Results Troubleshooting Summary Introduction I had a requirement to measure temperature, and I wanted to use off-the-shelf hardware for now. Looking around for what was available, it seemed that an RS-485 connection, transporting content known as Modbus RTU frames, might work for me. This short blog post explains how to use Modbus RTU with the thermocouple temperature acquisition device, in case anyone else has a similar need. But first, a brief explanation of the Modbus RTU protocol. What Is Modbus RTU? Modbus RTU is a protocol with a simple request-response format, where the client (master) sends the requests. You can use Modbus RTU to set values, or to read them. Only a few different data types are supported, and they have unusual names for historical reasons. Data Type Size Description Coil 1-bit (On/Off) Actuator state (e.g. relay coil) Discrete Input 1-bit A binary input (e.g. switch) Input Register 16-bit Usually a varying value, perhaps from a sensor Holding Register 16-bit Similar to above register, but typically for configuration values that seldom change (perhaps in non-volatile memory) A typical modbus frame contains: The bytes stream depends on the function code. There are different function codes to read a range of any of the four data types listed above, and to write one or multiple values of data, plus there are various other miscellaneous functions. The response overall looks very similar to the request (which makes it sometimes impossible to visually distinguish with complete certainty a request from a response!; that's a clue to how ancient this protocol is), and the bytes stream will vary depending on the function code. Usually, the stream will begin with a length byte, and then perhaps a list of 16-bit values might be returned, or binary values packed into bytes. The diagram below shows the formats for an example request, and a valid response, and an error response (which has the most significant bit set within the function code byte). Here are the hex bytes of an example request, for querying the values of 16-bit input registers #0 and #1: 01 04 00 00 00 02 71 CB Breaking that down, the first byte indicates the address of the device that is to respond. The second byte is function code 0x04, which is “Read Input Registers”. The next two bytes are the 16-bit address of the first desired register. The next two byes specify how many registers are to be read. Finally the last two bytes are a checksum for all the preceding bytes. A successful response to that will contain the same address and function code as the request, but then there will be a 1-byte length field, and then the list of 16-bit register contents, followed by the checksum. Example: 01 04 04 AA BB CC DD 3F 20 In that example response, the first register value is 0xAABB, and the second register value is 0xCCDD. Regarding register numbering, another interesting historical-based point to note, is that sometimes the registers are listed as very large numbers such as 30001, 30002 and so on; those are for display purposes (to distinguish different data types, the 10000 series would be Discrete Inputs [binary values] for example), and in reality, at the actual protocol level, it’s likely you need to use addresses from zero upward, not from those large numbers. For more detail about the Modbus RTU protocol format, please see https://github.com/shabaz123/modbus_tools/blob/main/modbus_rtu_format.md For the checksum algorithm (in microcontroller-friendly C code) see https://github.com/shabaz123/modbus_tools/tree/main/modbus_rtu_crc16 What is Modbus TCP? Only partially relevant to this blog post, but there’s a fair bit of similarity. As the name suggests, Modbus TCP uses TCP/IP instead of RS-485. The PDU in the earlier diagram remains the same, but there’s no need for a CRC (TCP/IP is already reliable), and the Additional Address byte is replaced by seven bytes called a Modbus Application Protocol (MBAP) header. In summary, the Modbus TCP protocol is as straightforward to understand as is Modbus RTU, so if required, a microcontroller with a network connection would be feasible to interface with a Modbus TCP device. RS-485 Refresher It’s a three-wire system (two carrying serial data in differential (balanced) pair, and a ground or 0V reference wire) and multiple devices can connect to it. The two balanced wires are called A and B, or Normal and Inverting respectively. When one of those two wires is high with respect to the 0V connection, then the other wire will be low, and vice-versa. Transmit and receive can occur over the same set of wires, therefore it’s best if all devices are usually set as inputs, and only when a device needs to send data, should that device become an output. Most microcontrollers only offer a UART that has separate connections (often called RXD and TXD) for normal single-ended receive and transmit signals. Therefore, a kind of switchable buffer/level converter chip, called an RS-485 transceiver, is needed, to interface between the microcontroller connections and the balanced A and B wires, and the transceiver must be able to divert the stream from RXD (microcontroller input) to TXD (microcontroller output) depending on if the microcontroller receiving or needs to transmit. Some RS-485 transceivers can automatically do this, but another technique is to allocate a third pin on the microcontroller, to act as the signal to switch the transceiver direction. Usually, that third wire from the microcontroller needs to go high whenever the microcontroller code needs to transmit, to switch the RS-485 transceiver direction accordingly. That third wire is labelled DE (Driver Output Enable) in the example diagram above. Multi-Channel Thermocouple Adapter I purchased a low-cost thermocouple adapter, and it’s not bad. The instructions were only in Chinese, so I had to do some auto-translation. The internals look pretty good, unfortunately I didn't take any better photos. The product code is HK-K-8-RS485-CAN V3.0 and is called a K-type Thermocouple Temperature Acquisition Series by Huikong Electronics (Dongguan) Co., Ltd. Product Description • 1-16 channels (depending on model) • Up to 10 Hz update per channel • Isolated RS-485 • Modbus RTU • Open Circuit detection • CJ Compensation • Measuring range: -200 to +1350 deg C • Resolution: 0.25 deg C • Accuracy: +- 3 deg C • LEDs: Power, Comms • Reliability: Hardware and Software Watchdog • STM32 ARM Microcontroller • 14-bit ADC • Isolation: 3kV • C45 (35mm) DIN rail mount Product Specifications Item Description Supply Voltage 6-36V DV Interface Isolated RS-485 Power Consumption < 200mW Measurement Range -200 to + 1350 degC (K-type sensor) Collection Channels 1-8 ADC Resolution 14-bit Temperature Resolution 0.25 deg C Accuracy +- 3 deg C Sample Rate 100 kHz Data Update Rate Up to 10 Hz Per Channel Sensor Type K-Type Cold Junction Compensation Present Fault Detection Sensor Disconnected, Open Circuit Communication Protocol Modbus RTU Supported Function Codes 0x03 = Read Holding Register 0x04 = Read Input Register 0x06 = Write Single Holding Register 0x10 = Write Multiple Holding Registers Data analysis method 1 decimal place Slave Address 1-255 (Configurable, Non-Volatile storage) Baud Rate 4800, 9600, 14400, 19200, 38400 [default], 56000, 57600, 115200 (Configurable, Non-Volatile storage) Reset capability Hardware button, software reset Default Communication Settings • Address: 0x01 • RS-485 settings: Baud: 38400, 8-bit data, no parity, 1 stop bit Input Registers (Temperature Values) Input registers are used to access the data acquisition values. • Read-only • 16-bit (two bytes) Format: Note: The format is NOT 2’s Complement. Bit 15 (most significant bit) represents the sign (0 = positive, 1 = negative) Bits 14:0 represent the temperature in tenths of a degree C. Examples: +50 degrees C is represented as 500 decimal, which is binary 0000 0001 1111 0100. -50 degrees C is also represented as 500 decimal, but with MSB set to 1, i.e. 1000 0001 111 0100 Register Numbering: The register numbering in the Modbus RTU protocol begin at 0, so for the 8-channel model, the registers are 0x0000 to 0x0007. For display purposes, that would be 30001 to 30008. Holding Registers Holding registers are used to store configuration values. • Read/Write capability • 16-bit unsigned integers (two bytes) Register Numbering Register Address Display Address Reset Value Description 0x0031 40050 0 Data upload time interval in hundredths of a second. Example: Register value 200 means 2 / 100 = 2 seconds. Register value 0 means no active data upload. 0x0032 40051 1 RS-484 Address (1-255). Changes take effect after power cycle 0x0033 40052 1 Baud Rate. Mapping: 1=9600, 2=14400, 3=19200, 4=38400(default), 5=56000, 6=57600, 7=115200 0x003d 40062 0 RS-485 Parity. Mapping: 0=No Parity (default), 1 = Odd, 2 = Even. Changes take effect after power cycle Testbed The busy photo here shows how everything was connected up. My setup used a USB-to-I2C adapter, followed by a I2C-to-UART adapter, and then the RS-485 transceiver, so it’s more involved than what would normally be done. I had various reasons not important for this blog. It would be far easier to use a USB-Serial adapter followed by an RS-485 transceiver, or, simpler still, buy a USB-to-RS485 adapter. Results I won’t go into the software, since it’s so specific to my needs, however, you can see the hex bytes that formed the Modbus RTU request, and the response, in the screenshot below! This was based on the format description already described in this blog post. The temperature measurement looks realistic, and goes up when the thermocouple is warmed up. I do have a thermocouple simulator, I could use that to measure the accuracy of the device at some point, but I’ve no reason to doubt the specification so far. Troubleshooting If one gets in trouble, then generally WireShark is a good application to try! It will decode Modbus TCP, however Modbus RTU requires a way of getting WireShark to accept the serial data. There are various tools for that, some purchaseable, but, it strikes me that an easy approach would be to use a cheap microcontroller (such as a Pi Pico) to sniff the RS-485, and send it to the PC, and let the PC convert to Modbus TCP, back-and-forth over a local (127.0.0.1 IP address) connection. Then, WireShark can simply decode as Modbus TCP. I have got some distance into implementing this, but it's a work-in-progress. Summary This blog post walked briefly through an RS-485 and Modbus RTU protocol overview. Modbus RTU is easy to begin experimenting with, using a PC or microcontroller, and a serial connection and an RS-485 transceiver. It was possible to purchase an off-the-shelf Modbus RTU compatible temperature acquisition unit, and query 16-bit “Input Registers” which contained the measured temperature results. Thanks for reading!temperature measurementmodbus tcpmodbus rtudata acquisitionthermocouplers-485rs485modbus tcp/ipmodbusmodbus /tcphttps://community.element14.com/technologies/industrial-automation-space/f/forum/57027/e14-community-recommendation-for-modbus-tcp-client/236177Sat, 20 Jun 2026 19:34:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:fdd0ca56-7f5f-4b0a-b381-1ea28faa29b9BigGAh fantastic. Not that I would know (noob here). Apparently with netcat , you can transmit the structured Modbus application bytes and see if the hardware replies. This completely validates both the firewall rules and the device's availability in one go. Searching online brought up this page: stackoverflow.com/.../send-modbus-rtu-request-via-tcp-with-netcat-and-catch-the-responsehttps://community.element14.com/technologies/industrial-automation-space/f/forum/57027/e14-community-recommendation-for-modbus-tcp-client/236173Sat, 20 Jun 2026 14:39:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:46ab1744-300a-4ba4-939c-c86fd1641fcbcolporteurI completely forgot about CLI netcat! I recall you can setup a transmit and receiving end on ports you are examining. Man I miss tech coffee breaks. All those minds in one place was a great technical pool of knowledge.https://community.element14.com/technologies/industrial-automation-space/f/forum/57027/e14-community-recommendation-for-modbus-tcp-client/236169Fri, 19 Jun 2026 16:03:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:14541113-afaa-4d0b-9654-039aa9230b34shabazI cannot take the credit, AI wrote that code, I merely pointed it at the 1280 user manual, and it spit out Python code, I merely ran it and told it of any errors, so it could correct it. The screenshot below shows what I asked it originally. It's not perfect as you noticed, since it could have provided more helpful output or automatically abort a test rather than hang. Regarding the TCP connection etc., I'm very familiar with that part only because I ended up developing some products that heavily relied on network features/functions, I believe I would struggle with a lot of it if I had to learn it on my own.https://community.element14.com/technologies/industrial-automation-space/f/forum/57027/e14-community-recommendation-for-modbus-tcp-client/236167Fri, 19 Jun 2026 15:35:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:4ac5fe91-46a2-4f4c-8d74-1191c6560f05colporteurI'm humbled by your knowledge and thankful that you are willing to share. Many eons ago, when my skins had less wrinkles, I recall training with a senior aviation electronics technician in a course. He took the the time to share his experience. The stuff I learned in that short interaction I have never forgot. I can't comprehend how you extracted the information from the manual that enabled you to write code and decode the output for the modbus tcp interface. I'm envious. I recall listening to a lecturer speaking Russian. I figured if I listened hard enough I would understand Russian. Never understood a word! I have combed the manual and reviewed your code thinking if I try hard enough I will gain the knowledge. It is not working. If I was forty years younger, I would invest the time. I accomplished the goal. Just have the test the firewall rules set and be done. Thanks again. I tried you trick of connecting to an IP that didn't support modbus tcp and noted the error. I suspected your code was working. Great work on a first attempt.https://community.element14.com/technologies/industrial-automation-space/f/forum/57027/e14-community-recommendation-for-modbus-tcp-client/236165Fri, 19 Jun 2026 15:22:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:c57b38e4-ac7f-4466-b214-c6602b175d50colporteurI believe the video is where I found the bread crumbs to the site.https://community.element14.com/technologies/industrial-automation-space/f/forum/57027/e14-community-recommendation-for-modbus-tcp-client/236156Thu, 18 Jun 2026 15:49:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:a499695b-02c0-4564-adf5-682e55ebf5e0shabazHere is how the 1280 did in fact respond during the first test case: Your log file indicates the 1280 returned a status code 269 which in hex would be 0x010d or 0000 0001 0000 1101 in binary. According to the user guide, that means: No error, tare not entered, center of zero, weight OK, standstill, primary units, tare not acquired, gross weight, first channel (I don't know if that means channel 0 or channel 1). Anyway, perhaps this is now too much detail, since it's already clear the TCP connection to the 1280 did successfully, and that's all you requested. However, the test case shows that the actual Modbus TCP protocol layer is successfully being received and sent by the 1280 (from experience/being burnt with various protocols, I wanted the simulation to include Modbus TCP; there are plenty of situations where a TCP connect alone is simply insufficient to be sure that the next layer will pass).https://community.element14.com/technologies/industrial-automation-space/f/forum/57027/e14-community-recommendation-for-modbus-tcp-client/236155Thu, 18 Jun 2026 15:23:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:ecf22dd5-b2aa-4b69-aaf1-884733272940beacon_daveFYI that Ocean Controls tool was one of the ones demonstrated in the video link I posted previously. https://youtu.be/RiYHcFqbxCo?t=1946https://community.element14.com/technologies/industrial-automation-space/f/forum/57027/e14-community-recommendation-for-modbus-tcp-client/236154Thu, 18 Jun 2026 15:22:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:d234681b-4987-4854-8d4a-7d8384976c4dshabazHi Sean, Your output is successful. Here is what you'd see if there was no TCP connection at all: And this is what would be seen if the TCP connect occurred, but there was no response data from the 1280 end; it would just hang on Step 1 of the first test case (which has three steps): However in your client_output file, I see this, so it got past step 1 (and 2 and 3) and all of the first test case was successful. Your log file stops on the second test case step 1. I'm guessing you've got the real 1280 device attached, and it simply doesn't like the second test case (which is fine, since the test cases were written based on the ambiguous user guide, so the second test case happens to attempt a register that the real 1280 doesn't like. The log file shows that second test case was using a read register # 40257, that's the only difference from the first test case. So, since it's now confirmed your real 1280 doesn't use 40257, that could be deleted from the list inside the cloud_app_simulator.py file if you wished. But it's already confirmed that the 1280 end did respond with TCP data during the first test case.https://community.element14.com/technologies/industrial-automation-space/f/forum/57027/e14-community-recommendation-for-modbus-tcp-client/236152Thu, 18 Jun 2026 15:17:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:aee0122c-22a9-423d-b8a6-93db1a44dde3colporteurAn update on the goal of finding a modbus TCP client. My attempt with Shabaz offering wasn't successful so I moved onto hits from a google search for modbus tcp client. oceancontrols has such a beast for Windows. https://oceancontrols.com.au/software-modbusview-tcp-ocs-011.html The free software timeout every 15 minutes. Once restarted you have to setup communication. I installed the software in a Windows sandbox to test. I believe it is important to provide a return on investment. Your responses are valuable here is a return. I don't know Modbus protocol and I am not in the market to learn it. My goal was to find software that I could use to test the ability to connect to a modbus tcp interface through the firewall to the DMZ. The oceancontrol software is easy to install from their download. The Configure tab (Ellipse A) is where you set the IP address of the device you want to connect to. There is no ability to save this in the free software therefore every 15minutes you have to start over. Pressing the Start Polling button generates Status window messages and the poll window changes to Active. Under the Communication tab you bring up a log or monitor window. The top half of the monitor window transmit screen, shows polling numbers and the bottom half polling response numbers (Ellipse B) poll 36 gives a return of poll 36. There is a polling number receive for every transmit. A quick cmd window netstat -an shows a connection established (Ellipse C) to the IP address and port of the interface. When polling is stopped this connection disappears. YES! We are connecting and communicating to the modbus tcp interface. I was unsuccessful when I tried using the registers to write and read. It would be nice to interact, request a read of the scale head and see some data but that is not necessary to reach my goal. I have little programming knowledge so I abandoned that exercise. For this test the modbus tcp interface was outside the DMZ. Next step is to reposition the interface inside and start testing communication into the DMZ.https://community.element14.com/technologies/industrial-automation-space/f/forum/57027/e14-community-recommendation-for-modbus-tcp-client/236151Thu, 18 Jun 2026 13:49:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:fb811e94-cc97-4e6e-bc5f-8b0cb4950e14colporteurI've used your client side program. It appears to connect but generates errors. community.element14.com/.../client_5F00_output.ziphttps://community.element14.com/technologies/industrial-automation-space/b/blog/posts/the-ocean-cleanup-will-clean-the-la-rivers-in-time-for-the-2028-olympicsTue, 16 Jun 2026 14:41:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:8280813d-1866-448d-9a01-2d727f7ac0b9CatwellThe Interceptor removes plastic waste from rivers. (Image Credit: The Ocean Cleanup ) LA is getting ready for the 2028 Olympics. While doing so, efforts are underway to clean the waterways and coastlines. Dutch-based company The Ocean Cleanup plans to expand its plastic interception network to cover the LA River and San Gabriel River, continuing the success of its system in Ballona Creek. The project’s focus is to keep hundreds of tons of plastic waste out of the Pacific Ocean every year prior to the 2028 Summer Olympic Games. According to The Ocean Cleanup research, the LA rivers transport 410-628 tons of plastic to the Pacific annually. The expanded deployment of the interceptor , invented by Boyan Slat, is the core of this effort. These systems are autonomous white barges designed to collect plastic waste before it reaches the ocean. They remain afloat in the river throughout the year and start collecting post-rainfall. As the rain falls, stormwater washes litter into the river, which sweeps it into the Pacific. To keep the waste out, the interceptor uses a boom and net mounted on the river wall, helping guide debris to a collection point. Afterward, a conveyor belt removes the trash from the water and places it into an onboard storage bin. When the bins fill up, the waste is sent to the harbor. A crane then takes it out and sends it for sorting, processing, and disposal. (Image Credit: The Ocean Cleanup ) Kia supports The Ocean Cleanup’s river cleanup by setting aside funds for these interceptors. Since its 2022 start, Ballona Creek Interceptor 007 has stopped over 175 tons of waste from drifting into nearby waters. During its two-year pilot program, the system collected more than 248,000 pounds of trash from Westside communities like Venice, Beverley Hills, and Santa Monica. The effort is part of The Ocean Cleanup’s global 30 Cities Program. It has one goal in mind: to reduce the amount of plastic flowing from rivers into the oceans by one-third by the decade’s end. The Ocean Cleanup has already removed over 50 million kilograms of waste via its river and ocean cleanup systems around the world. Have a story tip? Message me here at element14.environmentindustriallaolympicsusaocean cleanuphttps://community.element14.com/technologies/industrial-automation-space/f/forum/57027/e14-community-recommendation-for-modbus-tcp-client/236117Sat, 13 Jun 2026 16:57:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:866d9d15-707f-4533-b5ea-c1c03f53f5a7BigGA slight deviation/distraction but I wondered if the page you shared would make for a Github project (something I'm exploring at present). So, I opened up the question to Gemini... The file you linked is an excellent core element of a project because it has: Defined Terminology: It explicitly details domain-specific terms (like coils , discrete inputs , holding registers ) so a developer doesn't have to guess. Clear Structures and Mappings: It provides precise payload formats ( ... ) and error/exception tables. Actionable Utility: A developer trying to write a Modbus communication driver in Python, C, or Go can look directly at this markdown file and know exactly how to structure their bytes. An ideal GitHub project is simply a centralized workspace that solves a specific technical problem or serves a clear purpose for its target audience. It can be pure code, pure documentation, or a mixture of both.https://community.element14.com/technologies/industrial-automation-space/f/forum/57027/e14-community-recommendation-for-modbus-tcp-client/236116Sat, 13 Jun 2026 14:23:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:74241b4d-d911-4362-a4c5-c43a07fc4b3eshabazI'm doing a similar thing.. I'm getting AI to help me with my notes, since the Wikipedia pages (and other resources) have info scattered, and I just wanted it condensed. This is a work-in-progress, I still need to check, and will test with my real device, and capture some traffic and so on: modbus_tools/modbus_rtu_format.md at main · shabaz123/modbus_tools (but please don't use this yet, since I'm still learning!). In some ways sometimes it's better coming at things from a beginner perspective when writing notes, because then one learns what's unclear in existing online documentation, and those are the areas I like to focus on, because it's almost guaranteed I will eventually forget again and so I will want to re-read quickly. I got AI to write me the software for the checksum (CRC) that RTU uses (TCP doesn't require it), verified it on Windows with real examples, and will also build it on a Pi Pico to double-check (there's no endianness issue, but I still want to test on at least one microcontroller).https://community.element14.com/technologies/industrial-automation-space/f/forum/57027/e14-community-recommendation-for-modbus-tcp-client/236115Sat, 13 Jun 2026 14:07:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:e59c4956-07fd-4bba-b870-ea3223a6150bBigGHaving never done this, I was curious. So, decided to ask my AI assistant as this is how I am now learning these days. You learn by doing. The benefit with this method is that it pays to be wrong and AI is great at doing that. It simply sets a direction and off you go. Maybe this is helpful... gemini.google.com/.../9aba1ba75b87https://community.element14.com/technologies/industrial-automation-space/f/forum/57027/e14-community-recommendation-for-modbus-tcp-client/236114Sat, 13 Jun 2026 13:47:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:d1d2c586-0af9-422e-b636-79b4a2e93aaeshabazHi! Might depend on what the cloud app vendor can do. Depending on what they're using (e.g. PaaS) they might not have as much flexibility to confirm if things are working at that low level (i.e. TCP socket). Hence to preempt that, if the test included a higher level (i.e. valid Modbus TCP messages) then that may be quicker for them to be confident the comms is working fine, even though the Modbus TCP messages can be garbage (valid garbage). If the cloud app vendor can work at a low-level in the stack then you're right, just a TCP level check might be sufficient.