Btw- does this new plug-in fix both of the issues that we’ve been having (the high DAC0 output on some Labjacks and the lack of modulated DAC0 output with the most recent plugin)?
I only saw the first issue with my U6, and that’s what I fixed. It’s possible the other issue is related and the new plugin will fix it, too, but I don’t know.
Chris
Hi Chris,
The new plugin doesn’t work- I get the “no factory for object type” error.
Lindsey.
Huh. I just tried using the plugin on my work Mac (built it on my home Mac). When I launch MWServer, I get a pop-up window saying, “LabJackU6Plugin.bundle can’t be opened because Apple cannot check it for malicious software.” I’m not sure why that’s happening. I was able to work around the issue by going to System Preferences → Security & Privacy → General and clicking “Allow Anyway” next to the message saying the plugin was blocked (see attached image). After doing that and re-launching MWServer, the plugin loaded correctly.
Did you get that error message, too? If so, can you try manually allowing the plugin as I described? If that doesn’t work, I’ll push my fix to GitHub so you can build the plugin yourself. I won’t be able to do that today, though, since that code is on my home Mac.
Chris
Attachment: allow_plugin.jpg (172 KB)
No- that is not the issue.
I am able to launch both the Server and Client, and connect. It is only
when I load an experiment that I get the error. It is definitely the new
plugin since I can swap back to the previous plugin and load the experiment.
Lindsey.
OK. Can you run the following command in Terminal and send me the output? If MWServer is running, please close it first, as this command will open it again:
MWORKS_WRITE_MESSAGES_TO_STDERR=1 /Applications/MWServer.app/Contents/MacOS/MWServer
If the LabJack plugin is failing to load, there should be some error messages about that in the output.
Thanks,
Chris
Hi Chris,
I think there was an error with the unzipping- it now loads.
And it does resolve the DAC0 high issue. However, there is still no
modulation of DAC0 output with this plugin (I tried using a labjack from a
different rig that had normal DAC0 output this morning, and there’s
nothing).
I think you should have a copy of my experiment that you could try. Would
you take a look to see if you’re getting appropriate DAC0 output?
Thanks,
Lindsey.
OK, thanks for the update. I can do some more testing on Monday. Should I use the experiment attached to this comment (Glickfeld_2AFC_Experiment.zip)?
Chris
Yes- that’s the correct experiment. And this variable set should set DAC0
high when the stimulus goes on.
Thanks,
Lindsey.
Attachment: test_human.xml (14.4 KB)
Hi Lindsey,
Using the latest plugin code, the DAC output definitely works for me. I have an LED connected to DAC0 on my U6. When I set the variable tTrialLaserPowerMw to a non-zero value, the LED goes on. If I set it back to zero, it turns off. To confirm that your device does the same, try running the attached experiment, which just toggles tTrialLaserPowerMw between 10 and zero every second.
The problem with your experiment is that it never sets tTrialLaserPowerMw to anything but zero. It looks like the variable trialLaserPowerMw is meant to determine the “on” state power for the laser. However, both the experiment code and the variable set you sent me set this variable to zero. If I set trialLaserPowerMw to 10, then I see my LED periodically go on and off, just as it does in the demo experiment. (There’s also a block2TrialLaserPowerMw variable, which is also assigned to trialLaserPowerMw under some conditions and is set to 3 in your variable set. However, it’s not clear it was ever used in my test runs.)
As for why your experiment code works correctly with an older version of the plugin, my best guess is that some code change (by someone on your end, not by me) altered the behavior of the plugin with respect to DAC output. I see that GitHub user ziyeye has made a number of changes, some of which definitely touch on the DAC control bits. Do you know what version of the code the “old” plugin was built from? I’m guessing it predates some of these changes.
Cheers,
Chris
Attachment: dac_cycle.mwel.zip (524 Bytes)
Hi Chris,
Thanks for checking this, we will give your reduced code a try.
However, I’m confused that tTrialLaserPowerMw is always zero. It gets set
on line 1553 of that code, if tTrialLaserPowerMw_trigger is greater than 0,
which it should be on line 1349 for “block2” trials (which all trials are
in the experiment that I sent you).
Yes- Ziye had made changes to our plugin to use DAC0 to drive LED/laser
output ~five years ago. This is one of the ways that our plugin currently
diverges from Mark’s. However, I don’t know what “base” she used for those
changes- and I had assumed that all changes you’d been sending us were off
of her base. And I’m not sure how to hunt these origins down.
Lindsey.
As for why your experiment code works correctly with an older version of the plugin, my best guess is that some code change (by someone on your end, not by me) altered the behavior of the plugin with respect to DAC output.
Oh, wait – you said that reverting to an older plugin didn’t restore DAC0 output, right? Never mind, then, and apologies to ziyeye!
Chris
Yes- that’s correct. Reverting to the previous build of the plugin didn’t
enable DAC0 output.
However, I’m confused that tTrialLaserPowerMw is always zero. It gets set on line 1553 of that code, if tTrialLaserPowerMw_trigger is greater than 0, which it should be on line 1349 for “block2” trials (which all trials are in the experiment that I sent you).
In the version I have, tTrialLaserPowerMw_trigger is set to the value of either trialLaserPowerMw or block2TrialLaserPowerMw. As I said, I don’t know if block2TrialLaserPowerMw was ever used in my test, but trialLaserPowerMw was definitely always zero. Manually making it non-zero caused my LED to go on.
Chris
Yes, in the variable set I sent you, trialLaserPowerMw is 0, but
block2TrialLaserPowerMw is set to 3.
It’s set so that 100% of trials are block2 so it should use the
block2TrialLaserPowerMw.
Do you see tBlock2TrialNumber getting set to 1 on each trial?
Do you see tBlock2TrialNumber getting set to 1 on each trial?
No, it’s always zero.
That’s very strange.
doBlock2 and doBlock2SeparateOdds are both set to 1?
And block2TrPer80Level1 = 80?
I’ll make sure that tBlock2TrialNumber is being set on our end…
Lindsey.
doBlock2 and doBlock2SeparateOdds are both set to 1? And block2TrPer80Level1 = 80?
Yes to all.