HI
i have a problem after i clone PyPLC device server when i want to run this device it shows me an error i dont know what to do ?
what error do you get? How did you clone the device server?
Hi Faissal,
We would need a bit more of information to solve the issue.
Try my latest version of PyPLC from github and paste here your errors:
Sergi Rubio
when im wiring the plc i configure the plc modbus communication therefore i configure the ip of my pc when i run the device server ,the state attribute shows me “unknown”, it didn’t recognize the plc.
Hi Andy ,Sergio
i clone the device server with ‘git clone’ command from the github.
when i call the init method the terminal shows me this instruction :
ModbusMap> Wrong Definition!:%s2
Defining ModbusMap property is not required unless you many variables to read (>50). Try first by reading 10 registers from your Modbus device (e.g. PyTango.DeviceProxy(‘your/modbus/device’).ReadHoldingRegisters([0,10]) ) and then create an attribute returning this same values:
DynamicAttributes:
ARRAY=DevVarLongArray(ReadHoldingRegisters([0,10]))
Regarding Modbus with siemens (which I never tried before), I answered in the other thread:
Hi Sergio,
Thanks for this thread.
I have a issue when creating new PyPLC DS instance, i’ve got these errors:
tango-cs@tango9-vm:~/Downloads/PyPLC-master/PyPLC$ python PyPLC.py PLCtest
Failed to import EventChannelFactory notifd/factory/tango9-vm from the Tango database
Applying FullTangoInheritance from <class ‘main.PyPLC’> and <class ‘fandango.dynamic.DynamicDS’>
Updating PyPLCClass from DynamicDSClass
Updating PyPLCClass.attr_list from DynamicDSClass
Updating PyPLCClass.class_property_list from DynamicDSClass
Updating PyPLCClass.cmd_list from DynamicDSClass
Updating PyPLCClass.device_property_list from DynamicDSClass
In DynamicDS.CreateDynamicCommands(PyPLC/PLCtest)
class = PyPLC; classes = [‘dserver/PyPLC/PLCtest’, ‘DServer’]
devs =
Out of DynamicDS.CreateDynamicCommands(PyPLC/PLCtest)
In DynamicDSClass.new(<class ‘fandango.interface.inheritance.PyPLCClass’>): updating properties
DynamicSpectrumSize property NOT found in database
In PyPLCClass constructor
In DynamicDSClass.dyn_attr()
In DynamicDSClass.new(<class ‘fandango.interface.inheritance.PyPLCClass’>): updating properties
DynamicSpectrumSize property NOT found in database
In PyPLCClass constructor
Segmentation fault (core dumped)
tango-cs@tango9-vm:~/Downloads/PyPLC-master/PyPLC$
Is it the first time you launch this device or it was running already in the past?
Segmentation fault at startup may occur if you have configured a polling period for an attribute that has been later renamed or removed.
Is that the case?
Sergi
Hi Sergi,
it’s the first time.
Regards
… could you try to generate a corefile and paste here the backtrace?
> ulimit -n 99999
> ... run PyPLC and generate a "core" file after the segfault
> gdb -c core -f /usr/bin/python
#> bt
If you can paste here the contents of your PyPLC properties (hiding IP’s) I can crosscheck if everything is ok.
Hi Sergi,
1 : i can’t run ulimit -n 99999. i got this message:
bash: ulimit: open files: cannot modify limit: Operation not permitted
2 : i run gdb -c core -f /usr/bin/python
#> bt
but i got these message:
tango-cs@tango9-vm:~/Downloads/PyPLC-master/PyPLC$ gdb -c core -f /usr/bin/python
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “x86_64-linux-gnu”.
Type “show configuration” for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type “help”.
Type “apropos word” to search for commands related to “word”…
Reading symbols from /usr/bin/python…(no debugging symbols found)…done.
/home/tango-cs/Downloads/PyPLC-master/PyPLC/core: No such file or directory.
(gdb) bt
No stack.
(
3. PyPLC properties:
DynamicAttributes
T1=int(Reg(0000))
T2=int(Reg(0001))
T3=int(Reg(0002))
Modbus_name = mdb/test/1
Modbus DS properties
- Device Info ----------------------------------------
Device: mdb/test/1
type_id: IDL:Tango/Device_5:1.0
iiop_version: 1.2
host: tango9-vm (10.0.2.15)
alternate addr.: 192.168.210.104
port: 45546
Server: Modbus/MDBT
Server PID: 4697
Exported: true
last_exported: 31st May 2017 at 16:21:33
last_unexported: ?
- Polling Status -------------------------------------
Thanks
Hello,
If I were you I would try:
ulimit -c unlimited
instead of the ulimit command suggested by Sergi…
I think the idea here is to configure Linux to create a core file when there is a crash of a process.
I recommend you to have a look at what is gdb (GDB: The GNU Project Debugger) and what does the ulimit command (ulimit Man Page - Linux - SS64.com)
So if this ulimit command succeeds, the next time your PyPLC server will crash, it will create a core file.
gdb is a debugger which will allow us to locate which part of the code caused the crash… but you need to have a core file generated to be able to analyze it.
It might be that your Linux distribution will generate a core file having a name different than “core” so you will have to adapt the name of the core file passed after -c option of gdb. It might also be that it will create this core file in a special directory. You may refer to your Linux distribution documentation/community to know this location if this is the case.
Hoping this helps,
Reynald
Hi
i add the core compressed file to this link
https://drive.google.com/open?id=0B6VsJcfDEMQreUhXbWJtS29nQkE
Regards
Now that you have the core, run again GDB on it to obtain the backtrace (it has to be done in the very same machine)
run gdb -c core -f /usr/bin/python
#> bt
Hi Sergi
this is the trace :
tango-cs@tango9-vm:~/Downloads/PyPLC-master/PyPLC$ gdb -c core -f /usr/bin/python
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/python...(no debugging symbols found)...done.
warning: core file may not match specified executable file.
[New LWP 9614]
[New LWP 7795]
[New LWP 7797]
[New LWP 7799]
[New LWP 7800]
[New LWP 7801]
[New LWP 9610]
[New LWP 7868]
[New LWP 7688]
[New LWP 7685]
[New LWP 7798]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `python PyPLC.py PLCT'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000000111 in ?? ()
Traceback (most recent call last):
File "/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19-gdb.py", line 63, in <module>
from libstdcxx.v6.printers import register_libstdcxx_printers
ImportError: No module named 'libstdcxx'
(gdb) bt
#0 0x0000000000000111 in ?? ()
#1 0x00007fc4777a4861 in ~auto_ptr (this=0x1704e60, __in_chrg=<optimized out>)
at /usr/include/c++/4.8/backward/auto_ptr.h:170
#2 boost::python::objects::pointer_holder_back_reference<std::auto_ptr<CppDeviceClassWrap>, CppDeviceClass>::~pointer_holder_back_reference (this=0x1704e50,
__in_chrg=<optimized out>)
at /usr/include/boost/python/object/pointer_holder.hpp:88
#3 0x00007fc476a20907 in ?? ()
from /usr/lib/x86_64-linux-gnu/libboost_python-py27.so.1.54.0
#4 0x00000000004f7148 in ?? ()
#5 0x00000000004ad7ec in _PyObject_GenericSetAttrWithDict ()
#6 0x00000000004d6436 in ?? ()
#7 0x00000000004adb99 in PyObject_SetAttr ()
#8 0x000000000049a356 in PyEval_EvalFrameEx ()
#9 0x00000000004a1c9a in ?? ()
#10 0x00000000004dfe94 in ?? ()
#11 0x00000000004dc9cb in PyEval_CallObjectWithKeywords ()
#12 0x00000000005a65b1 in PyEval_CallMethod ()
#13 0x00007fc4777a3032 in call_method<void, Tango::DevVarStringArray const*> (
name=0x7fc47783e17f "device_factory", a0=<synthetic pointer>,
self=0x7fc4707047e0) at /usr/include/boost/python/call_method.hpp:66
#14 CppDeviceClassWrap::device_factory (this=<optimized out>,
dev_list=0x7fc4667fbbf0)
---Type <return> to continue, or q <return> to quit---
at /tmp/PyTango/src/boost/cpp/server/device_class.cpp:222
#15 0x00007fc476e102da in Tango::DServer::init_device() ()
from /usr/lib/x86_64-linux-gnu/libtango.so.8
#16 0x00007fc476e0e1d3 in Tango::ServRestartThread::run(void*) ()
from /usr/lib/x86_64-linux-gnu/libtango.so.8
#17 0x00007fc474ab0673 in omni_thread_wrapper ()
from /usr/lib/libomnithread.so.3
#18 0x00007fc479140182 in start_thread (arg=0x7fc4667fc700)
at pthread_create.c:312
#19 0x00007fc478e6d47d in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Regards
Hi,
Here we have something to search for. I’ll have a look and come back with an answer next week.
Sergi
Hi,
I’m very sorry but I couldn’t replicate the error. My guess is that something stored in the Tango DB is corrupting somehow the loading of properties.
Could you create a new PyPLC device server with all properties empty except Modbus_name and see if the error also occurs?
Sergi
In case of need, you may have a look to the new C++ equivalent of PyPLC.
I think is property-compatible so you may use it as an alternative if your error persists:
https://www.ict.inaf.it/indico/event/514/session/8/contribution/47/material/slides/2.pptx