Do you have any idea why there's this 5V output on some of the rigs?
If the output isn't being initialized explicitly by the plugin, then it's possible that its initial state is just random or depends on some unknown details of the hardware and/or the USB connection. However, in the current code on GitHub, it looks like DAC0 is initialized explicitly to zero (here). If you're using this version of the code, then it certainly seems like the output should be zero after the experiment is loaded.
Do you know if you're using the latest version of the plugin code? If not, I recommend trying it on one of the Mac's where you're seeing the 5V output after loading. If the issue persists, maybe get in touch with LabJack and see if they have any recommendations?
I've been having an issue with the output of DAC0 where it turns on as soon as an experiment is loaded (before it is started) rather than when it should be triggered during the experiment. This is happening only on a subset of rigs- and while there isn't a clear correspondence between labjack code versions and the issue, it does seem to be that computers with updated labjack plugins and/or newer labjacks (maybe with updated drivers) tend to have this issue. I've checked the LabjackU6Device.cpp code and they are identical- so I'm leaning towards this being a driver issue. Is this an issue that either of you have seen before?
I'm responding here, because Shuyang recently reported this same issue. As I previously told Shuyang, the plugin code clearly initializes DAC0 to low. The fact that you see the issue only with certain rigs makes me think that something is going wrong on the LabJack device itself.
Perhaps your LabJack's have different firmware versions, and one version has a bug that's not present in other versions? I've attached a compiled version of LabJack's u6BasicConfigU6 example. If you run it in Terminal on a system with a LabJack connected, it will report the firmware version. For reference, here's what I see with my U6 Pro:
Thanks for sending this code. I cataloged the Labjacks on our rigs and the answer is unfortunately not simple. All of the rigs have the same BootloaderVersion, HardwareVersion, ProductID, LocalID, VersionInfo, and Device name:
There are three different FirmwareVersions: 1.35, 1.39 and 1.45. All of the Labjacks with 1.35 work as expected (DAC0 goes high when we set it high). However, those with versions 1.39 and 1.45 are a mixed group- some have DAC0 always high and some are modifiable. It's possible that in some cases the DAC0 high behavior is a failure mode of the Labjack- this could explain some of the variability with the group at 1.39, but not 1.45: all of the Labjacks that I know we've just taken out of the box in the last 6 months are 1.45 and have DAC0 high, but there is also one that has been in use for a few years that is 1.45 and does not have DAC0 high.
Despite it not lining up cleanly with the Firmware version, it does seem to be Labjack specific. If I swap Labjacks between rigs, the ones that drive DAC0 high do that on every rig, and the modifiable ones work on every rig.
The one exception to this is for a couple of rigs on which I recently updated the plugin (using the one that you sent already bundled to deal with the ehFeedback error). On both of these rigs, DAC0 has stopped working normally. If I put a DAC0 high labjack on them, then DAC0 is high, but if I put an otherwise functional Labjack on that rig DAC0 doesn't go on at all. I tried reverting to an older plugin, but this didn't solve the problem. All of the other code on these computers is identical.
As you suggested, I've been in contact with Labjack. They don't think there have been any changes in the Labjack that could explain this, and suggested that I try testing the devices independent of our plugin/software, tethering DAC0 to AIN and using the LJControlPanel to readout changes in AIN that way. I have to figure out how to use that software, so it may take me a bit. That at least might help me sort out if there are some with broken DAC0 and some that (at least with their code) work appropriately.
Just to loop you in, I just sent this email to Labjack:
"I've installed the LJControlPanel on a Windows machine and tested a bunch of our Labjacks- I've attached a zip file with screenshots for each one. The following Labjacks work as they should (where DAC0 goes high when we tell it to): Rig1LJ, Rig2LJ, G2PLJ, H2PLJ and IV2LJ.
All of the rest have DAC0 high as soon as the labjack is initialized. IVRigLJ and NewLJ were both just opened within the last 6 months.
While all Labjacks with Firmware 1.35 are "good", 1.39 and 1.45 are a mix of "good" and "bad"- so there doesn't seem to be any correlation between Firmware and DAC0 output.
Notably, this behavior is independent of which computer the Labjack is plugged into- it is Labjack specific. This matches with the fact that this also correlates with the measured output in DAC0 on the LJControlPanel- all of the "good" Labjacks have readings of 0 V- while the "bad" ones are all >0. Notably- all I did was connect these Labjacks to a new PC which just now had the LJControlPanel (and Labjack drivers) installed. There is no other Labjack-related software/plugins/etc on this computer (we do all of our experiments on Macs), and nothing other than the USB connected to the Labjack.
Please let me know if this DAC0 output is expected in the LJControlPanel and if there is anything that can be done to turn it off."
The partial correlation with firmware version makes me wonder if the issue is due to a manufacturing flaw with the more recent devices (firmware version 1.39 and 1.45), with DAC0 failing on some but not others. Hopefully, the LabJack folks will get back to you with some useful info.
Another thought: Have you tested DAC1 on any of your devices? If it behaves normally, you could move the laser power output to that pin instead.
I haven't explicitly tested DAC1. But looking at the LJControlPanel images
it seems like DAC1 is a mixed bag too with it being high on some and not
others (in this case a mix of 1.35 and 1.39)- and not correlated with DAC0.
I suppose I could set up the code to trigger both DACs and then just
connect whichever port works on each Labjack.
Did you have any thoughts about the other issue where the two rigs that
have the new plugin no longer drive DAC0 at all? I'm pretty sure it's an
issue of computer to Labjack communication, because when I swap in a
"broken" labjack that always has DAC0 on, that is still true.
But looking at the LJControlPanel images it seems like DAC1 is a mixed bag too with it being high on some and not others (in this case a mix of 1.35 and 1.39)- and not correlated with DAC0.
Now that I look more closely at those images, I don't understand what they're showing. When you say DAC1 is "high", do you mean that in image G2PLJ.PNG, for example, the value under DAC1 is 0.0028 instead of 0.0? But where does that value even come from? Isn't that the field where you would set the output value, not read its current state? You said LabJack suggested connecting DAC0 to an AIN, but I don't see any AIN values in the images you sent.
Did you have any thoughts about the other issue where the two rigs that have the new plugin no longer drive DAC0 at all? I'm pretty sure it's an issue of computer to Labjack communication, because when I swap in a "broken" labjack that always has DAC0 on, that is still true.
I don't know what to make of that. If you said that DAC0 stopped working when you installed the updated plugin, but worked again when you reverted to the old plugin, then I would think the new plugin was at fault. But you said that reverting to the old plugin didn't fix the issue. Is it only DAC0 that no longer works, or do other outputs fail, too?
> Now that I look more closely at those images, I don't understand what
> they're showing. When you say DAC1 is "high", do you mean that in image
> G2PLJ.PNG, for example, the value under DAC1 is 0.0028 instead of 0.0? But
> where does that value even come from? Isn't that the field where you would
> *set* the output value, not read its current state? You said LabJack
> suggested connecting DAC0 to an AIN, but I don't see any AIN values in the
> images you sent.
Yes- you're right. I did not connect DAC0 to AIN yet. That is because I
noticed that there was a 100% correlation between Labjacks that have
non-zero DAC0 values and those that misbehave with DAC0 output. My
impression from the Labjack guys is that that is both a place to read and
set the output value. Apparently, each Labjack is calibrated and has a
default output offset, some of which are non-zero, to linearize output. I
can read these offsets with a multimeter- so they are real. As you point
out, there is a magnitude mismatch- the offsets are max ~12mV, but I always
see ~4.8V in the constant output when the plugin/experiment is loaded. So
there is still some transformation that is happening between the default
settings and the output that we're measuring- but the 100% correlation
makes me think that they're still related. At the tech's suggestion, I
tried resetting the DAC0 value to 0; however, when I unplug and reload it,
it reverts back to its default offset, and I still get constant output in
our setup. I've sent this info to the tech, and am waiting on their next
> I don't know what to make of that. If you said that DAC0 stopped working
> when you installed the updated plugin, but worked again when you reverted
> to the old plugin, then I would think the new plugin was at fault. But you
> said that reverting to the old plugin didn't fix the issue. Is it only DAC0
> that no longer works, or do other outputs fail, too?
I agree- the fact that reverting the plugin doesn't solve it is strange.
However, we just updated a third computer with the new plugin (to solve the
ehFeedbackError), and now it no longer modulates DAC0 output either (though
it does go high if I put a broken one on it). We use FIO0 for reward
delivery, and it seems to be fine. Is there anything that would get
updated/rewritten when this new plugin is used that wouldn't simply get
rewritten when it's reverted?
The Labjack guys just wrote to me and said that since they're unable to
replicate my issue I should send them one of my misbehaving Labjacks so
they can check it out. However, given that I only see the large output
once I have loaded an experiment, I'm skeptical that they're going to be
able to help me troubleshoot this. Maybe a better idea would be for me to
send you a misbehaving Labjack instead? Or can you look and see if any of
your labjacks have non-zero DAC0 values, and if so, check what the output
looks like when you load an experiment?
I agree- the fact that reverting the plugin doesn't solve it is strange. However, we just updated a third computer with the new plugin (to solve the ehFeedbackError), and now it no longer modulates DAC0 output either (though it does go high if I put a broken one on it). We use FIO0 for reward delivery, and it seems to be fine. Is there anything that would get updated/rewritten when this new plugin is used that wouldn't simply get rewritten when it's reverted?
That is very distressing. As far as I know, nothing the plugin does should be persistent. That said, I don't know what LabJack's interface library code does internally. I suppose it's possible that it writes some persistent configuration info to the device, but I don't know (1) why it would do so or (2) why that would break DAC0.
Maybe a better idea would be for me to send you a misbehaving Labjack instead? Or can you look and see if any of your labjacks have non-zero DAC0 values, and if so, check what the output looks like when you load an experiment?
Yes, it might be more fruitful for me to have a look first. Let me see if I can reproduce the issue with my U6. If not, then you can ship me one of yours.
I was able to reproduce this issue on my U6, and I think I've figured out how to fix it. I've attached a build of the plugin (compiled against the current MWorks nightly build) that contains the fix. Could you try this out and see if it restores normal behavior for DAC0 on your hardware? To install it, unpack the ZIP file, then copy LabJackU6Plugin.bundle to /Library/Application Support/MWorks/Plugins/Core as usual.
If my conclusions are correct, the problem stems from a longstanding issue in the U6 example code provided by LabJack. I'll provide more details and a pull request with the fix once you've confirmed that it works for you.
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.
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.
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
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?
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.
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.
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!
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.
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
Do you see tBlock2TrialNumber getting set to 1 on each trial?