Galvanometer control and data acquisition with DAQ Card

[cbarnera@ub.edu]

Hello GerdW,

Thank you for answering and sorry to reply that late. 

I am trying to do all you are saying but I would like to also have the option to continously be scanning and I don't know if I am able to do it with a For Loop intead of the While Loop that I had. Could I?

And last, what do you mean by FP elements?

Thank you for the tips.

Carla

[GerdW]

Hi Carla,

---

cbarnera@ub.edu wrote:

And last, what do you mean by FP elements?

---

• "FP" = front panel, "BD" = block diagram
• FP elements is anything you place on the frontpanel: controls, indicators, decorations, splitter bars, …

You can hide the label of FP elements on the front panel, but you should never do that in the block diagram!

[cbarnera@ub.edu]

Hey everyone,

I'm writing here because I'm having trouble solving a problem, even though I previously sought help in another situation.

I'm new to programming in LabVIEW and need to create a program that synchronizes the galvanometer mirrors used for scanning with the photodetector that needs to acquire the image. I'll explain my requirements first and then describe what I've tried and the issues I'm facing.

I have two galvanometric mirrors: one scans along the X-axis, and the other scans along the Y-axis. While scanning, a photodetector needs to capture photons at each scanning point, requiring precise synchronization. To control this setup, I'm using a DAQ unit, the NI USB-6001, connected to a computer running a LabVIEW program.

I've created a program that acquires an image and is nearly synchronized with the photodetector. However, it's not perfectly synchronized, especially at low dwell times. I suspect the issue arises because the time it takes for the scanning mirror to return to the starting point of the next line differs from the regular scanning intervals, and I'm not accounting for this.

I'm considering separating the scan into individual lines and inserting a wait time between each line, but I'm unsure how to implement this.

Does anyone have any ideas on how to solve this or start from scratch?

Attached is my LabVIEW program.

Thank you,

Carla

[cbarnera@ub.edu]

Hello NI Community,

I am working on a project where we have to buil a two-photon microscope and two galvanometer mirrors are used to do the scan of the sample. The image is going to be acquired by a photodetector (APD, thorlabs), which has to be synchronized with the galvanometer to acquire an image at each step to reconstruct the image. To sinchronize this acquisition, we want to use a signal from galvos (position output from a servodriver). The signal ranges from +5V to -5V per each line scan, with 10 discrete steps. This process repeats for 10 lines, creating a 10x10 scan grid with the galvos.

Our goal is to use the rising edge after each line as a start trigger for data acquisition, specifically to synchronize the scanning signal with the acquisition of data from a photodetector. We want to start acquisition at the beginning of each new line, triggered by the rising edge of the signal.

I've attached the file of our LabVIEW block diagram for reference.

Despite configuring the DAQmx Start Trigger VI with the source set to USB-6001/ai1, we keep encountering Error 200077, which indicates an invalid or unavailable source.

Questions:

1. Is this the way of using this signal as a start triggering edge?
2. Is there a specific configuration required for the USB-6001 to support analog edge triggers?
3. Are there any known limitations with the USB-6001 regarding analog triggers?
4. Could there be an issue with the signal itself that prevents it from being used as a trigger?
5. Are there any best practices or alternative methods for achieving the desired triggering and synchronization with the photodetector acquisition in this setup?

Any insights or suggestions would be greatly appreciated. We are eager to get this setup working correctly to proceed with our scanning and photodetector synchronization application.

Thank you in advance for your help!

Best regards,

Carla

[mcduff]

The USB-6001 does NOT support analog triggering. However, I believe it supports digital triggering on its PFI inputs. Can your galvanometer mirrors output a TTL signal? If so that can be used as a digital trigger with your setup.

[santo_13]

As per the 6001 specification, the trigger for an Analog Input can be only digital through PFI0 or PFI1. It does not support an Analog-Level trigger.

You can add external circuit to condition this +/-5V signal into a 0-5V digital edge and thereby working with 6001 through PFI0/1.

Use an optocoupler to digitize this +/-5V signal into a 0-5V digital edge.

[cbarnera@ub.edu]

Yes, it returns a Ready Output, however it gives a signal when the scan starts. But when each line starts the signal is super low and it doesn't detect it. 

[Kevin_Price]

Ok, I'll be the bad guy.

