Terminating: GSD 'HIL_0B69.gsd': DPv1 User_Prm_Data is shorter than 3 bytes

[derekyu56]

I have a GSD file from Hilscher that has "DPV1_Slave = 1" indicates it support DPV1. Going through pyProfibus it generated the above error in getUserPrmData() in interp.py . Judging from the code, it seems there are relationship between DPV1 and "User_Prm_Data", "User_Prm_Data_Len", "Ext_User_Prm_Data_Const", and "Ext_Module_Prm_Data_Len". These parameters are not in the GSD file. I cannot find these requirements in the Profibus Specification.

It works fine after I changed "DPV1_Slave = 0".

[mbuesch]

Thanks for your report.
Can you please send the GSD file via mail to me, so that I can reproduce the behaviour?
Thanks.

[derekyu56]

File attached.

HIL_0B69.zip

[mbuesch]

Thanks.

I checked this problem and what I found out is:

• The GSD parser currently does not parse Bit() or BitArea() definitions.
• The GSD interpreter currently does not interpret the ExtUserPrmData fields.
• Unknown/unimplemented sections are simply ignored.

That is why the UserPrmData ends up with size 0 instead of size 5 as specified in your GSD.

That's why I currently consider this a missing feature rather than a bug. The GSD parser isn't fully prepared to parse all details of your GSD file, yet. There are a couple of other ignored fields as well. These will be shown, if GSD parser debugging is enabled (set debug=True in the parser.py file)

[mbuesch]

Please also note that you probably won't get your device working, if the UserPrmData from the GSD file is ignored by pyprofibus. That is unless you somehow hack the code and hardcode the required UserPrmData somewhere.

[derekyu56]

I appreciate very much for spending the time to investigate the issue. Despite these missing features, I believe the pyprofibus will still be a very good application to help my Profibus application development.
Thanks for a job well done.

[mbuesch]

Re-opening the issue, to keep track of this feature, because it should be implemented at some point.

I think it is fairly easy to work around this missing feature, by just hard coding the required UserPrmData in the user code that uses pyprofibus for a particular device. However the plan is to also have this GSD feature to be part of pyprofibus. If you have any enhancements to pyprofibus, that are of general use, please feel free to create pull requests. Your help is greatly appreciated.

[derekyu56]

Currently I can get around the problem by setting "DPV1_Slave = 0" to remove DPV1 support. If I do need DPV1 support, I will consider come back and see if I can contribute to this issue.

[mbuesch]

That will silence the error message, but the root of the problem will still persist.
No valid UserPrmData will be generated and no UserPrmData will be sent to the slave. The slave probably won't successfully pass configuration state and probably won't enter Data_Exchange without valid UserPrmData.

[derekyu56]

In my module configuration, I only have the following defined:
module_1=16 Bytes In
module_5=16 Bytes Out
This is working fine:
DPM1: Trying to initialize slave 2...
PHY-serial: TX 10 02 7D 49 C8 16
PHY-serial: RX 10 7D 02 00 7F 16
DPM1: slave[02].state --> 'wait for diag'
DPM1: Requesting Slave_Diag from slave 2...
PHY-serial: TX 68 05 05 68 82 FD 6D 3C 3E 66 16
PHY-serial: RX 68 0B 0B 68 FD 82 08 3E 3C 02 05 00 FF 0B 69 7B 16
DPM1: slave[02].state --> 'wait for Prm'
DPM1: Sending Set_Prm to slave 2...
PHY-serial: TX 68 0C 0C 68 82 FD 5D 3D 3E B8 C8 01 00 0B 69 01 4D 16
PHY-serial: RX E5
DPM1: slave[02].state --> 'wait for Cfg'
DPM1: Sending Chk_Cfg to slave 2...
PHY-serial: TX 68 07 07 68 82 FD 7D 3E 3E 9F AF C6 16
PHY-serial: RX E5
DPM1: slave[02].state --> 'wait for Data_Exchange-ready'
DPM1: Requesting Slave_Diag (WDXRDY) from slave 2...
PHY-serial: TX 68 05 05 68 82 FD 5D 3C 3E 56 16
PHY-serial: RX 68 0B 0B 68 FD 82 08 3E 3C 00 0C 00 7D 0B 69 FE 16
DPM1: slave[02].state --> 'Data_Exchange'
DPM1: Initialization finished. Running Data_Exchange with slave 2...
PHY-serial: TX 68 13 13 68 02 7D 7D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FC 16
PHY-serial: RX 68 13 13 68 7D 02 08 01 23 45 67 89 AB CD EF 01 23 45 67 89 AA BB CC D1 16
PHY-serial: TX 68 13 13 68 02 7D 5D 10 0F 0E 0D 0C 0B 0A 09 08 07 06 05 04 03 02 01 64 16
PHY-serial: RX 68 13 13 68 7D 02 08 01 23 45 67 89 AB CD EF 01 23 45 67 89 AA BB CC D1 16
............

[mbuesch]

Ok. Fair enough. So your device is not as picky about missing data as mine. :)

[looninho]

Hi,
maybe question for @derekyu56: did you use rs485 physical link? If yes, did you use bus termination even if there is only 1 slave device on the bus?
I get :
DPM1: Trying to initialize slave 8...
DPM1: RX error: PHY-serial: Failed to get received telegram size:
Invalid telegram format.
......

[derekyu56]

I used a RS232 to RS485 dongle from HMS. It is a direct connection to one slave using a serial cable with no terminator.

[looninho]

thank you! Le jeu. 23 avr. 2020 à 20:26, derekyu56 <[email protected]> a écrit :

…

I used a RS232 to RS485 dongle from HMS. It is a direct connection to one slave using a serial cable with no terminator. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACH6NZQ3Z7YZYDANX2FST7TROCB45ANCNFSM4MIATC6Q> .