timeout exception and hangs

[luzik]

When i run PTC.get_temperature() on my software init stage ..everything works fine! after initing more bricklets, and running some threads PTC.get_temperature throws TIMEOUT error (other bricklets works just fine).

In same software i use DC brick. Motor run till some points where it is mechanically stopped so i have to use DC.get_current_consumption() to turn it off. In normal operations DC.get_current_consumption() works fine, but after my program inits DC.get_current_consumption() hangs.

I am using python language.

I am using master and DC bricks with 6 connected bricklets.

I am connecting to master brick via usb.

 

I know that this is not to much information. I will try to isolate problem, and then put some more info in this topic, but maybe You have some hints ?

[remotecontrol]

You use multiple threads?

 

If you send commands to the stack from within a callback you must be aware that only one callback can be active at a time and you should not wait in a callback for the execution of another callback.

[luzik]

Callbacks are registered only from main process. There are no Callbacks registered from PTC or DC modules. I will try to disable them anyway.

In main thread I created tf class where I init all TF hardware, then I use tf.ptc as argument for multiprocessing.Process() fork function. Is it ok ? Maybe i should init ptc from within forked process ?

tf.ssr (SolidStateRelay) work fine in this way.

[remotecontrol]

You are using Linux?

 

Then python's fork() should call Linux' fork() and would copy the process and if you don't execute another program in the forked process, you have a clone of the parent process with different address space.

 

Both proesses share open file and network handles and I don't know what happens in this case with the IPConnection. In forked() processes I would open a new IPConnection (so start the init after fork()).

[luzik]

Yes it is linux, where fork() do 'copy-on-write' - so if i understand correctly it will copy whole object only when i try write to it. I don't know if DC.get_current_consumption() or PTC.get_temperature() anyhow alter base object, Maybe this is a reason. I will definitely try this!.

 

It is OK for brickd to share multiple connections with same bricklet ?

[remotecontrol]

Yes it is OK, to use a Bricklet from multiple clients.

 

But I think the fork() is a problem for the network connection:

if you fork() after a call to IPConnection.connect() then both processes share the same network port. If both processes still use this port, then this will lead to confusion.

 

This might be OK as long as only one child uses the connection, but is not OK if both processes read and write to that connection. In this case each process needs an own connection (IPConnection opened within the forked process).

[luzik]

Yes! python multiprocessing was an issue.

Thank You remotecontrol for this hint !

 

Creating new ipconnection from new process resolve problem.

 

Maybe there is a space to improve in this area inside tinkerforge.ip_connection ?

...to automagicaly create new connection if proccess pid changes ?

..somehow

[remotecontrol]

I'm not a Python specialist, but Python also has a native thread implementation if you would use start_new_thread.

 

With "real-threads" (all in one process) you don't have such problems, I use quite a lot of threads in C++ and Java.

 

But if you fork() the process is different and that is not the "regular" usage for the IPConnection ...