[etherlab-users] 64-bit integers in Etherlab OK?

[Richard Hacker (MSc Eng)]

Hi Julian,

If you look at the definition of SS_DOUBLE_UINT32 in 
${matlab}/simulink/include/simstruc_types.h, you may recognise that it is 
made up of 2 uint32's. On the other hand it is not possible to define a block 
input/output port with this data type. Allowed are only the types listen in 
BuiltInDTypeId.

I think that your problem is that Matlab does not have 64 bit as a native 
signal data type. Obviously you can start with tricks like using an array of 
uint32[2], but what do you do with this vector in a simulink model? What 
happens if you want to put 5 uint64 signals as a vector on a single block 
output port; define it as uint32[10], or uint[2][5]?

I acknowledge the need for supporting EtherCAT slaves that have 64 bit PDO's, 
but I think that unless Simulink directly supports these data types, any 
solution will be a severe compromise. Maybe someone has a good idea?

At the moment, my solution is to use alternative PDO's that output 32 bit 
data.

- Richard

On Thursday 11 June 2009 14:00, Julian Stoev wrote:
> Hello again,
>
> I would like to provide more info and thoughts on the problem I have,
> which may concern a general problem in the Etherlab code.
>
> It appears to me that the current version of Etherlab supports up to
> 32 bit integer data.
> This can be found in the comments of ec_slave2.c
>
>  * 10. Pdo Entry Info - N-by-4 numeric matrix
>  *   A matrix of 3 columns describing the PDO entry information. It is used
>  *   to configure the slave's PDO's. The columns have the following
>  *   functions:
>  *    1 - Index
>  *    2 - Subindex
>  *    3 - Bit length: number of bits that are mapped by the pdo entry
>  *    4 - PDO Data type: one of 1, -8, 8, -16, 16, -32, 32 mapping to
>  *        SS_BOOLEAN, SS_INT8, SS_UINT8, SS_INT16, SS_UINT16,
>  *        SS_INT32 and SS_UINT32
>
> Same can be found also in the ec_slave2.c code in the function
> get_data_type, for example:
>
>     else if (width > 32) {
>         reason = "Unsigned data type must be in the range [1..32].";
>         goto out;
>      }
> This is actually the part which signals error in my case, as reported
> before.
>
> But current EL5101 XML files definitely have 64 bit integer objects.
> And according to my understanding my hardware requires this new XML
> files.
>
> I found this in the Matlab RTW documentation (C API for S-Functions):
> void ssGetElapseTimeCounter(SimStruct *S, (void *)elapseTime): This
> function is provided for the use of blocks that require the elapsed
> time values for fixed-point computations. ssGetElapseTimeCounter
> returns, to the location pointed to by elapseTime, the integer value
> of the elapsed time counter associated with the S-function. If the
> counter size is 64 bits, the value is returned as an array of two
> 32-bit words, with the low-order word stored at the lower address.
>
> To determine how to access the returned counter value, obtain the data
> type of the counter by calling ssGetElapseTimeCounterDtype, as in the
> following code:
>
> int    *y_dtype;
> ssGetElapseTimeCounterDtype(S, y_dtype);
>
>  switch(*y_dtype) {
>   case SS_DOUBLE_UINT32:
>       {
>           uint32_T dataPtr[2];
>           ssGetElapseTimeCounter(S, dataPtr);
>       }
>       break;
>   case SS_UINT32:
>       {
>          uint32_T dataPtr[1];
>          ssGetElapseTimeCounter(S, dataPtr);
>      }
>       break;
>   case SS_UINT16:
>      {
>           uint16_T dataPtr[1];
>           ssGetElapseTimeCounter(S, dataPtr);
>      }
>       break;
>   case SS_UINT8:
>      {
>          uint8_T dataPtr[1];
>          ssGetElapseTimeCounter(S, dataPtr);
>     }
>      break;
>   case SS_DOUBLE:
>       {
>          real_T dataPtr[1];
>          ssGetElapseTimeCounter(S, dataPtr);
>      }
>       break;
>   default:
>     ssSetErrorStatus(S, "Invalid data type for elaspe time
>         counter");
>     break;
> }
>
> So here we see a 64 bit object SS_DOUBLE_UINT32 is available and maybe
> this can be used to change the current Etherlab code and permit access
> to 64 bit data.
>
> Before I plunge unto changes of this magnitude, taking into account my
> limited experience in this area, it would be nice if somebody can at
> least confirm if this would be the right approach.
>
> Thanks a lot!

-- 
------------------------------------------------------------------------

Richard Hacker
Ingenieurgemeinschaft IgH
Gesellschaft für Ingenieurleistungen mbH
Heinz-Baecker-Str. 34
D-45356 Essen
Tel.: +49 201 / 360-14-16
Fax.: +49 201 / 360-14-14
Mobil: +49 175 6822089
E-mail: ha at igh-essen.com

------------------------------------------------------------------------