Laser interface

Hi Yasmine,

The interface to your laser device is now in the MWorks nightly build. I’ve attached an example experiment that shows how to configure and use it.

Since I don’t have the actual hardware on hand, my testing has been limited. I did program an Arduino board to respond to commands like the laser should, so I can at least confirm that the I/O is happening as the QCUALOR manual says it should. However, it’s always possible that there will be issues that I couldn’t anticipate.

If you run into any issues or have any suggestions for improvements, please let me know.

Cheers,
Chris

Attachment: qcualor_demo.mwel.zip (1.33 KB)

Hi Chris -

Thank you! We’ll start testing the laser functionality ASAP

Best,
Yasmine

Hi Yasmine,

(1) How do we program the laser to drive 1 of the 4 channels? We don’t see channel number as an option, only modes.

mode_1 sets the mode for channel 1, mode_2 for channel 2, etc. If you don’t want to use a channel, set its mode to off (or just omit the corresponding mode parameter from the device definition).

(2) Do we need to send a digital TTL to the laser to enable activation?

Yes. From the QCUALOR user manual, I see that the back panel has a BNC connector labeled “Modulation Enable Gate” (i.e. MEG). In order for the laser to recognize configuration commands and activate, the TTL signal connected to that input must be set high.

In your MWorks experiment, if you

  1. set the meg_state parameter of the qcualor device to the name of the variable,
  2. use that same variable as the value parameter of a DATAPixx bit output channel, and
  3. connect the digital line associated with the output channel to the laser’s MEG input BNC,

then MWorks will set the MEG input high and low at the appropriate times.

If you don’t want MWorks to do this, then omit the meg_state parameter. In this case, your experiment will have to set the MEG input explicitly.

In our VPixx configuration file, we currently set dout 21 for use with the laser. We are assuming that this is what the “meg_state” variable controls.

If dout 21 is physically connected to the laser’s MEG input, and you’ve arranged things as described above, then you are correct.

(3) Could you please give us an example of the syntax we need to make the laser deliver the following stimulation:

  • Channel 1
  • Blue laser
  • Sinusoidal
  • Frequency 100
  • Amplitude X
  • Duration Y

In my notes from our meeting with Karim, I have that channels 1 and 3 are red, 2 and 4 are blue. I don’t see this mentioned in the user manual, though, so I can’t confirm.

Anyway, assuming you want channel 1, here’s an example that configures the laser as you described and runs it for one second:

var amplitude = 0.1  // Between 0 and 1, subject to max_gain
var meg_state = false

iodevice/qcualor laser (
    mode_1 = 'sinusoidal'
    modulation_frequency = 100
    gain_1 = amplitude
    meg_state = meg_state
    )

protocol {
    start_io_device (laser)
    wait (1s)
    stop_io_device (laser)
}

If meg_state is used as discussed above, then start_io_device will turn the laser on, and stop_io_device will turn it off. (Stopping the experiment will also turn it off.)

(4) Is there an easy way for us to test the USB serial signals coming from MWorks (in case our laser is not configured correctly)?

I don’t understand how testing the signals coming from MWorks would tell you if your laser is configured correctly. Can you elaborate?

Cheers,
Chris

Hi Yasmine,

In my notes from our meeting with Karim, I have that channels 1 and 3 are red, 2 and 4 are blue.

It occurs to me that maybe you meant you want blue light on optical output 1. Per the user manual, optical output 1 is the combination of laser channels 1 and 2. If you want just the blue laser on output 1, then replace mode_1 and gain_1 in the example with mode_2 and gain_2, i.e.

iodevice/qcualor laser (
    mode_2 = 'sinusoidal'
    modulation_frequency = 100
    gain_2 = amplitude
    meg_state = meg_state
    )

Cheers,
Chris

Thanks Chris. We are looking into your email today and testing the plugin
again.
More soon,
Yasmine

Hi Chris,

Thank you for your advice!
We have incorporated your suggestions in the MWORKS experiment but the
laser does not turn on.
I am attaching here
https://drive.google.com/drive/folders/1ByYYnClhsvP4oXJ4WmRoql0LVPmEKu1M?usp=sharing:
(1) the MWORKS experiment we are running and (2) the console error.

