Warning in GSD: User_Prm_Data truncated by User_Prm_Data_Len
arabel1a opened this issue · comments
I, probably, found a strange bug.
When i use pyprofibus via python console, everything is ok, but when i', trying to use pyprofibus-linuxcnc-hal with the same devices and config file, i get this warnings on both devices in profibus net. Also, it sends a garbage instead of parameters, devices report a faulty parametrization, and this again.
I've tried to add theese lines in "setup profibus stack" section:
print(str(slaveConf.gsd.getUserPrmData(dp1PrmMask=dp1PrmMask, dp1PrmSet=dp1PrmSet))).
to see, what it parses. The output is cutted: something like [0, 32, 0, 22, 95, 4, 138. (here is a prefix of correct User_Prm ). Probably it is cutted because of linuxcnc realtime tasks. But when i'm trying to run sudo python3 pyprofibus-linuxcnc-hal -W 0 without linuxcnc, it fails with "can not find hal_ module"
How to run pyprofibus-linuxcnc-hal without linuxcnc for debug tasks? Have you any ideas why the parser works correctly, but it sends strange parameters to devices?
master = config.makeDPM()
for slaveConf in config.slaveConfs:
slaveDesc = slaveConf.makeDpSlaveDesc()
dp1PrmMask = bytearray((
DpTelegram_SetPrm_Req.DPV1PRM0_FAILSAFE,
DpTelegram_SetPrm_Req.DPV1PRM1_REDCFG,
0x00))
dp1PrmSet = bytearray((
DpTelegram_SetPrm_Req.DPV1PRM0_FAILSAFE,
DpTelegram_SetPrm_Req.DPV1PRM1_REDCFG,
0x00))
# slaveDesc.setUserPrmData(
print(str(slaveConf.gsd.getUserPrmData(dp1PrmMask=dp1PrmMask,
dp1PrmSet=dp1PrmSet)))
master.addSlave(slaveDesc)
This piece of code is absolutely the same in my python script and pyprofibus-linuxcnc-hal. They lives in the same folder and uses the same config/gsd files. GSDs and config are attached.
You are running the module with python3, only master version of linuxcnc currently supports python3.
So, what is the way linuxcnc-demo-dymmyphy should be used? Parser works correctly only when is used under python3, but linuxcnc works only with python2.
Try development version of linuxcnc, it uses python3.
Well' i've done that. But there is a strange moment: data exchange is OK untill linuxcnc gui appearance. Then it get
State machine timeout! Trying to re-initializing slave xx/,
re-initializing slaves, trying to data exchange and get this error again.
Also, i've got a led on my RS485 adapter - it blinks rapidly (9600, i beleive), but as soon as linuxcnc interface is loaded - it starts blinking 2-3 times/sec, not faster. It looks like linuxcnc forbids accessing COM port faster, than its base thread.
I've tried to renice pyprofibus process, but if i do that - i get permission error. But linuxcnc dont wont to work with root privileges.
if i renice pyprofibus process manually, nothing is changed.
UPD when i run non-hal pyprofibus script and open linuxcnc, communication is not broken. So it is not realtime issues.
UPD2. Added slave.setOutData(txData) to main loop, everything works. thats kinda strange, that it isn't in original code. It just write nothing to slaves.
Thanks for your report.
I think the main loop probably got broken by this commit 98e062b
Pyprofibus is still supposed to work with Python 2, just because LinuxCNC stable releases still need it. As soon as LinuxCNC ships stable Python 3 support, I will drop Python 2 support from pyprofibus.
It becomes increasingly hard to test pyprofibus on Python 2 and especially hard on LinuxCNC.
Current Linux distributions don't ship the dependencies needed for Python 2 based LinuxCNC.
Therefore the latest commits/releases have not been fully tested with LinuxCNC and that caused the bug. :(
I'm very sorry for any inconvenience that may have caused.
I committed the slave.setOutData(txData) change to master.
Does that fix everything (including running on Python 2) for you?
Found and fixed another Python 2 incompatibility bug in the GSD parser.
As far as I can test it right now (no real hardware) latest master seems to work with LinuxCNC 2.8.2.
The fixes have been released as part of pyprofibus-1.10.
Please note that the pyprofibus LinuxCNC HAL module contains more bugs that are currently being sorted out in the master branch. See #21.