Hi Chris,
After some more troubleshooting, it seems like at least some of our issue
was a variable set one. When doEasyStart is 1, this sets tBlock2TrialNumber
to 0.
However, we’re still not in the clear. There is still a computer-specific
and/or plugin-specific issue:
On three computers, the plugin you had sent on 7/22 (to fix the
ehFeedbackError) and the more recent one (to fix the DAC0 high error) have
the expected DAC0 output using both our code and dac_cycle.mwel.
However, on another computer the plugin from 7/22 works fine, but the more
recent one does not: tBlock2TrialNumber goes high (and in dac_cycle it says
that it’s sending output) but nothing happens.
We tried swapping the labjacks between the two computers, but that didn’t
do anything.
All computers have the same version of Mworks, but the one in question had
a much older OS (it had High Sierra, while the other three had either
Mojave or Catalina). We updated the computer to Catalina, but that still
doesn’t have any DAC0 output with the latest plugin.
We also now have a different problem, where Mworks is using Display 1 as
the stimulus display, despite this being set for Display 2 in the
Preferences.
We’ve tried reinstalling Mworks, but that didn’t solve either issue.
Do you have any suggestions?
Thanks,
Lindsey.
Hi Chris,
To follow up on the display issue, we did try to use the configuration file
as described here:
https://mworks.tenderapp.com/discussions/questions/568-mwork-window-configuration
We created a system-level configuration file but noticed that it doesn’t
update when we make changes in the MWclient preferences window. We found
the user-level configuration file that does change appropriately when
changes are made in the preferences window. According to the documentation
the system level file should take precedence, but it doesn’t seem to be
that way. Another interesting thing we noticed is that this computer is the
only one with a user-level “Library” folder that contains Application
support > Mworks > Configuration. Could this be the issue?
Lindsey.
Hi Lindsey,
We created a system-level configuration file but noticed that it doesn’t update when we make changes in the MWclient preferences window. We found the user-level configuration file that does change appropriately when changes are made in the preferences window. According to the documentation the system level file should take precedence, but it doesn’t seem to be that way.
You’re correct that changes made in MWServer’s preferences window affect the user-level config file, not the system-level one. However, as noted in the manual, it’s the user file that takes precedence, not the system one. The system one will be used only if the user one doesn’t exist.
Another interesting thing we noticed is that this computer is the only one with a user-level “Library” folder that contains Application support > Mworks > Configuration. Could this be the issue?
The user-level config file should just contain the settings you see in MWServer’s preferences window. What do you see in MWServer → Preferences → Display → “Display stimuli on:”? On a system with two displays, the three possibilities should be “Mirror window only”, “Main display”, and “Display 2”. “Main display” is whichever display the macOS Dock is on. “Display 2” is the other one.
Chris
Hi Lindsey,
On three computers, the plugin you had sent on 7/22 (to fix the ehFeedbackError) and the more recent one (to fix the DAC0 high error) have the expected DAC0 output using both our code and dac_cycle.mwel. However, on another computer the plugin from 7/22 works fine, but the more recent one does not: tBlock2TrialNumber goes high (and in dac_cycle it says that it’s sending output) but nothing happens.
Just to be specific, when you say that dac_cycle.mwel says it’s sending output, are you seeing this message?
*** 10mW is received and 4.13953V is sent ***
If yes, then this must be another issue in LabJack’s code, as the reported voltage value (4.13953) is exactly what gets passed to the eDAC function.
To confirm this, I’ve attached a test program (called just “dac_cycle”) that does the same thing as dac_cycle.mwel but uses only LabJack code. When I run it, the LED attached to my U6 toggles on/off once per second, and I see the following output in Terminal:
$ ./dac_cycle
Setting DAC0 to 4.1 V (54291)
Setting DAC0 to 0 V (0)
Setting DAC0 to 4.1 V (54291)
Setting DAC0 to 0 V (0)
...
The program stops after 10 on/off iterations. Can you try this on your misbehaving system and let me know what happens?
Thanks,
Chris
Attachment: dac_cycle.zip (58.3 KB)
Hi Chris,
Yes, we do see those three options. Selection of either the Main Display or
Display 2 results in the display on the Main Display (the one with the
macOS Dock).
When these preferences are toggled, they are updated in the user-level file
(0 for Main, 1 for Display 2), but the display used does not change, and
nor does the system-level file.
Lindsey.
Hi Lindsey,
It sounds like the preferences are being set correctly. I have no idea why the main display is always being used. Have you tried rebooting the Mac?
Chris
Yes.
Hi Chris,
No- I had missed this email.
The console did report sending the output.
We will try this new test.
Thanks,
Lindsey.
Hi Chris,
I just tried this (I’m just executing the unix file, right?), but it doesn’t seem to find the labjack- here’s the terminal error:
hullglick6:~ hullglick$ /Users/hullglick/Downloads/dac_cycle ; exit;
Open error: could not find a U6 with a local ID or serial number of -1
Lindsey.
Hi Lindsey,
Despite the wording, that error message indicates that at least one U6 device was found, but it couldn’t be opened for some reason. Is MWServer open and running an experiment that uses the U6? If so, try quitting it, as it may be preventing dac_cycle from using the device.
Chris
Oops- yes, I had Mworks open.
I do see DAC0 output using that script.
Lindsey.
I do see DAC0 output using that script.
OK, so both the device and the LabJack code seem to work correctly.
But you don’t see DAC0 output when running dac_cycle.mwel in MWorks, correct? And this is despite the console message saying “10mW is received and 4.13953V is sent”? If so, it’s hard to see where things could be going wrong, as it sounds like both the MWorks plugin and the LabJack code it uses are working correctly.
I’m not sure what the next step is with this…
Chris
That is correct. I do not see DAC0 output using dac_cycle.mwel in Mworks-
though only if I use the most recent plugin where you fixed the DAC0-high
issue.
If I use the plugin you sent in July, I do see DAC0 output with dac_cycle.
So I do think it’s a plugin issue- though for some reason, it’s an issue
that is specific to this computer.
Lindsey.