# Show\_data\_type\_info.py script gives different signatures for one custom message

**URL:** <https://forum.opencyphal.org/t/show-data-type-info-py-script-gives-different-signatures-for-one-custom-message/539>\
**Category:** Libcanard\
**Created:** [June 24, 2019, 6:56am UTC](https://forum.opencyphal.org/t/show-data-type-info-py-script-gives-different-signatures-for-one-custom-message/539 "2019-06-24T06:56:21Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sergey\_Frolov](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/s/b19c9b/32.png) [@Sergey\_Frolov](https://forum.opencyphal.org/u/Sergey_Frolov)\
**Post date:** [June 24, 2019, 6:56am UTC](https://forum.opencyphal.org/t/show-data-type-info-py-script-gives-different-signatures-for-one-custom-message/539/1 "2019-06-24T06:56:21Z")

</div>

Hello. I have any troubles with calculating signature for custom message. If I use python 2.7 I get a valid value of signature (0x2bde13409f972973). If I use Python 3.7 and`-c` prefix I get another value of signature…(0x5e68a28c75b35c1e) And…  
If I copy \*.uavcan message to Python37 namespace (for calling without -c prefix) I get third(!) variation of signature. (0x17CCB115141356EF)  
Something is wrong…  
I really confused. For basic messages signatures no difference for any versions of Python. But if I try to make it for custom message, script returns different values.  
Why this happens?  
Thanks.

---

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [June 24, 2019, 7:53pm UTC](https://forum.opencyphal.org/t/show-data-type-info-py-script-gives-different-signatures-for-one-custom-message/539/2 "2019-06-24T19:53:49Z")

</div>

> [@Sergey\_Frolov](#):
>
> If I copy \*.uavcan message to Python37 namespace (for calling without -c prefix) I get third(!) variation of signature. (0x17CCB115141356EF)

The signature depends on the namespace so it’s natural that you get a different result after the namespace is changed.

The other one looks suspicious. Could you please share your data types here and show which exact commands you use when invoking the script?

---

<div class="post-metadata">

**Author:** ![Sergey\_Frolov](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/s/b19c9b/32.png) [@Sergey\_Frolov](https://forum.opencyphal.org/u/Sergey_Frolov)\
**Post date:** [June 26, 2019, 2:25pm UTC](https://forum.opencyphal.org/t/show-data-type-info-py-script-gives-different-signatures-for-one-custom-message/539/3 "2019-06-26T14:25:56Z")

</div>

Hello. We have such message  
20501.FuelEngineSensors.uavcan

```auto
#
# Message with sensor data fuel engines
#

```

```auto
uint8 id

float16 temperature
float16 temperature_oil
float16 temperature_carb_input
float16 pressure_fuel
float16 pressure_oil
float16 pressure_boost
uint8 shavings_oil
uint16 rpm

```

And we get different signature, depending where \*.uavcan is laying (in default or custom path (-c prefix used))

---

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [June 26, 2019, 4:01pm UTC](https://forum.opencyphal.org/t/show-data-type-info-py-script-gives-different-signatures-for-one-custom-message/539/4 "2019-06-26T16:01:20Z")

</div>

Please show us the directory structure containing the file and which exact commands you use.

---

<div class="post-metadata">

**Author:** ![Sergey\_Frolov](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/s/b19c9b/32.png) [@Sergey\_Frolov](https://forum.opencyphal.org/u/Sergey_Frolov)\
**Post date:** [August 19, 2019, 5:18am UTC](https://forum.opencyphal.org/t/show-data-type-info-py-script-gives-different-signatures-for-one-custom-message/539/5 "2019-08-19T05:18:07Z")

</div>

Topic closed. We used different paths to files, that caused problems. Now its ok