{"id":1182,"date":"2026-09-02T11:19:25","date_gmt":"2026-09-02T09:19:25","guid":{"rendered":"https:\/\/www.embedded-communication.com\/?p=1182"},"modified":"2026-09-02T11:31:53","modified_gmt":"2026-09-02T09:31:53","slug":"canopen-sdo-abortcodes-verstehen","status":"publish","type":"post","link":"https:\/\/www.embedded-communication.com\/en\/canopen\/canopen-sdo-abortcodes-verstehen\/","title":{"rendered":"Understanding CANopen SDO Abort Codes"},"content":{"rendered":"<p><\/p>\n<h1>Understanding CANopen SDO Abort Codes<\/h1>\n<p>Anyone commissioning CANopen devices knows the situation: an SDO access to an object fails and the tool reports a 32-bit value such as <code>0x06090011<\/code> or <code>0x08000022<\/code>. Without looking it up, that number says very little \u2014 yet it carries the decisive information about why the access was rejected. This article explains how abort codes are structured and shows, for the cases that actually turn up in the field, what really lies behind them.<!--more--><\/p>\n<h2>What is an SDO abort?<\/h2>\n<p>The SDO service (Service Data Object) transfers configuration and diagnostic data between an SDO client (usually a CANopen manager (master) or a tool) and an SDO server (the addressed device). If an ongoing transfer cannot be completed normally, the other side terminates it with an <strong>Abort SDO Transfer<\/strong>.<\/p>\n<p>The abort message is always 8 bytes long and structured as follows:<\/p>\n<table border=\"1\">\n<tbody>\n<tr>\n<th>Byte<\/th>\n<th>Content<\/th>\n<\/tr>\n<tr>\n<td>0<\/td>\n<td>Command specifier <code>0x80<\/code><\/td>\n<\/tr>\n<tr>\n<td>1\u20132<\/td>\n<td>Index of the affected object (LSB first)<\/td>\n<\/tr>\n<tr>\n<td>3<\/td>\n<td>Sub-index<\/td>\n<\/tr>\n<tr>\n<td>4\u20137<\/td>\n<td>Abort code, 32 bit, LSB first<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Important for trace analysis: the abort code appears <strong>little endian<\/strong> on the bus. Code <code>0x06020000<\/code> therefore shows up in the frame as <code>00 00 02 06<\/code>. Anyone reading traces by hand should keep this reversal in mind \u2014 it is one of the most common sources of confusion.<\/p>\n<p>An abort is not acknowledged. It ends the transfer immediately, and it works in both directions: the client can abort as well, for example on its own timeout or when the user cancels a running download.<\/p>\n<h2>Structure of the abort code<\/h2>\n<p>The 32-bit value is not arbitrary but structured:<\/p>\n<table border=\"1\">\n<tbody>\n<tr>\n<th>Bits<\/th>\n<th>Meaning<\/th>\n<th>Typical values<\/th>\n<\/tr>\n<tr>\n<td>31\u201324<\/td>\n<td>Error class<\/td>\n<td><code>0x05<\/code> protocol error, <code>0x06<\/code> access error, <code>0x08<\/code> other errors<\/td>\n<\/tr>\n<tr>\n<td>23\u201316<\/td>\n<td>Error code within the class<\/td>\n<td>e.g. <code>0x04<\/code> for access errors<\/td>\n<\/tr>\n<tr>\n<td>15\u20130<\/td>\n<td>Additional code, refines the error<\/td>\n<td>e.g. <code>0x0011<\/code> for &#8220;sub-index does not exist&#8221;<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Roughly speaking, <code>0x05\u2026<\/code> concerns the SDO protocol itself, <code>0x06\u2026<\/code> the object dictionary, and <code>0x08\u2026<\/code> the application behind it. For everyday work, though, that classification is only a first orientation \u2014 what matters is the complete code including the additional code, because only that names the actual cause.<\/p>\n<h2>Where to find the complete list<\/h2>\n<p>The normative source for all defined abort codes is <strong>CiA 301<\/strong> (&#8220;CANopen application layer and communication profile&#8221;), in the section on the SDO protocol. There they are tabulated completely and bindingly \u2014 including the values you will never encounter in the field. The document is available from <a href=\"https:\/\/www.can-cia.org\/\">CAN in Automation<\/a> and belongs on every CANopen developer&#8217;s machine anyway.<\/p>\n<p>Repeating that list here would help nobody: an abort code should not be looked up in a table in the first place, but displayed by the tool. The more interesting question is a different one \u2014 which codes actually occur, and what do they mean beyond their definition?<\/p>\n<h2>The codes that actually occur in practice<\/h2>\n<h3><code>0x05040000<\/code> \u2014 SDO timeout<\/h3>\n<p>By far the most frequent error during commissioning, and the one least likely to have anything to do with the object dictionary. Typical causes, in the order in which they should be checked:<\/p>\n<ul>\n<li><strong>Wrong node ID.<\/strong> The client transmits on <code>0x600 + node ID<\/code> and waits for <code>0x580 + node ID<\/code>. If the node number is wrong, nobody answers at all.<\/li>\n<li><strong>Device in NMT state Stopped.<\/strong> In the Stopped state only NMT and error control are active \u2014 SDOs are not served. An <code>Enter Pre-Operational<\/code> resolves this instantly. See the article on <a href=\"https:\/\/www.embedded-communication.com\/canopen\/canopen-netzwerkmanagement-nmt\/\">CANopen network management<\/a> for details.<\/li>\n<li><strong>Bit rate mismatch or missing termination.<\/strong> If no frame is acknowledged at all, the bus is the problem, not CANopen.<\/li>\n<li><strong>Client timeout too short.<\/strong> Devices that block while writing to flash or during a store operation need longer than the usual 1000 ms. Some servers do respond correctly, just late.<\/li>\n<\/ul>\n<p>A look at the trace clarifies this in seconds: is a request visible on the bus at all, and does the node answer with anything?<\/p>\n<h3><code>0x06020000<\/code> \u2014 object does not exist<\/h3>\n<p>The device does not know the index. Almost always one of three causes:<\/p>\n<ul>\n<li>The EDS file in use does not match the actual firmware version of the device. A perennial issue with manufacturer-specific objects from <code>0x2000<\/code> onwards.<\/li>\n<li>The index was entered incorrectly, or the tool interprets the byte order differently than expected.<\/li>\n<li>An optional object is simply not implemented in this particular device. Many CiA 301 objects are optional \u2014 <code>0x1015<\/code> (EMCY inhibit time) or <code>0x1003<\/code> (error history), for instance.<\/li>\n<\/ul>\n<p>The code is clearly distinct from the sub-index error <code>0x06090011<\/code>: with <code>0x06020000<\/code> the entire object is missing, with <code>0x06090011<\/code> it exists but the requested sub-index does not. For arrays it is then worth reading sub-index 0, which reports the actual number of entries.<\/p>\n<h3><code>0x06010002<\/code> \u2014 attempt to write a read-only object<\/h3>\n<p>Besides the obvious case (writing to <code>0x1018<\/code>, the identity object), there are two classics:<\/p>\n<ul>\n<li><strong>Sub-index 0 of arrays and records<\/strong> is defined as <code>const<\/code> in many objects and cannot be changed.<\/li>\n<li><strong>Changing a PDO mapping while the PDO is valid.<\/strong> Per CiA 301, bit 31 in the PDO&#8217;s COB-ID entry must be set first (PDO invalid), then sub-index 0 of the mapping parameter written to 0, then the mapping changed, then sub-index 0 set to the new count, and finally the PDO made valid again. Skip this sequence and, depending on the stack, you get <code>0x06010002<\/code> or <code>0x06040042<\/code>. More on this in the article on <a href=\"https:\/\/www.embedded-communication.com\/canopen\/canopen-pdo-linking\/\">PDO linking<\/a>.<\/li>\n<\/ul>\n<h3><code>0x06070010<\/code>, <code>0x06070012<\/code>, <code>0x06070013<\/code> \u2014 length errors<\/h3>\n<p>The client sent a different data length than the object expects. In practice this is nearly always a tool or client issue rather than a device fault: in an expedited download, the number of valid bytes must be indicated correctly via the <code>n<\/code> bits in the command specifier. If an <code>UNSIGNED16<\/code> is written with four bytes, a standard-compliant server rejects it. Some stacks are tolerant here and silently accept oversized accesses \u2014 so a device that aborts correctly is not the worse one.<\/p>\n<h3><code>0x06090030<\/code>, <code>0x06090031<\/code>, <code>0x06090032<\/code> \u2014 value out of range<\/h3>\n<p>The data type is right, the value is not. The permitted limits are given in the EDS file in the <code>LowLimit<\/code> and <code>HighLimit<\/code> entries. If a device aborts here even though the value should be allowed according to the EDS, the EDS file is usually out of date.<\/p>\n<h3><code>0x08000022<\/code> \u2014 wrong device state<\/h3>\n<p>The access would be permissible in principle but is blocked in the current state. Typical situations:<\/p>\n<ul>\n<li>Configuration parameters that can only be changed in the Pre-operational state.<\/li>\n<li>CiA 402 drives in which certain parameters are locked in the <em>Operation Enabled<\/em> state.<\/li>\n<li>An ongoing store or update operation blocking further accesses.<\/li>\n<\/ul>\n<p>The difference from <code>0x08000021<\/code> (local control) is subtle: there, local operation \u2014 a hand terminal or a selector switch on the device \u2014 prevents access via the bus.<\/p>\n<h3><code>0x08000020<\/code> \u2014 application rejects the data<\/h3>\n<p>The generic fallback when an application callback in the device rejects the value without supplying a more specific reason. A common example: writing to <code>0x1010<\/code> (store parameters) without the required signature. The expected value is the ASCII sequence &#8220;save&#8221; as <code>UNSIGNED32<\/code>, i.e. <code>0x65766173<\/code>; likewise <code>0x1011<\/code> (restore) requires &#8220;load&#8221;, i.e. <code>0x64616F6C<\/code>. Any other value leads to an abort.<\/p>\n<h3><code>0x05030000<\/code> \u2014 toggle bit not alternated<\/h3>\n<p>Relevant only for segmented transfers. Every segment must alternate the toggle bit. The error points to duplicated frames, a retransmission at CAN level, or a faulty client implementation \u2014 with commercial stacks on both sides it is practically never seen.<\/p>\n<h2>The right tool saves the lookup<\/h2>\n<p>Nobody should have to look up abort codes in a table \u2014 and translating the raw bytes <code>80 17 10 00 02 00 01 06<\/code> back by hand is a pure waste of time. A tool with CANopen interpretation takes care of both: it recognises the abort message, reverses the byte order, resolves index and sub-index against the EDS file, and displays the abort code in plain text.<\/p>\n<p>Two tools cover the typical use cases:<\/p>\n<ul>\n<li><strong><a href=\"https:\/\/www.emotas.de\/en\/software-products-by-emotas\/can-software-products\/can-tools\/caninterpreter\">emotas CANinterpreter<\/a> with the CANopen Interpretation plug-in<\/strong> \u2014 the way to go when you want to observe what a third-party CANopen manager or a host controller is actually doing on the bus. Instead of raw data bytes, the tool shows the CANopen service, for example a read SDO access to the heartbeat producer object <code>0x1017<\/code> \u2014 and, in the error case, the decoded abort code. Filtering works both by node ID and by CANopen service, which makes all the difference on busy networks. Together with the recording and replay functions, this is the right choice for sporadic faults that cannot be reproduced on demand.<\/li>\n<li><strong><a href=\"https:\/\/www.emotas.de\/en\/software-products-by-emotas\/canopen-software-products\/canopen-tools\/canopen-deviceexplorer\">emotas CANopen DeviceExplorer<\/a><\/strong> \u2014 the way to go when you trigger the access yourself. The object browser reads the EDS file and presents every object with its data type, access rights and value limits. In many cases that shows you before the access why it is going to fail \u2014 because an object is <code>ro<\/code>, say, or because the requested sub-index does not exist at all. If an SDO does fail, the abort code is reported directly in plain text. CANopen interpretation is already part of the Basic package, so object access and trace view live in the same tool.<\/li>\n<\/ul>\n<p>For recurring checks, the scripting plug-in pays off: a script that walks through a list of objects and logs the returned abort codes finds inconsistencies between EDS and firmware in seconds rather than hours.<\/p>\n<h2>A workflow for troubleshooting<\/h2>\n<p>A pragmatic order that resolves most cases within minutes:<\/p>\n<ol>\n<li><strong>Record a trace and have it interpreted.<\/strong> Only once request, response and abort are available in plain text do you know whether the device answered at all, and with which code. Skip this step and you are guessing.<\/li>\n<li><strong>Check the NMT state.<\/strong> Some timeouts disappear after an <code>Enter Pre-Operational<\/code>.<\/li>\n<li><strong>Cross-check the EDS against the device.<\/strong> Object actually present, access rights, data type, value limits \u2014 a matter of seconds in the object browser.<\/li>\n<li><strong>Repeat the access in isolation.<\/strong> A single SDO access from the tool, with no CANopen manager running in parallel, separates genuine object errors from state-dependent locks.<\/li>\n<li><strong>Ask the manufacturer<\/strong> \u2014 but with the specific abort code, index and sub-index. That shortens any support request considerably.<\/li>\n<\/ol>\n<h2>For device manufacturers<\/h2>\n<p>The abort code is part of the device&#8217;s user interface. Returning a blanket <code>0x08000000<\/code> (general error) forces every integrator to guess and generates support effort. Three recommendations:<\/p>\n<ul>\n<li style=\"list-style-type: none;\">\n<ul>\n<li>Use the most specific applicable code, in particular the range errors <code>0x06090030<\/code> to <code>0x06090032<\/code> instead of a generic <code>0x08000020<\/code>.<\/li>\n<li>Report state-dependent locks consistently with <code>0x08000022<\/code>, and state in the device documentation which objects are writable in which state.<\/li>\n<li>Document the abort codes your device uses \u2014 just as you would the <a href=\"https:\/\/www.embedded-communication.com\/canopen\/canopen-emergency-nachrichten\/\">emergency error codes<\/a>.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><\/p>","protected":false},"excerpt":{"rendered":"<p>Sorry, this entry is only available in Deutsch.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-1182","post","type-post","status-publish","format-standard","hentry","category-canopen"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v28.4 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Understanding CANopen SDO Abort Codes - embedded communication<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.embedded-communication.com\/canopen\/canopen-sdo-abortcodes-verstehen\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Understanding CANopen SDO Abort Codes - embedded communication\" \/>\n<meta property=\"og:description\" content=\"Sorry, this entry is only available in Deutsch.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.embedded-communication.com\/canopen\/canopen-sdo-abortcodes-verstehen\/\" \/>\n<meta property=\"og:site_name\" content=\"embedded communication\" \/>\n<meta property=\"article:published_time\" content=\"2026-09-02T09:19:25+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-09-02T09:31:53+00:00\" \/>\n<meta name=\"author\" content=\"Torsten Gedenk\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@EmbeddedComm\" \/>\n<meta name=\"twitter:site\" content=\"@EmbeddedComm\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Torsten Gedenk\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"9 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.embedded-communication.com\\\/canopen\\\/canopen-sdo-abortcodes-verstehen\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.embedded-communication.com\\\/canopen\\\/canopen-sdo-abortcodes-verstehen\\\/\"},\"author\":{\"name\":\"Torsten Gedenk\",\"@id\":\"https:\\\/\\\/www.embedded-communication.com\\\/en\\\/#\\\/schema\\\/person\\\/8f0fcf033edee00b06d4dd4cf196680e\"},\"headline\":\"Understanding CANopen SDO Abort Codes\",\"datePublished\":\"2026-09-02T09:19:25+00:00\",\"dateModified\":\"2026-09-02T09:31:53+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.embedded-communication.com\\\/canopen\\\/canopen-sdo-abortcodes-verstehen\\\/\"},\"wordCount\":3235,\"publisher\":{\"@id\":\"https:\\\/\\\/www.embedded-communication.com\\\/en\\\/#organization\"},\"articleSection\":[\"CANopen\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.embedded-communication.com\\\/canopen\\\/canopen-sdo-abortcodes-verstehen\\\/\",\"url\":\"https:\\\/\\\/www.embedded-communication.com\\\/canopen\\\/canopen-sdo-abortcodes-verstehen\\\/\",\"name\":\"Understanding CANopen SDO Abort Codes - embedded communication\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.embedded-communication.com\\\/en\\\/#website\"},\"datePublished\":\"2026-09-02T09:19:25+00:00\",\"dateModified\":\"2026-09-02T09:31:53+00:00\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.embedded-communication.com\\\/canopen\\\/canopen-sdo-abortcodes-verstehen\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.embedded-communication.com\\\/canopen\\\/canopen-sdo-abortcodes-verstehen\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.embedded-communication.com\\\/canopen\\\/canopen-sdo-abortcodes-verstehen\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Startseite\",\"item\":\"https:\\\/\\\/www.embedded-communication.com\\\/en\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"CANopen SDO Abortcodes verstehen\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.embedded-communication.com\\\/en\\\/#website\",\"url\":\"https:\\\/\\\/www.embedded-communication.com\\\/en\\\/\",\"name\":\"embedded communication\",\"description\":\"A blog about embedded communcation protocols.\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.embedded-communication.com\\\/en\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.embedded-communication.com\\\/en\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.embedded-communication.com\\\/en\\\/#organization\",\"name\":\"embedded communication\",\"url\":\"https:\\\/\\\/www.embedded-communication.com\\\/en\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.embedded-communication.com\\\/en\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/www.embedded-communication.com\\\/wp-content\\\/uploads\\\/2016\\\/08\\\/embedded-communication.png\",\"contentUrl\":\"https:\\\/\\\/www.embedded-communication.com\\\/wp-content\\\/uploads\\\/2016\\\/08\\\/embedded-communication.png\",\"width\":240,\"height\":240,\"caption\":\"embedded communication\"},\"image\":{\"@id\":\"https:\\\/\\\/www.embedded-communication.com\\\/en\\\/#\\\/schema\\\/logo\\\/image\\\/\"},\"sameAs\":[\"https:\\\/\\\/x.com\\\/EmbeddedComm\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.embedded-communication.com\\\/en\\\/#\\\/schema\\\/person\\\/8f0fcf033edee00b06d4dd4cf196680e\",\"name\":\"Torsten Gedenk\",\"url\":\"https:\\\/\\\/www.embedded-communication.com\\\/en\\\/author\\\/ged\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Understanding CANopen SDO Abort Codes - embedded communication","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.embedded-communication.com\/canopen\/canopen-sdo-abortcodes-verstehen\/","og_locale":"en_US","og_type":"article","og_title":"Understanding CANopen SDO Abort Codes - embedded communication","og_description":"Sorry, this entry is only available in Deutsch.","og_url":"https:\/\/www.embedded-communication.com\/canopen\/canopen-sdo-abortcodes-verstehen\/","og_site_name":"embedded communication","article_published_time":"2026-09-02T09:19:25+00:00","article_modified_time":"2026-09-02T09:31:53+00:00","author":"Torsten Gedenk","twitter_card":"summary_large_image","twitter_creator":"@EmbeddedComm","twitter_site":"@EmbeddedComm","twitter_misc":{"Written by":"Torsten Gedenk","Est. reading time":"9 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.embedded-communication.com\/canopen\/canopen-sdo-abortcodes-verstehen\/#article","isPartOf":{"@id":"https:\/\/www.embedded-communication.com\/canopen\/canopen-sdo-abortcodes-verstehen\/"},"author":{"name":"Torsten Gedenk","@id":"https:\/\/www.embedded-communication.com\/en\/#\/schema\/person\/8f0fcf033edee00b06d4dd4cf196680e"},"headline":"Understanding CANopen SDO Abort Codes","datePublished":"2026-09-02T09:19:25+00:00","dateModified":"2026-09-02T09:31:53+00:00","mainEntityOfPage":{"@id":"https:\/\/www.embedded-communication.com\/canopen\/canopen-sdo-abortcodes-verstehen\/"},"wordCount":3235,"publisher":{"@id":"https:\/\/www.embedded-communication.com\/en\/#organization"},"articleSection":["CANopen"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/www.embedded-communication.com\/canopen\/canopen-sdo-abortcodes-verstehen\/","url":"https:\/\/www.embedded-communication.com\/canopen\/canopen-sdo-abortcodes-verstehen\/","name":"Understanding CANopen SDO Abort Codes - embedded communication","isPartOf":{"@id":"https:\/\/www.embedded-communication.com\/en\/#website"},"datePublished":"2026-09-02T09:19:25+00:00","dateModified":"2026-09-02T09:31:53+00:00","breadcrumb":{"@id":"https:\/\/www.embedded-communication.com\/canopen\/canopen-sdo-abortcodes-verstehen\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.embedded-communication.com\/canopen\/canopen-sdo-abortcodes-verstehen\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.embedded-communication.com\/canopen\/canopen-sdo-abortcodes-verstehen\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Startseite","item":"https:\/\/www.embedded-communication.com\/en\/"},{"@type":"ListItem","position":2,"name":"CANopen SDO Abortcodes verstehen"}]},{"@type":"WebSite","@id":"https:\/\/www.embedded-communication.com\/en\/#website","url":"https:\/\/www.embedded-communication.com\/en\/","name":"embedded communication","description":"A blog about embedded communcation protocols.","publisher":{"@id":"https:\/\/www.embedded-communication.com\/en\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.embedded-communication.com\/en\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.embedded-communication.com\/en\/#organization","name":"embedded communication","url":"https:\/\/www.embedded-communication.com\/en\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.embedded-communication.com\/en\/#\/schema\/logo\/image\/","url":"https:\/\/www.embedded-communication.com\/wp-content\/uploads\/2016\/08\/embedded-communication.png","contentUrl":"https:\/\/www.embedded-communication.com\/wp-content\/uploads\/2016\/08\/embedded-communication.png","width":240,"height":240,"caption":"embedded communication"},"image":{"@id":"https:\/\/www.embedded-communication.com\/en\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/x.com\/EmbeddedComm"]},{"@type":"Person","@id":"https:\/\/www.embedded-communication.com\/en\/#\/schema\/person\/8f0fcf033edee00b06d4dd4cf196680e","name":"Torsten Gedenk","url":"https:\/\/www.embedded-communication.com\/en\/author\/ged\/"}]}},"_links":{"self":[{"href":"https:\/\/www.embedded-communication.com\/en\/wp-json\/wp\/v2\/posts\/1182","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.embedded-communication.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.embedded-communication.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.embedded-communication.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.embedded-communication.com\/en\/wp-json\/wp\/v2\/comments?post=1182"}],"version-history":[{"count":4,"href":"https:\/\/www.embedded-communication.com\/en\/wp-json\/wp\/v2\/posts\/1182\/revisions"}],"predecessor-version":[{"id":1186,"href":"https:\/\/www.embedded-communication.com\/en\/wp-json\/wp\/v2\/posts\/1182\/revisions\/1186"}],"wp:attachment":[{"href":"https:\/\/www.embedded-communication.com\/en\/wp-json\/wp\/v2\/media?parent=1182"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.embedded-communication.com\/en\/wp-json\/wp\/v2\/categories?post=1182"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.embedded-communication.com\/en\/wp-json\/wp\/v2\/tags?post=1182"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}