If you use a debugger on a C program that uses the Sensel API, set a breakpoint, and hit the breakpoint after calling a few APIs, all subsequent APIs will fail (with a “Failed to receive ack from sensor” error). I believe that any pause (due to a breakpoint or some other non-debug-related pause in the program) will cause the same failure. I noted this behavior very early on (at this no-longer-valid link):
but that issue didn’t make it over to this new forum. This issue can often be worked around, but ultimately this is a pretty serious issue, since if someone ships a program that uses the API, and that program pauses after startup, for any reason, it will fail completely. I currently use a separate executable for tracking things with the Morph, and send OSC/TUIO to a second program. I would like to embed Morph support directly in the second program, but this issue prevents me from doing that.
This issue continues to plague me - I’m now actively trying to embed Morph support inside a FreeFrame plugin, to make it easier to distribute rather than requiring/using the separate TUIO server in github.com/nosuchtim/TUIO3D_Sensel.git. After embedding it, I’m finding the same issue - after pausing in a debugger, all APIs fail.
Sorry for the delay. We are looking to add a register to the Morph that allows you to keep it the protocol open and prevent the device from timing out (which is causing the issue during pause). I will make sure to post here when the update has been released.
Facing this error as well while working on a TouchDesigner mod. It’s difficult to figure out where to initialize the handles if I’m unsure when readSensor will be called next.
Hi Tim, sorry for no updates. The previous solution ended up not working but we have a few other potential solutions. I will try to keep this thread updated when they are tested.
Hi. I’m curious if if this issue got resolved. Not only for the content but also to see how developer issues are addressed. I’m curious before I start investing too much time developing with this product. Seems like Tim is a pretty active developer and if his concerns aren’t being addressed then that’s not a very good sign.
Since my Morph-accessing software is now bug-free I’m not affected by this anymore. Using the Morph API from a separate program and sending TUIO to other processes is a good way of insulating the Morph code from delays that might kill it, and in my experience the API has been very reliable otherwise for a 24/7 installation.
Thanks for the info Tim! Are you pretty happy with the product? I probably won’t be using it the traditional way. I will be experimenting using it as input for other types of things.
I’m much more than “pretty happy”; I’m thrilled and delighted with the product. It is a dream come true for me, and I say so explicitly in talks I’ve given recently about my experience with three-dimensional input devices (see https://timthompson.com/talks). I’ve never used an overlay or MIDI map on the Morph; I’ve only used it by writing custom code with their SDK.
Hi Alex - I’m now experiencing this problem in an actual application, not just when debugging. Specifically, when the computer I’m using is very heavily loaded (CPU-wise), occasional delays in the execution of my application (which does nothing but query the Morph continuously) causes my application to get into an infinite “Failed to receive ack from sensor” situation that doesn’t resolve itself when the CPU becomes less heavily loaded. Did any other potential solutions get implemented/tested?
Alex worked with Tim to resolve this issue. Wanted to share the fix with everyone!
To remain connected over Serial and prevent the timeouts, write 255 into register 0xD0.
unsigned char val[1] = { 255 };
senselWriteReg(handle, 0xD0, 1, val);
This will keep the serial open until you write 0 into register 0xD0 or you unplug/replug."
I’m not affected by this anymore. Using the Morph API from a separate program and sending TUIO to other processes is a good way of insulating the Morph code from delays that might kill it, and in my experience the API has been very reliable otherwise for a 24/7 installation.
