My LED blink 3 times before entering while loop??

[dytbaat]

Hi all

I want to be able to simply PWM my LED. So I created this VI. But it blinks 3 times before entering the loop, and it's like no matter what I do it insists on running 3 times the freequency with the given duty cycle on the channel creat VI before it continues. What do I miss??

Thank you.

[Kevin_Price]

1. Define your initial pulse timing parameters by wiring values into your call to DAQmx Create Virtual Channel.vi

2. Don't ignore errors in your loop -- react to them.  (Simple ways: terminate the loop on error or call an error popup).

3. Don't try to write the same constant timing parameters to the task repeatedly in a loop as fast as your CPU can iterate.  If you want to (occasionally) change the timing, make GUI controls for freq and/or duty cycle, add an Event Structure to the loop, then only write your timing parameters to the task if one of them changes.

-Kevin P

[dytbaat]

1. I dont see initial pulse timing parameter inputs anywhere!

          I see duty cycle, frequenzy, name, unit, idle state and initial delay

          I can get it to initiate differently by changing duty cycle, freequenzy and initial delay, but not make it do nothing!

2. Yeah true, I dont have any errors at the moment, its working fine, except for the blinking!

3. Yeah I know 🙂 But this is about the startup. I'm trying to understand whats going on regarding the startup!

\\dytbaat

[Kevin_Price]

By timing parameters, I *meant* freq & duty cycle.  (Initial delay is also a timing parameter.)

Can you describe the things you've tried and what you observed in greater detail?   Please spend several minutes to make it thorough and clear -- right now there's too much I'd have to guess, assume, or ask detailed questions about. 

You should not be stuck with an inexplicable behavior like you described.  I've been dealing with NI's counters for a very (very very) long time, and unless your board is damaged in a really odd way, I suspect the root cause to be something you haven't yet mentioned (perhaps because you didn't consider it relevant).

What DAQ device are you using?  Are you running in highlight execution mode?  How else would you know whether the blinks happen before the loop or during it?  Do you have any DIO happening on the board at the same time (many boards share some of their pins between DIO and counter signals)? 

-Kevin P

[dytbaat]

Okay 🙂

Yeah sure, I'll try to explain..

Before the program enters the loop, my LED flashes three times. To begin with I just used the default parameters.

f = 1, DC = 0,5, ID = 0 As soon as I run the program my LED turns on for 0,50 second, then off 0,50 second, and repeats 3 times in total. And then it dims.

f = 2, DC = 0,5, ID = 0 As soon as I run the program my LED turns on for 0,25 second, then off 0,25 second, and repeats 3 times in total.  And then it dims.

The higher f, the faster blink, but always 3 times!

f = 1, DC = 0,1, ID = 0 As soon as I run the program my LED turns on for 0,1 second, then off 0,9 second, and repeats 3 times in total. And then it dims.

The lower DC, the shorter on time. But it cant be zero, only close to, or an error occur.

f = 10, DC = 0,01, ID = 0 As soon as I run the program my LED turns on for a very short time, still three times, then dims.

So I guess frequency and DC is working properly. What I dont get is why it has to execute three times before it goes into the loop.

With initial delay, say 1, it just postpone the execution. Same thing happends, just a secont later..

I am new to Labview, so yeah, it is probably something I miss. I have a myDAQ.

I dont see any other exlanation than it must have something to do with the channel creation. Because it dims after it flashes. And it can only be the counter F inside the loop that does that..

I have a breadboard with the LED mounted.

\\Peter

f = 1, DC = 001, ID = 0 As soon as I run the program my LED turns on for 0,25 second, then off 0,25 second, and repeats 3 times in total.  And then it dims.

[Kevin_Price]

Thanks for the info.  I'm starting to think a few things, but only as (partial?) explanation, not really a solution.  First, could you try the following 3 things?

1. Inside the loop, feed the iteration terminal 'i' to a numeric indicator.  Also, popup a 2-Button Dialog when there's an error so you can choose to either stop iterating or continue.  (See attachment below.)  Record which iteration #(s) result in an error, and what the error was.

2. Set a debug breakpoint on the loop border so the code can't enter the loop until you un-pause it.  Do you then see the LED keep blinking at the initial slow rate *more* than 3 times?   Basically, does it keep blinking until after you unpause the code?

3. Configure the initial freq & duty cycle to be the same that you set inside the loop.  Use 100 Hz or more for the freq though.   Do you *ever* see any blinks slow enough to be countable?

My expectations:

1. error on iteration 0.  After you transition from slow to fast blinks (too fast to see, your eyes just see a dimming), errors again on alternate iterations (either ...5,7,9,... or ...6,8,10,...)

2. slow blinks until you un-pause the code (with perhaps 1-3 more slow blinks just after un-pausing)

3. no slow blinks seen

I'm not at all familiar with the myDAQ device but am very familiar with DAQmx.  I tend to avoid USB DAQ devices when possible because there are inherent limitations to the USB bus and over the years I've occasionally learned of additional limitations for specific USB DAQ devices, especially some of the lower-cost ones.

You might have run into one (or more) of these unavoidable limitations.  Are you able to get direct support from NI?  I'd suggest you give that a try too.

-Kevin P

[dytbaat]

Hi

Thank you for taking your time to help 🙂

1. I have an indicator on i now, and I'm quite surpriced to see that, i starts to count before it dims. Actually the flashing follows the iterations, 0, 1, 2.... And then as it dims i runs fast!! So its like it's excetuting some kind of buffer that the create task has made!! I'm not sure about the two buttom dialog box, I havent any experience with that, and I have no errors. But it inspired me to start single stepping, and as soon I run the start task the LED starts blinking, and it keeps on forever till I run the Write function.

2. I'm not sure what a break point is, but I guess the single stepping feature kind of gave us the answer?

