# Laser interface

**URL:** <https://mworks.discourse.group/t/laser-interface/758>\
**Category:** Support\
**Created:** [May 12, 2022, 3:14pm UTC](https://mworks.discourse.group/t/laser-interface/758 "2022-05-12T15:14:12Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [May 12, 2022, 3:14pm UTC](https://mworks.discourse.group/t/laser-interface/758/1 "2022-05-12T15:14:12Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [May 12, 2022, 3:14pm UTC](https://mworks.discourse.group/t/laser-interface/758/2 "2022-05-12T15:14:12Z")

</div>

Attachment: [qcualor\_demo.mwel.zip](https://mworks.discourse.group/uploads/short-url/38LrrKGEXZ70BvUEGwDTzxqGDjY.zip) (1.33 KB)

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [May 12, 2022, 3:50pm UTC](https://mworks.discourse.group/t/laser-interface/758/3 "2022-05-12T15:50:36Z")

</div>

Hi Chris -

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

Best,  
Yasmine

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [June 14, 2022, 2:46pm UTC](https://mworks.discourse.group/t/laser-interface/758/4 "2022-06-14T14:46:28Z")

</div>

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](https://mworks.github.io/documentation/latest/components/datapixx_bit_output_channel.html), 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:

```auto
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

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [June 14, 2022, 3:19pm UTC](https://mworks.discourse.group/t/laser-interface/758/5 "2022-06-14T15:19:19Z")

</div>

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.

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

```

Cheers,  
Chris

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [June 14, 2022, 3:21pm UTC](https://mworks.discourse.group/t/laser-interface/758/6 "2022-06-14T15:21:39Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [June 14, 2022, 6:03pm UTC](https://mworks.discourse.group/t/laser-interface/758/7 "2022-06-14T18:03:06Z")

</div>

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](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

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [June 14, 2022, 7:35pm UTC](https://mworks.discourse.group/t/laser-interface/758/8 "2022-06-14T19:35:08Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [June 14, 2022, 7:35pm UTC](https://mworks.discourse.group/t/laser-interface/758/9 "2022-06-14T19:35:08Z")

</div>

Attachment: [qcualor\_demo\_v2.mwel.zip](https://mworks.discourse.group/uploads/short-url/1rlW455JHqcEAzqPtVhx5KKD7Ey.zip) (2.16 KB)

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [June 14, 2022, 8:48pm UTC](https://mworks.discourse.group/t/laser-interface/758/10 "2022-06-14T20:48:26Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [June 14, 2022, 10:14pm UTC](https://mworks.discourse.group/t/laser-interface/758/11 "2022-06-14T22:14:03Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [June 15, 2022, 1:05pm UTC](https://mworks.discourse.group/t/laser-interface/758/12 "2022-06-15T13:05:58Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [January 31, 2023, 3:17pm UTC](https://mworks.discourse.group/t/laser-interface/758/14 "2023-01-31T15:17:38Z")

</div>


