ehFeedback error

Support
1

Hi Chris,
We’ve been sporadically getting the attached error (ehFeedback error, see stdout), and shortly after mWorks crashes.
Do you have thoughts on what might be causing it? Anything we can do other than restarting the computer/labjack?
Thanks,
Lindsey.

2

Attachment: Image_from_iOS.jpg (1.42 MB)

3

Hi Lindsey,

(Sorry for creating multiple discussions. The support site was being flaky, but it seems better now.)

I can’t say I have much insight in to the problem. It seems like a simple write to a digital output shouldn’t be failing, and certainly such a failure shouldn’t lead to MWServer crashing. This makes me think there’s memory corruption happening somewhere, and the write failure and crash are side effects of that.

Are you sure you’ve recompiled your plugin against the version of MWorks you’re using? If not, that’s definitely a potential source of memory corruption.

You might try following the suggestion in the error message and looking at stdout. The simplest way to do this is to launch MWServer from the command line via Terminal:

$ /Applications/MWServer.app/Contents/MacOS/MWServer

Any messages written to standard output or standard error will appear in the Terminal window. I don’t know if you’ll see anything helpful, but it’s possible you’ll get more detail about the write failure.

Cheers,
Chris

4

Hi Chris,
Here’s the output from stdout.
Do you think it’s a labjack failure- should we reach out to them?
Thanks,
Lindsey.

5

Attachment: Image_from_iOS_(9).jpg (3.29 MB)

6

Hi Lindsey,

The image you sent is of MWServer’s console window. (The error message in it indicates that you have more than one instance of MWServer running.) The standard output will be in the Terminal window from which you launched MWServer.

To see MWServer’s standard output:

  1. Close all running instances of MWServer.

  2. Open the Terminal application (in /Applications/Utilities on your Mac).

  3. In the Terminal window, enter

     /Applications/MWServer.app/Contents/MacOS/MWServer

    and press return. MWServer should launch.

  4. Run your experiment. MWServer’s standard output (if there is any) will appear in the Terminal window.

Chris

7

Hi Chris,
Thanks for clarifying. Here’s the stdout from the Terminal.
Interestingly (frustratingly) it was a different computer this time.
Lindsey.

8

Attachment: Image_from_iOS_(10).jpg (1.23 MB)

9

Hi Lindsey,

Thanks for sending that. Do you know if the “response buffer is too small” message happens at the same time as the “bug: writing digital output low” message in the MWServer console?

In any case, the “response buffer is too small” message indicates failure to receive a response from the U6, which is worrisome. Have you changed anything in your setup recently (e.g. macOS version, MWorks version, other USB devices)? Are you seeing the “bug: writing digital output low” with multiple U6 devices or just one?

It might be worthwhile to contact LabJack and see if they have any insight or recommendations.

Chris

10

Hi Chris,
We haven’t caught the moment that these errors appear (often they’re ~20
minutes into an experiment) so I don’t know about the relative timing, but
I assume they’re close.
Right now, this is happening on two different Labjacks. We have not
changed OS, Mworks or anything lately. We did swap out a computer
yesterday (with the same labjack) and it still crashed. There is some
(anecdotal) link to a specific variable condition, but I’ve been digging
through the code and can’t figure out why it would matter.
We’re getting in touch with Labjack now.
Thanks,
Lindsey.

11

Hi Chris,
Labjack says: “The error indicates that a transfer was bigger than the
maximum transfer size (64 bytes for our USB endpoints). You should ensure
that your transfers are always sized to be a multiple of the maximum packet
size. Also be sure you always send an even number of bytes (appending a
byte of 0x00 if the packet has an odd number of bytes).”
Any thoughts on what might cause transfers to be larger than expected?
Let me know if it’d be helpful to see our experiment code.
Lindsey.

12

Hi Chris and Lindsey,

We have been seeing errors like this too.

The relevant code here is the code I wrote a long time ago to control the labjack, so it will be shared in Lindsey’s current plug-in and ours. So hopefully we can find the same fix.

We have one machine whose hardware we think is failing, and are replacing it. I don’t know yet whether this is happening just on that rig or on others, and I’m asking my team now.

13

Hi Lindsey & Mark,

Based on your experiences, my current suspicion is that this issue stems from the ancient version of libusb that LabJack includes in their Exodriver package for macOS. (I just reinstalled the current release, and the bundled libusb binary has a creation date in 2012.)

Would either of you be willing to try a version of your U6 plugin built against a newer libusb? Since version 0.10, MWorks has shipped with a libusb binary. (It’s needed for the DATAPixx interface.) If you’re running MWorks 0.10 or later, then I can just update your plugin code to build against MWorks’ bundled libusb, which is very recent. If you’re using an older version of MWorks, things will be slightly more complicated, but we can make it work.

Thanks,
Chris

14

Hi Chris,
We are currently using 0.10 and would be happy to try an updated plugin.
I think you already have access to our plugin repository? It has diverged
a bit from Mark’s, so you may have to make the changes separately…
Lindsey.

15

Hi Lindsey,

We are currently using 0.10 and would be happy to try an updated plugin.

OK, great. I’ve attached a build of your plugin against MWorks 0.10 and its bundled libusb. To install the plugin, unpack the ZIP file, copy LabJackU6Plugin.bundle to the folder /Library/Application Support/MWorks/Plugins/Core, and restart MWServer. Once that’s done, please try running your experiment, and let us know how things go.

Thanks,
Chris

16

Hi Chris,
Tried the new plugin but it still crashed.
Lindsey.

17

Hi Lindsey,

Tried the new plugin but it still crashed.

OK, thanks for trying. I guess that leaves the plugin itself as the most likely source of the problem.

Let me know if it’d be helpful to see our experiment code.

I think that would be very helpful at this point. Can you send me the experiment that triggers the crash?

If possible, please include all associated files (images, sounds, etc.), so that I can reproduce the runtime environment as closely as possible. Also, I see that your plugin reads calibration info from some hard-coded paths (e.g. /Users/hullglick/Documents/Calibration_Table/led.txt.) Can you also include a copy of whichever file you’re using for the example experiment?

Thanks,
Chris

18

Great- thanks.
Here’s the bundle. I think it has all of the (non-matlab) dependent files,
but please let me know if it’s missing anything.
I’ve also included an example variable set- i485.xml. If you set
“doTestRobot” to 1, it will run on its own. Also- we’ve found that setting
“doFeedbackMotion” to 0 increases the likelihood of crashing (which is
strange because this should be less overhead)- so hopefully that will help
you replicate.
Lindsey.

19

Attachment: Glickfeld_2AFC_Experiment.zip (820 KB)

20

Thanks, I’m able to run the experiment. I haven’t seen any errors yet, but I’ll keep it running and will hopefully get a crash eventually.

Chris