From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Creating a steady PWM of 100 KHz using NI-9402 and cDAQ-9178

Solved!
Go to solution

Hello Kevin,

Thanks for the suggestions!

 

I made the modifications but can't try it right now. I will try this afternoon or more possibly tomorrow. I'll give feedback if this works or no.

 

One the other hand, I don't understand how using a DI can works without reading/writing, and knowing I'll not use any physical wires nor can I use any available input (since the 2 nibble are output for the counter).

 

I understand I shall use the cDAQ1/di/StartTrigger but there will never be any 5v in any input, right?

 

Regards,

Clément 

 

 

0 Kudos
Message 21 of 26
(819 Views)

Yeah, maybe the DI idea isn't so helpful for your particular situation where your devices has restrictions about subdividing into a mix of outputs and inputs.  Sticking with DO and all outputs may well be simpler overall for your hw configuration.

 

But the basic idea for any of it is that the DO (or DI) task is used purely for its *internal* StartTrigger signal.  No external signals ever matter.  The mere act of starting the task will assert the internal StartTrigger signal which in turn starts your counters in sync.  As soon as you've done this, the job of the DO (or DI) task is done.  You can then stop it immediately.

   DO requires you to define data for its buffer or else you get a task error, the Start doesn't succeed, and the internal StartTrigger signal isn't asserted.  With a DI task, you couldn't Read until after you've Started, at which point you've already triggered the counter tasks so there's simply no need to Read.  Just Stop.   That's the idea.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 22 of 26
(813 Views)

Sorry I had been awfully busy at work. Didn't have much time to try your proposition.

So I finally had a bit of time and tried it, and it seems to work perfectly.

I encounter some "201133 error" when I start the program in with debug option. https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P6TtSAK

 

Is this normal ?


I added an option to stop and restart the PWM anytime you want.

I drop the snippet and VI if that can help someone later.


2 Pwm kevin's FYI.png

0 Kudos
Message 23 of 26
(783 Views)

The -201133 error seems to be pretty specific to your particular cDAQ device, and isn't something I have prior knowledge about.  Generally though I'd say that no, if it isn't *always* an error, it shouldn't have to *ever* be one.  There's probably a way to fix this with better enforcement of the desired DAQmx call sequence.

 

What you show in the code generally looks like it follows the advice in the article you link.  The only thing I see to comment on is that the call to DAQmx Write for the digital task leaves the "auto-start" input unwired.  If the default value is True, it's possible for there to be a race between when the digital task auto-starts and when the counter tasks do their "reserve" action.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 24 of 26
(778 Views)

The DAQmx write auto start is at false if left unwired. I still put a false bool and it changed nothing.

The "error" happen when I quit the VI by force without stoping it. This case, I never encounter the "delete task" and the task stay in the cDAQ maybe? This way, when I start the VI again later, and when I start the task again, I have a problem 201133 ?
The strange thing is when I quit the VI, I don't have any pulse on the oscilloscope.

When the error show, If I click on "continue" several time, the program work well later. And If I stop him in the good way with the "delete task" included, I can start the VI everytime without any 201133 error.

Hope that can help understand the error a bit more.

 

Nevermind, your solution with only 1 frame works, I can use all 4 PWM synchronized. I plan to use 2 Ni-9401, one for external triggering instruments for a later acquisition and one for pulsing on transistors.

 

Wish you a nice day,
Clément.

 

 

 

 

0 Kudos
Message 25 of 26
(765 Views)

Ah!  If you only get the error after a forced stop, then I guess the solution is not to do forced stops.  Give yourself a cleaner way to exit your loops.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 26 of 26
(759 Views)