Hi Chris,
This is Shuyang in Court Hull’s lab at Duke. I was setting up a new experiment recently and found something weird. On some of our rigs, there is a 5V output between port DAC0 and Ground once an experiment is loaded in MWorks. This doesn’t seem to be experiment specific, as I tried to load different xml programs and they all made the DAC0 to have a 5V output. I’m also not seeing this on all of our rigs. All the Macs are having the same LabJack6 Plugin code. Do you have any idea why there’s this 5V output on some of the rigs?
Thank you so much!
Shuyang
Hi Shuyang,
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?
Cheers,
Chris
Hi Chris,
Okay I’ll double-check if the code is up to date, thanks for your opinions!
Best,
Shuyang
Hi Lindsey,
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:
$ ./u6BasicConfigU6
Results of ConfigU6:
FirmwareVersion = 1.35
BootloaderVersion = 6.15
HardwareVersion = 2.00
SerialNumber = 360008405
ProductID = 6
LocalID = 1
VersionInfo = 12
DeviceName = U6-Pro
Maybe try running this on your setups and see if there’s any correlation between firmware version and presence of the DAC0 issue?
In any case, it’d probably be good to contact LabJack about this, as it’s possible they’ve heard from other users about this issue.
Cheers,
Chris
Attachment: u6BasicConfigU6.zip (60.1 KB)
Hi Chris,
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:
BootloaderVersion = 6.15
HardwareVersion = 2.00
ProductID = 6
LocalID = 1
VersionInfo = 4
DeviceName = U6
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.
Lindsey.
Hi Chris,
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.”
Let me know if you have any thoughts…
Lindsey.
Attachment: Labjack.zip (359 KB)
OK, thanks for the update.
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.
Chris
Hi Chris,
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.
Lindsey.
Hi Lindsey,
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?
Chris
Hi Chris,
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
suggestions.
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?
Lindsey.
Hi Chris,
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?
Thanks,
Lindsey.
Hi Lindsey,
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.
Thanks,
Chris
Hi Lindsey,
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.
Thanks,
Chris
Hi Chris,
Just wanted to check and see if you’ve had time to test DAC0 on your
Labjack.
Thanks,
Lindsey.
Hi Lindsey,
Just wanted to check and see if you’ve had time to test DAC0 on your Labjack.
I did. I also believe I resolved the issue. I wrote to you about this on Monday. I guess you didn’t receive my reply?
If you could test the plugin build I sent you and see if it fixes the issue for you, too, that’d be great!
Thanks,
Chris
I had missed the email- we’ll try this right away!
Lindsey.
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)?
Lindsey