Free topology is the reason people put up with LonWorks wiring. Bus, star, loop, or any mix of them, on one pair, with one termination you can put anywhere. No daisy-chain discipline, no polarity to get right. It isn’t free of rules. It has distance limits, a termination that has to be the right value, and a power… Read More: LonWorks Twisted Pair Wiring: Free Topology, Distances and Link Power »
A Modbus register is sixteen bits and nothing else. What those bits mean lives in a document somebody emailed you. A LonWorks network variable carries its own type. Two devices that agree on the type exchange a temperature without anyone deciding whether it’s tenths of a degree. That difference is the reason the protocol exists, and it’s also… Read More: LonWorks Network Variables: Selectors, Bindings, Aliases and Polls »
Pick the wrong service type and the network still works — until it doesn’t. Under light load everything delivers. Under load, the acknowledged multicast you specified starts eating the channel it needs, and the symptom looks like a hardware fault. ISO/IEC 14908-1 gives you four services. This is what each one actually does on the wire, when to… Read More: LonTalk Service Types: Acknowledged, Request/Response, Repeated and Unacknowledged »
Every LonTalk packet carries both a source and a destination address, and both live in the same header. There is no separate layer-2 addressing underneath — the standard folds routing and naming into one address field. Get the structure of that field straight and most of the network’s limits, quirks, and failure modes stop being mysterious. This is… Read More: LonTalk Addressing: Domain, Subnet, Node, Group and Neuron ID »
Walk into a plant room and you will see three names on the same equipment. LonWorks on the panel label. LonTalk in the manual. ISO/IEC 14908 in the submittal package. They are not three protocols. LonWorks is the platform — chips, transceivers, tools, devices. LonTalk is the protocol those devices speak. ISO/IEC 14908 is the published standard that… Read More: LonWorks Protocol: LonTalk, ISO/IEC 14908, and How the Network Actually… »
Above the tool Two holding registers come back as 17142 and 58982. The vendor manual says the value is a float. It does not say in which order the two registers go. That is the whole problem. The Modbus specification defines a 16-bit register and nothing larger, so every device that reports a 32-bit float had to invent… Read More: Modbus Float Converter — 32-Bit Register Word Order Tool »
Above the tool An EDS file is a plain text device description. Your configuration tool reads it, builds a device profile, and hides everything behind a wizard. When the device does not come online, you need to see what is actually in that file. This viewer opens both kinds of EDS you run into on an industrial job:… Read More: EDS File Viewer — Open CANopen & EtherNet/IP EDS Online »
Every CANopen device carries an object dictionary, and the SDO is the only way to reach into it from outside. Read a serial number, change a gear ratio, remap a PDO, save the configuration to flash — all of it is SDO traffic. Unlike a PDO, an SDO frame carries its own address. The first byte says what… Read More: CANopen SDO Explained: Expedited, Segmented, Block »
A PDO is eight bytes of raw process data with no protocol overhead — no index, no sub-index, no length field, nothing that tells you what is inside. The bytes arrive and the consumer is expected to already know what they mean. That agreement is the PDO mapping. It lives in the object dictionary on both sides, it… Read More: CANopen PDO Mapping: TPDO, RPDO and Transmission Types »
Paste a CAN trace. Each line becomes a decoded message: the COB-ID split into function code and node ID, then the service behind it read out field by field. It takes candump output, PCAN text, or plain identifier data lines. Several lines at once, in order, so a whole startup sequence decodes in one pass. Message input One… Read More: CANopen Message Decoder — SDO, PDO, EMCY and NMT Online »