3. Yeah true, if I give the create function the same values as the write function you wont notice anything.. But as soon there's a difference its clear to see the change!

I'm starting to think that the problem overall can be caused by a bad architecture. As you mentioned earlier, this is a puling scheme, and I should only write when there is an event instead of constantly puling values!! But this is just a thought.. To me it seems like its not posible to create the channel without initializing some kind of counter. If I remove the start task, it just starts when it hits the write function as it has auto start as default. But still it insists on excecuting what I initiated in the create task. And the values cant be set to zero.. So do nothing is not a posibility!!

Okay, yeah Im not very familiar with the equipment. And I dont have experience with anything else. I use myDAQ as part of the course I run at the university I just resently took over.

Good question, maybe we have direct support.. I'll try to find out 🙂

 - Peter

[Kevin_Price]

First I'll address a few things from your last msg directly, in red.   

---

1. I have an indicator on i now, and I'm quite surpriced to see that, i starts to count before it dims. Actually the flashing follows the iterations, 0, 1, 2.... And then as it dims i runs fast!! So its like it's excetuting some kind of buffer that the create task has made!!   I think your "buffer" thought is at least a useful *analogy* to what might be really going on.  From a black box viewpoint, the behavior seems to fit the idea.  But I suspect the low level root cause is not from the same buffer mechanism(s) used in for analog i/o and digital i/o tasks.  It just *acts* similar.   More on this later.

I'm not sure about the two buttom dialog box, I havent any experience with that, and I have no errors. But it inspired me to start single stepping, and as soon I run the start task the LED starts blinking, and it keeps on forever till I run the Write function.  Are you checking for errors while still *inside* the loop?  The code you've posted doesn't.  You only find out at the end whether the very last loop iteration caused an error.  And only if you stop the conventional way, by clicking the GUI 'stop' button control on the front panel.  If you're going to the upper left of the toolbar to click the icon that looks like a stop sign, that's considered a bad practice as it aborts execution immediately and (especially in the past) can leave drivers and other resources in an unstable state.  

2. I'm not sure what a break point is, but I guess the single stepping feature kind of gave us the answer?  Yes.  But do yourself a favor and learn about breakpoints too.  And debugging "Probes".  While you're at it, another great debugging tool is the one for "Retain Wire Values".  It's up in the block diagram toolbar, just to the left of the single-stepping icons.

I'm starting to think that the problem overall can be caused by a bad architecture.  Probably not.  As you mentioned earlier, this is a puling scheme, and I should only write when there is an event instead of constantly puling values!!  Agreed.  But the rapid iterations and attempts to re-write pulse timing parameters are (probably) mainly helping to *reveal* the problem, not causing it.  But this is just a thought.. To me it seems like its not posible to create the channel without initializing some kind of counter. If I remove the start task, it just starts when it hits the write function as it has auto start as default. But still it insists on excecuting what I initiated in the create task. And the values cant be set to zero.. So do nothing is not a posibility!!  Correct.  This has been true as long as I can remember.  But my understanding of it was that a counter had to be allowed to generate 1 full pulse cycle worth of any pulse timing parameters you gave it before you'd be able to change to new ones.  I've speculated in the past (see this post, and further along in the same thread, this one too) that in a practical sense, you might get stuck with 2 full pulse cycles before you can change parameters.  I'm suspecting that there's some special behavior due to an unknown-to-me combo of the USB bus, the myDAQ device in particular, and DAQmx itself that bumps that up to 3 for you.  (Congratulations!  😖).   It's not exactly a buffer, but it acts like one.

   This whole problem intrigued me enough to send me down the rabbit hole.  Here's one other thread I found with a mention of low freq pulses that pulse 2 or 3 times before new parameters take effect.  The poster was using a (wait for it) USB-connected cDAQ device.

More info, musings, speculations.

 - Vague, mushy thoughts on new pulse specs needing to be "activated" by some unknown mechanism that requires the prior pulse specs to be used to completion.  Seemingly, something about DAQmx and/or your device (and maybe some/many other USB devices?) delays this activation until 3 full pulse cycles have completed.

- My own as-yet-unanswered questions about some picky details related to changing pulse specs for a pretty uncommon use case.   I follow up with some speculations, which are still my working theory until I learn otherwise.

   If you *do* get direct help from NI support, do me a favor and point them to that thread.  Whoever knows enough low level details to explain *your* observations is likely to be able to answer my questions over there too.

-Kevin P

[dytbaat]

Yeah I guess a buffer is just a good word to try and grasp whats going on. But in reallity I guess maybe some kind of communication bus is a better explanation..

Yeah I'm trying to monitor the errors inside the loop and at the end.. I never get an error! Unless ofcause I use bad practice and use the stop button in the toolbar. But I always use my front panel stop button.

Yeah I will take a lok on the break points. It kind of sound like a line coding thing, which is what I have been doing more. I've been using the retain wire values, thats quite nice.

Anyway.. I'm not sure we come any closer to a solution. And, basically it's no problem.. It's just because I'm currious about how it works.

Thank you for your time 🙂

BR

Peter

[Kevin_Price]

I'm curious too, but am coming to think there probably isn't a real solution or workaround.  I'm still intrigued by your lack of errors because several of the threads I looked into confirmed that DAQmx certainly *used to* throw errors for such premature writes.

Could you do one more thing?  Right click the error wire coming out of DAQmx Write.   Select Custom Probe->Conditional Error Probe and configure the "Condition" tab to pause on both errors and warnings.

I'm curious whether you might be iterating so fast that the error indicator gets overwritten too quickly for the eye to see.  Otherwise, it seems like a change in DAQmx for it to no longer throw errors for that situation, unless the myDAQ device is a special case that never did.

-Kevin P