I see that you've been trying to integrate your equipment since April.   GerdW told you then, and I'll repeat it now: the USB-6001 is the wrong DAQ device for a job like this.  I understand the initial impulse to try to make things work with the device you have in hand, but after 3 months it's really time to tackle this with more suitable hardware.

I've been in a number of threads about galvo and APD work, mainly related to synchronization techniques, though I've never worked with any such equipment myself.  Most often, folks generate their own analog signals to control the galvo while capturing one or more AI signals and sometimes also things like photon pulse counts.  But it sounds like you're relying on an external servo to control the galvo and you want to sync your AI task to the operation of that servo.   

I'm laying all this out because it's important to have a solid definition of your requirements to help guide a choice of DAQ device.  In the NI world, what comes first to mind is either an X-series multifunction device or a cDAQ chassis fitted with suitable I/O modules.

Some questions:

1. Do you prefer or need to control the galvo with the external servo?  Or would you rather have the flexibility of generating your own scan pattern with analog output signals and just weren't quite ready for that step yet?   Sync can often become much more straightforward and reliable when *you* have control over *all* the signals.

2. How will this system be deployed?  My bias is towards desktop systems and PCIe cards for higher performance where feasible, but a cDAQ system on USB or Ethernet could also work for the things you've described so far.   

3. Will this equipment be fully dedicated to this job or does it also need to be able to do a variety of other things?  Can you define them?   If you have to share the PC and/or DAQ system with other tasks, you'll want to consider how to cleanly break and re-make your connections.

    Examples: with a PCIe X-series card in a desktop PC, test station wiring would go to something like an SCB-68 connector block and remain dedicated to the test station.  One NI cable connects that to the X-series card for easy connect/disconnect.

    With a cDAQ system, test station wiring would go to 1 or more cDAQ modules.  The modules would remain dedicated to the test system, the PC would be free to move about.  The cDAQ chassis could either stay or go, depending on your needs.  Either way, there's a simple enough connect / disconnect procedure available.  Just keep track of which slots your different cDAQ modules go into.

-Kevin P

[cbarnera@ub.edu]

Hello Kevin,

Fist of all thank you for your reply. 

Here is the thing, there are sometimes that is hard to be able to reach all the instruments need it, and this is why we where first trying to do how was in our hand with the equipment that we have. Moreover, I am super new here and it is my first time using all this. All this said, it is super cool that you made the answer that clear, thank you, and I am going to try to answer all the questions for you the best as I can:

1. Do you prefer or need to control the galvo with the external servo?  Or would you rather have the flexibility of generating your own scan pattern with analog output signals and just weren't quite ready for that step yet?   Sync can often become much more straightforward and reliable when *you* have control over *all* the signals.

What I am doing now is generating my own signal with labview, which is a raster point by point, and sending it to the galvos via the DAQ unit. However, this could change if there is a better way of doing it.

2. How will this system be deployed?  My bias is towards desktop systems and PCIe cards for higher performance where feasible, but a cDAQ system on USB or Ethernet could also work for the things you've described so far.  

I am using my laptop to run everything and USB would be the best way for me to work with. However, as we might have to change the DAQ unit (USB-6001) we could try with something else.

3. Will this equipment be fully dedicated to this job or does it also need to be able to do a variety of other things?  Can you define them?   If you have to share the PC and/or DAQ system with other tasks, you'll want to consider how to cleanly break and re-make your connections.

The equipment is going to be fully dedicated to this job, which will consist in synchronize the galvos with the APD, and in the future also control a PIFOC. 

I hope I answer what you answer and if not I will try my best again.

However, with all this said, I was trying now to fins a digital output from the galvos and use this USB-6001, because I think it should work like mcduff said. What do you think (knowing that the DAQ unit might not be the best option for this work)?

Thank you fr your time,

Carla

[NIquist]

You don't need to worry about hardware triggers when you are only scanning a 10 x 10 point grid.  Unless you have very tight physical time constraints, your program should do a simple sequence of:

1. Move to new position.

2. Wait for settling time.  (You could technically monitor for your POSITION ERROR or VELOCITY signal to reach zero, but a sufficient delay is much easier.)

3. Collect signal from photodetector.

4. Store data.

5. Repeat until end of grid...

If you need help with your code, back-save (Save for Previous Version...) to 2018 so we can open it.