06-03-2024 02:26 PM
Hello,
I want to trigger 3 devices using USB 6212. The system is an imaging system for small droplets, so the Camera and light must have a finite delay ( a user value). Are there any examples of triggering systems? Also, all the terminals used can be PFI or need to be analog for TTL waves for triggering.
I am sorry for the language.
06-03-2024 03:50 PM - edited 06-03-2024 03:51 PM
To rephrase, you want to generate 3 digital signals with precise timing relationship using 6212.
Now, to the specifics,
06-04-2024 01:30 PM - edited 06-04-2024 01:30 PM
Can you draw a timing diagram of these 3 signals? denote the range of expected values
What level of flexibility is required? on-the-fly and static?
I want to change the delay time on the fly and have a precise synchronous trigger for both.
Importance of missing the accuracy of timing relationship between the signals
The accuracy of timing relationships between signals is crucial in an imaging system for droplets to reproduce the data correctly. And Precise timing allows the system to capture images at the exact moment of droplet ejection, which is necessary for accurate analysis.
I hope to answer all your questions to the best of my knowledge.
06-11-2024 09:54 AM
The info you've given so far is still incomplete.
- you say you only need 2 signals, but your timing diagram shows 3
- you say the camera and light can use the same signal, but you show 2 distinct timing signals on the diagram
- you say camera + light should both be around 55 Hz, but you show 7 light trigger pulses per camera pulse
- you mention a 10-50us delay, but haven't clearly identified the 2 endpoints that define that delay
- you reference an "AFG trigger" at 1 kHz in your text, but don't show it in the timing diagram. The timing diagram shows a "jetting trigger", but that's the same freq as the light trigger which was previoiusly stated to be ~55 Hz.
Please be *very* specific about all the timing relationships. It's important to know which signals you need your app to capture or react to and which ones you need to generate. It's important to know which timing relationships are from an edge of one signal to the edge of another, and which are a measure of time spent in a specific digital state. And polarity will matter in both cases (your previous pic suggests but doesn't fully *define* a delay from jet trigger rising edge to light trigger rising edge and a high time duration for a camera pulse).
-Kevin P
06-18-2024 02:19 PM
I apologize for the confusion caused by the incorrect picture upload. Here are the clarifications:
Number of Signals: The correct setup requires only 2 signals.
Camera and Light Signals: The camera and light can indeed use the same signal. The diagram incorrectly showed two distinct signals.
Frequency Discrepancy: Both the camera and light should operate around 55 Hz. The 7 light trigger pulses per camera pulse shown in the diagram were incorrect and used just as an example.
Delay Specification: The 10-50µs delay should be clearly identified between the AFG and the camera/light trigger. This wasn't shown correctly.
AFG Trigger: The 1 kHz "AFG trigger" mentioned should have been included in the diagram. The "jetting trigger" shown at the same frequency as the light trigger (approximately 55 Hz) was a mistake.
06-19-2024 02:50 PM
Hard to help much more yet. A rough summary of the latest post reads to me something like this:
"Yep, many of the details I posted before were incorrect. Now how do I solve my problem?"
And all I can answer back is that I'd first need to see a clear, complete, and correct rendition of the details I've asked about. Which signals are inputs and which are outputs (relative to your 6212)? What timing relationships do you need to support or control? When do you only care about the timing placement of a rising or falling edge and when do you need to care about the duration a signal retains a given digital state? *Those* kinds of things...
-Kevin P
06-19-2024 06:14 PM
Hello Kevin,
I apologize for any confusion earlier. I've added the timing diagram below to help clarify the situation.
I am working on syncing an imaging system (camera and light) with a jetting system (AFG and jetting head). This involves having two trigger outputs from the 6212 device, each going to one of the systems.
The goal is to capture images of jetted droplets in flight. To achieve this, I need to vary the delay between the two triggers within the range of 10-55 microseconds. Additionally, the trigger signals for both the jetting head and the imaging system need to be synchronized at the end of each trigger cycle. This means that the frequency of the jetting head should be a multiple of the imaging system's trigger frequency (55Hz * 18 = 990Hz). By doing so, both systems will reset to the starting point at the end of each cycle, allowing for consistent imaging of the droplets at the same positions.
I hope this explanation clears up any confusion. Please let me know if you need further details or have any questions.
06-20-2024 10:47 AM
I can't generate a complete solution, but here's an outline and some caveats.
Outline:
1. Start with the LV2020 code I attached, a very slightly modification of a shipping example. Make 2 copies, one each for your jetting trigger signal and your camera trigger signal.
Note that I added the all-important (but oft-neglected in NI's examples) "initial delay" parameter. This is how you'll adjust the 10-55 usec offset you want, by making the initial delay for the camera to be 10-55 usec larger than that for the jetting trigger.
2. Note that the modified example always wants a digital start trigger. You're going to need to generate that with a very simple software-timed DO task, after working out the appropriate PFI terminals & wiring (if necessary. Often you can toggle a DO line that has a dual PFI designation which the counter tasks can react to, with no need for any physical wiring).
Note also that to make this work correctly, you need to start your counter tasks first before you run your DO task that toggles the PFI line in question.
3. You're going to set your pulse specs so that the the camera pulse period is *exactly* 18x the jetting pulse period. Based on your diagram, you'll want similar high times and very different low times.
4. To accomplish the 18x factor *exactly*, I would highly advise you start thinking like a counter and work out your pulse spec math in units of Ticks using only *integers*. You're going to find that because the counter logic circuitry can only divide down its internal 80 MHz clock by integer divisors, you *cannot* create 990 Hz *exactly* because that would have required a non-integer divisor. You'll be stuck with a nearby integer divisor instead. Whatever that turns out to be, you can then be sure that the integers you use for your ~55 Hz pulse will make the period an *exact* 18x multiple.
-Kevin P
06-20-2024 03:50 PM
Hello Kevin,
I have tried your suggestions and made a code. I have attached the codes here with. I have some confusions after this.
You're going to need to generate that with a very simple software-timed DO task, after working out the appropriate PFI terminals & wiring (if necessary. Often you can toggle a DO line that has a dual PFI designation which the counter tasks can react to, with no need for any physical wiring).Note also that to make this work correctly, you need to start your counter tasks first before you run your DO task that toggles the PFI line in question.
Terminal Assignments:
Distinct Terminals:
06-21-2024 06:52 AM
I see you're making decent progress. Don't forget to revisit the code to take care of that integer stuff I outlined, it's going to make a difference for some combos of pulse parameters. It may be small and subtle, but sometimes it's important to be exact rather than merely really close. However, I'm also on board with the idea of focusing elsewhere first, getting the main idea working before worrying about the subtleties.
Responses inline in red:
Terminal Assignments:
- Do the counter and digital output terminals need to be the same? My understanding is they should be different.
Each of the 2 counter outputs and the digital output serve different purposes so yes, they should all be distinct from one another.
- For the digital output terminal, should I be using AI (Analog Input) terminals? Currently, I only see AI terminals as options, which seems incorrect for a digital output task.
No, you should be using digital channel designations, similar to "Dev1/port1/line2". You need to right-click the DAQmx channel constant and choose "I/O Name Filtering" from the popup menu. There you can designate that only Digital Output channel names should be shown. In the future, if you *first* choose the Digital Output version of "DAQmx Create Virtual Channel", then when you right click the vi terminal to create a channel constant or control, it'll create one with filtering already set to show Digital Output channel names.
(This is just one of those learning curve things that one gets used to after a while. It isn't particularly obvious or intuitive before you know.)
Distinct Terminals:
- Should the counter terminal, digital trigger source terminal, and digital output terminal all be different?
The counter output terminals need to be different. The counter tasks' trigger source terminal and the digital output terminal can refer to the same hardware terminal, but need to refer to it by different names. Signals used for timing clocks and triggers get referenced similarly to "/Dev1/PFI2" while digital output terminals are referenced more like "Dev1/port1/line2". If you look up the pinout for your USB-6212, you'll see that those are just two different ways to reference the same physical pin on the terminal block. So you can generate your software timed digital pulse on a digital line that the counter task can treat as a PFI line for its trigger. Then there's no physical wiring to do.
-Kevin P