There is currently a BNC cable connecting the VPIXX digital output (pin 21)
to the laser’s MEG.

  • An additional test we did was to connect the VPIXX digital output (pin
  1. to an oscilloscope and run the MWORKS experiment to check if VPIXX is
    sending any voltage. However, we did not observe any signal in the
    oscilloscope.

Could it be that the communication between MWORKS and VPIXX is not working?
(Is there a way for us to test this?) Or are we missing anything in the
code?

Best,
Margaret

Hi Margaret,

There are a couple issues in your experiment:

  1. The value parameter of the datapixx_bit_output channel and the meg_state parameter of the qcualor device must be set to the same variable name.
  2. You never start the datapixx device (which explains why you saw nothing on the oscilloscope).

I’ve attached a new version that corrects these problems.

The error messages saying “QCUALOR device did not respond to configuration command” indicate that the laser either didn’t receive or didn’t accept the commands sent from MWorks. A couple things to check:

  1. Are you certain the laser and the Mac running MWServer are connected via a USB cable?
  2. Are you sure there aren’t other serial devices connected to the Mac, and that the serial port you specified (/dev/cu.usbserial-AR0JVL1T) doesn’t belong to one of those? For example, an Arduino board would also present itself as a serial device.

If the answer to those questions is yes, then I don’t know what the problem is. MWorks is following the communication protocol provided by Karim, so we’ll probably need to bring him in to the loop to figure out why it isn’t working.

Chris

Attachment: qcualor_demo_v2.mwel.zip (2.16 KB)

Thanks Chris. Margaret and Jack are re-testing the laser right now. We’ll
report back soon.
Yasmine

Hi Chris,

Sorry about the last code—I think we did change the variable meg_state out
for vpixx_dout_laser_gate during our testing, but we must have accidentally
sent the wrong file for you to review.

Starting the datapixx device was missing, however, so I just ran a test
and I do find that I can activate the laser by manually setting
vpixx_dout_laser_gate=1 at the beginning of the protocol. Unfortunately,
this does *not *solve our configuration error, and I also find that if I
change gain_1 to gain_2/3/4, the laser doesn’t activate at all (so we’re
only able to turn on laser 1). Oddly enough, the LED on the front panel of
the laser would seem to indicate that the laser is active, even with
gain_2-4, but the laser itself isn’t actually on.

Finally, the USB cable definitely connects the Mac to the laser, and I’m
fairly certain that the serial port (/dev/cu.usbserial-AR0JVL1T) is
correct, because when I disconnect the cable on the laser’s side, that usb
device no longer appears when I search for it in the command terminal.
Also, when we disconnect the USB port from the laser and try to run the
protocol, we receive a different error:

ERROR: Requested path (/dev/cu.usbserial-AR0JVL1T) does not exist or is not
a serial device
ERROR: Can’t start iodevice (laser) and no alt tag specified
Extended information:
parser_context: mw_finalize

So it seems to me like the USB connection is functional and correct, but
something with the communication itself isn’t working. Does this sound
right to you? If so, I agree that it might be useful to set up a meeting
with Kareem later this week to figure this out.

Thank you!

Jack

Hi Jack,

I do find that I can activate the laser by manually setting vpixx_dout_laser_gate=1 at the beginning of the protocol

OK, that’s good to know. Is it possible to tell if the parameters set in your MWorks experiment (mode, frequency, gain) are affecting the operation of the laser? If they are, then we would know that the laser is receiving and accepting the configuration commands, even if it isn’t sending a response.

I also find that if I change gain_1 to gain_2/3/4, the laser doesn’t activate at all (so we’re only able to turn on laser 1).

This is expected. When starting the laser, MWorks sends a configuration command for every channel (even ones that are off), in order. If it fails to receive a response to the command configuring channel 1, it will abort the process and never send the commands configuring the other channels.

Oddly enough, the LED on the front panel of the laser would seem to indicate that the laser is active, even with gain_2-4, but the laser itself isn’t actually on.

That may just indicate that the MEG signal is high. A more convincing confirmation that a given channel is actually on would be to connect the corresponding “Channel X Light Sensor” BNC output to an oscilloscope and check if the signal changes when the laser is started (which may be what you’re already doing).

So it seems to me like the USB connection is functional and correct, but something with the communication itself isn’t working. Does this sound right to you?

Yes, I think we’ve confirmed this now.

As for the source of the problem, my first thought is that maybe my information is incorrect, and the laser does not echo back the serial commands. I can send an email to Karim asking for confirmation of that, but I’ll wait until after our meeting this morning, in case we have other questions.

Chris