Performance issue: recieve real-time encoder data via TCP

advanced
#22

Great setup! Nice installation! Are you using predetermined positions or arbitrary ones?
Is the data encoder on the winch axis?
did you wonder using infrared led on frame to capture the position via camera?
and lastly: are you sure the lag is only on network ? I mean if you are measuring delay by video frames.

I know they have this speed easing built in for the weight handling, so not very easy to anticipate positions. Once I had to individually calibrate 14 machines because of difference in chains and gears.

#23

dimitre,

Thanks
Encoder is sitting on the axis of the motor itself.
Predetermined positions for whatā€¦ ? not sure about your question.

Regarding infrared, yes thatā€™s actually the first idea that I had, when I was thinking about building this installation. (wellā€¦ actually the first idea was to hang the real LCD panelsā€¦). However Iā€™m sure it opens a whole new bag of worms. And Iā€™m sure there is a latency there too.

Iā€™m pretty sure by now, that lag is not on the network, but elsewhere. Apparently I recieve encoder data via UDP with only 3ms delay.

Yes, basically what Iā€™m doing now is writing procedures to physically simulate the behavior of the winches when breaking and accelerating. And yes, they do behave differently, so Iā€™m doing also something similar to dynotest for car engines. Running in different modes, adjusting values, plotting them and trying to find the function that fits. (or could use probably flat tables).

M

1 Like
#24

theo, a question for you. is there a way to resync the draw cycle to start from a particular moment in time ? I have a thread that is running at certain frequency (much higher, than 60hz). Whenever I get certain data, I need to start draw/update cycle from this particular moment. Is there a call for that ?

Or maybe another way around. From the thread to determine where we are in time relative to main cycle ?

Thanks
M

#25

Hmm,

Basically the main app and the thread are both looping.
As you said the thread is running much faster, so really the best you can do is set a bool or int in the thread and then read that value on the next ofApp::draw() call.

Speeding up the main app
( ofSetVerticalSync(false); and ofSetFrameRate(1000); also make sure your NVIDIA settings on PC are not forcing vertical sync on ) will help reduce the latency between when your threaded function wants to tell the main thread something and when the main thread can draw.

For any variable that you are changing in the main thread and your threaded function always wrap those changes around a

if( lock() ){
  //change a variable here 
  unlock();
}

Note: You canā€™t call draw(); from the threaded function due to the way OpenGL works.

Hope that helps!
Theo