Jump to content

timeout exception and hangs


luzik

Recommended Posts

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 ?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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()).

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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 ...

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...