CANopen - variable length strings ?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Not applicable
Hi folks,

I'm getting started on a second phase of our project, that will see us add CANopen comms.
A question, if I may, about sending byte strings over CANopen, of 7 to 261 bytes..
..if there's someone reading that's clued up on these matters.

From what I've gathered so far, SDO is the right vehicle for this.
Specifically, as 'segmented' or 'block' transfer, rather than the 4-byte limited 'expedited'.
Although in many respects, that's down to the CANopen stack, to handle.

My question, concerns the fact that the strings I wish to send, are variable in length, anywhere between 7 and 261 bytes.
And I don't want to always have to send 261 bytes, and swamp the CAN bus with a ton of frames, each carrying 8 bytes of the 261 !

My first thought, was create an SDO object/index, comprising just a single 262-byte OCTET_STRING
262, to allowing one extra byte, for terminating null, per the Port CANopen stack (demo version) documentation, at least.
And start sending as if I plan to send the full 262 bytes..
.. but bail, with an abort frame, when done.

But I didn't much like that idea. Especially as abort, from what I gather, is intended really for errors,
and diagnostics might record the aborts as such - doesn't look great!

My second thought, was to create an SDO array object, comprising 255 strings, the first being 8 bytes, the next 9 bytes, through to the last, of 262 bytes.
In other words, an SDO object/index, with subindex 0 being the array size, namely 255. Subindex 1 would be a 8-byte OCTET_STRING, subindex 2 would be an 9-byte OCTET_STRING, through to subindex 255 being a 262-byte OCTET_STRING. And use whichever of the strings matches the length of my variable string (including its terminating null).

Nice idea! But the Port stack at least, requires that with an array of OCTET_STRING's, they all have to be the same size. The manual says so. And when I tried the above, in the Port Design Tool, it errors with: Error: 'line 0, index 2000 - Different 'Size' values for sub-indices of this index. This is not allowed for Arrays.'. OK, fair enough.

My third idea then, is to create 255 SDO objects, each comprising just a different length OCTET_STRING, from 8 bytes, through to 262 bytes. And likewise, use whichever string matches.

But, my question is, is this really necessary? Do CANopen stacks, generally, accept an SDO write request, of say a 123-byte string, to an OCTET_STRING object configured to be size 262-bytes? And if so, do they infact only send sufficient frames to communicate the 124 bytes (string and terminating null) ?

And does the receiving stack accept the string? Or reject on the basis of it not equalling 262 bytes ?

I see in the great description, at http://www.byteme.org.uk/canopenparent/canopen/sdo-service-data-objects-canopen/, if you scroll down to 'Write Dictionary Object (segmented)', that the first frame includes unsigned 32-bit 'Len'.

The CANopen standards, unfortunately don't have anything to say on the above. Infact, CiA301 doesn't even indicate the maximum length of an OCTET_STRING, or the other extended data types.

Which leads me to my last question: Anyone know whether the various CANopen stacks / tools, can support a 262 byte OCTET_STRING ?

With the Port Design Tool, I tried entering various lengths, including 9999999999, above the 'Len' limit, but it didn't complain, on entry or code generate, and simply generated the below. So that, unfortunately, didn't inform.

:
extern CO_DT_INIT_VAR OCT_STRING_T xxx[9999999999];
:

Looking at the below, I was concerned to read, 'Please note that the size of an octet string is limited to 127 characters.'.

http://www.port.de/fileadmin/user_upload/Dateien_IST_fuer_Migration/DeviceMonitor/UserMan_CANopen_De...

So we might find that tool limiting, for our project..

..anyone have a handle, on which stacks / tools can support OCTET_STRING's of 262 bytes?

Best regards,

David
0 Likes
0 Replies