i have a question regarding the generate Signal command. I am using an NI USB 6000 to control an air pressure pump. When i set the number of samples per second and numbers of samples to 2000 the while loop takes 2 seconds, therefore the frequency decreases unintentionally to 1 Hz. But when i set both to 1000 i become the awaited result with a frequency of 2 Hz. Why does that happen that way?
Thanks for providing the VI, it is visible from the code that the deterministic (hardware I/O) and non-deterministic (File I/O) tasks are within the same loop. I would recommend to separate these out and the loop will not iterate until the File I/O has completed.
Unfortunately the USB-6000 also does not support hardware timed I/O, so you cannot achieve deterministic reliable timing with a Digital I/O task. This is why you have 1 sample on demand as the set timing methodology. Essentially the answer is that you cannot control the rate through the hardware configuration as there is no clock associated with the DIO lines, what is the project itself?
I am wondering why you have also used MathScript for some decision making? A case structure could handle the range idea, for the z calculation you could also have an array of numbers you compare too which would be much cleaner. This would have little effect on your current issue and is simply an observation.
I would also recommend that if you have an active LabVIEW License, look into the online training available through your NI profile, Core 1 and Core 2. Core 1 explains LabVIEW fundamentals like case structures, creating ranges while Core 2 discusses separating out tasks such as File I/O and DIO as I mentioned initially.
Cleaning up some of your code will help you determine possible causes, along with making it easier to have your code run at the speed you want.
It's not obvious what you're trying to do with the inner for loop - you autoindex over boolean values, then build an array (of one value) and send it to a DAQ Express VI. These VIs are fairly slow, and you're trying to iterate over it at 1 or 2 kHz. This isn't going to work out for you.
Additionally, you have some pretty unnecessary MathScript nodes - you can replace these either with a case structure or a Search 1D Array node. The case structure would need only two cases (you can have more than one value in the case structure selector) and an array of values for z=1 and a Search 1D Array with a check for a negative 1 output (or just negative).
I implemented one of each of these, but the case structure was fairly ugly. A subVI with an array of clusters of ranges and a set of In Range or Coerce nodes might be better.
Your Simulate Signal was set to run as fast as possible, which will destroy any chance of measuring a sensible rate from the iteration counts you're looking at and the subtraction.
It's not obvious to me what you're trying to do here with your multiple express VIs with no inputs (presumably they're like that to allow it to run on other people's computers, so thank you, both for the ease of testing and the VI being attached).
If you let us know, maybe someone can provide tips on a better architectural choice to structure your code and make it easier to understand, and faster to run (plus more reliably timed!)
Like that we hit most of the same points here, I still want to highlight that the USB-6000 has no hardware timing for Digital I/O. A Windows PC would typically not allow you to run a thread reliably every 1ms (1kHz - from the number of samples and rate you mentioned) so despite that it is correct that the code should meet the practices given in Core 1 and Core 2 I doubt the hardware could achieve this reliably.
Depending on how Mohamed wants to control the air pump, it might be (as with the current VI) that the boolean only needs to change comparatively infrequently - here it is changing 4 times per second (with a 2Hz square wave) even though the Digital Output is being called at kHz speeds.
Depending on the timing requirements, it might be possible to avoid these problems by only checking for the passage of time and then changing the boolean on DigOut a few times a second. Windows should manage this vaguely acceptably. Definitely Mohamed doesn't want to be running a loop every 1ms (I hope!).
Ah okay, then yes the USB-6000 would be sufficient if this is indeed the case. However as you have also spotted, doesn't need to be run as fast as possible.
Therefore the limiting factors would be purely coding style.. I don't quite understand your spoiler question?
I had problems a while ago with trying to get timing values. I was surprised, because although I knew that Windows wouldn't provide me with sub-ms timing values simply, I hadn't thought that 1Hz sampling would be problematic. With a greater understanding of process scheduling, it all makes sense, but I was initially quite confused by the whole issue.
I put it in a spoiler because it really has nothing to do with this thread and I wanted to prevent it causing confusion - in the spoiler tag, perhaps it can provide an interesting (to me, at least) example of Windows timing difficulties without overly polluting the question.
That makes sense now, I just ran a VI based on your elaboration. It's an interesting topic, I've always thought we should have technical content on this although it is not an NI concept.
i want to control the air pump te preform a two full cycles, cycle means press and release, in one second, my question is, why when I select the samples to read in the generating signal to 2000 it preforms as if it is 1 Hz, while when putting the rate to 1000 it excites the way it should
The question has been answered, your code needs re-evaluation and re-work. Separate out your tasks into producer/consumer, don't use Express VI's and the current code does not meet best styling practices nor best coding in terms of how things are achieved. Additionally why are you sending 2000 samples if the signal really only varies at 1Hz?