When you read an attribute from a CIP device, the bytes you get back have a type. When you write a value, you must encode it in the right type or the device returns an error. This page is the complete reference for every CIP data type defined by ODVA’s CIP Networks Library Volume 1, Appendix C. CIP’s… Read More »
Every CIP message starts with a one-byte service code. That byte tells the target device what to do — read an attribute, write an attribute, open a connection, reset, save configuration. This page is the authoritative reference for every CIP service code defined by ODVA’s CIP Networks Library Volume 1, Appendix A. If services are the verbs of… Read More »
When a CIP service fails, the device returns an error response with a one-byte General Status Code that tells you why. This page is the complete reference for every code defined by the official CIP specification — what each one means, what usually causes it, and how to fix it. The codes come straight from ODVA’s CIP Networks… Read More »
Pull a cable in a star-topology EtherNet/IP network and one device goes dark. Pull a cable in a properly designed DLR ring and the network recovers in less than 3 milliseconds — fast enough that the PLC scan does not even register the change. That recovery time is the whole reason DLR exists. Engineers building motion-control machines, robotic… Read More »
Open Wireshark on an EtherNet/IP network and the first thing you see is not CIP. You see TCP. Then a strange 24-byte header. Then more bytes inside that look like CIP. The 24-byte header is the EtherNet/IP Encapsulation Protocol — the layer that wraps every CIP message onto a TCP/IP network. Nobody talks about it because everyone calls… Read More »
Two of the most practical additions in MQTT 5 are about time: how long the broker should hold on to a client’s session, and how long it should hold on to an individual message. In MQTT 3.1.1, neither was a protocol concern. A persistent session lived indefinitely on the broker until something explicitly wiped it, and a queued… Read More »
MQTT 5 is the current version of the protocol. It was ratified as an OASIS standard on 7 March 2019, succeeding MQTT 3.1.1, which had been the standard since 2014. MQTT 5 is not a rewrite. It is an evolution of MQTT 3.1.1 that keeps the core (publish/subscribe, topics, QoS, sessions, retained messages, LWT, keep alive) and adds… Read More »
MQTT runs on top of TCP. That works well almost everywhere it is deployed: on embedded devices, gateways, servers, and desktop tools. There is one environment, though, where it does not work directly: the browser. A web page cannot open a raw TCP connection, which means a JavaScript MQTT client cannot connect to a broker over plain MQTT… Read More »
Both protocols certify safety up to SIL3, Cat 4, PL e. Both use the Black Channel principle. Both have been deployed for nearly two decades and are used extensively across industries worldwide, with very large installed bases. On paper, CIP Safety and PROFIsafe look almost interchangeable. In practice, choosing between them is one of the most consequential decisions… Read More »
Here is the question every engineer eventually asks: how can you trust an Ethernet packet to stop a hydraulic press? Standard Ethernet drops packets. Switches buffer and re-order them. Cables get unplugged mid-cycle. Yet CIP Safety lets a safety PLC monitor an emergency stop button over the same network that carries your I/O and your HMI traffic —… Read More »