voltage from port DAC0

Shuyang Jin's Avatar

Shuyang Jin

12 Aug, 2021 05:51 PM

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

  1. Support Staff 1 Posted by Christopher Sta... on 13 Aug, 2021 12:43 PM

    Christopher Stawarz's Avatar

    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

  2. 2 Posted by Shuyang Jin on 13 Aug, 2021 02:59 PM

    Shuyang Jin's Avatar

    Hi Chris,

    Okay I’ll double-check if the code is up to date, thanks for your opinions!

    Best,
    Shuyang

  3. Support Staff 3 Posted by Christopher Sta... on 13 Sep, 2021 02:32 PM

    Christopher Stawarz's Avatar

    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

  4. 4 Posted by llglick on 16 Sep, 2021 08:35 PM

    llglick's Avatar

    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.

  5. 5 Posted by llglick on 17 Sep, 2021 10:05 PM

    llglick's Avatar

    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.

  6. Support Staff 6 Posted by Christopher Sta... on 20 Sep, 2021 12:58 PM

    Christopher Stawarz's Avatar

    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

  7. 7 Posted by llglick on 20 Sep, 2021 01:26 PM

    llglick's Avatar

    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.

  8. Support Staff 8 Posted by Christopher Sta... on 21 Sep, 2021 01:10 PM

    Christopher Stawarz's Avatar

    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

  9. 9 Posted by llglick on 22 Sep, 2021 02:44 PM

    llglick's Avatar

    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.

  10. 10 Posted by llglick on 22 Sep, 2021 08:36 PM

    llglick's Avatar

    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.

  11. Support Staff 11 Posted by Christopher Sta... on 22 Sep, 2021 09:40 PM

    Christopher Stawarz's Avatar

    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

  12. Support Staff 12 Posted by Christopher Sta... on 27 Sep, 2021 09:29 PM

    Christopher Stawarz's Avatar

    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

  13. 13 Posted by llglick on 01 Oct, 2021 06:23 PM

    llglick's Avatar

    Hi Chris,
    Just wanted to check and see if you've had time to test DAC0 on your
    Labjack.
    Thanks,
    Lindsey.

  14. Support Staff 14 Posted by Christopher Sta... on 01 Oct, 2021 06:28 PM

    Christopher Stawarz's Avatar

    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

  15. 15 Posted by llglick on 01 Oct, 2021 06:30 PM

    llglick's Avatar

    I had missed the email- we'll try this right away!
    Lindsey.

  16. 16 Posted by llglick on 01 Oct, 2021 06:31 PM

    llglick's Avatar

    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

  17. Support Staff 17 Posted by Christopher Sta... on 01 Oct, 2021 06:36 PM

    Christopher Stawarz's Avatar

    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

  18. 18 Posted by llglick on 01 Oct, 2021 07:07 PM

    llglick's Avatar

    Hi Chris,
    The new plugin doesn't work- I get the "no factory for object type" error.
    Lindsey.

  19. Support Staff 19 Posted by Christopher Sta... on 01 Oct, 2021 07:30 PM

    Christopher Stawarz's Avatar

    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

  20. 20 Posted by llglick on 01 Oct, 2021 07:33 PM

    llglick's Avatar

    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.

  21. Support Staff 21 Posted by Christopher Sta... on 01 Oct, 2021 07:39 PM

    Christopher Stawarz's Avatar

    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

  22. 22 Posted by llglick on 01 Oct, 2021 08:09 PM

    llglick's Avatar

    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.

  23. Support Staff 23 Posted by Christopher Sta... on 01 Oct, 2021 08:22 PM

    Christopher Stawarz's Avatar

    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

  24. 24 Posted by llglick on 01 Oct, 2021 08:34 PM

    llglick's Avatar

    Yes- that's the correct experiment. And this variable set should set DAC0
    high when the stimulus goes on.
    Thanks,
    Lindsey.

  25. Support Staff 25 Posted by Christopher Sta... on 04 Oct, 2021 03:46 PM

    Christopher Stawarz's Avatar

    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

  26. 26 Posted by llglick on 04 Oct, 2021 03:55 PM

    llglick's Avatar

    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.

  27. Support Staff 27 Posted by Christopher Sta... on 04 Oct, 2021 03:56 PM

    Christopher Stawarz's Avatar

    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

  28. 28 Posted by llglick on 04 Oct, 2021 03:58 PM

    llglick's Avatar

    Yes- that's correct. Reverting to the previous build of the plugin didn't
    enable DAC0 output.

  29. Support Staff 29 Posted by Christopher Sta... on 04 Oct, 2021 04:06 PM

    Christopher Stawarz's Avatar

    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

  30. 30 Posted by llglick on 04 Oct, 2021 04:17 PM

    llglick's Avatar

    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?

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:

»

Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac

Recent Discussions

17 May, 2022 02:12 PM
16 May, 2022 03:12 PM
04 May, 2022 06:02 PM
03 May, 2022 01:30 PM
02 May, 2022 10:47 PM