08-29-2016 09:01 PM
Hi there,
I'm using a 9401 (with a 9215) in a 9174 chassis, Labview 14.0.1.
I have a very basic question that I can't seem to find an example for, to start me off on my current acquisiton project. I need to send a digital falling edge signal from the PFI0 channel of a 9401 digital I/O module, to a microcontroller. The task "DAQmx trigger: Start digital edge" doesn't seem appropriate, as requires a digitail signal to use at the source of the trigger, rather than sending a trigger signal. I attach here my attempt, but I'm doubtful its even close. I would like an output chart so I can monitor the signal being sent.
Can anyone help with this?
Thanks,
Claire
08-30-2016 01:24 AM
Hi Claire,
the "Start digital edge" is used to start a data aquisition task at receiving a digital input signal.
- To output a digital signal you should use a simple digital output: first set it to HIGH, then set it to FALSE to generate a falling edge…
- If your PFI0 also allows for data output (I didn't check the specs of the NI9401) you should use create a DAQmx CounterOutput task…
09-05-2016 08:48 PM
Hi Gerd,
Thanks for your message, and sorry for delay in my reply - I've been off work with a sick kid.
I'm trying to implement your first suggestion, without much luck I'm afraid. I've attached a VI here. Firstly this does not work as there is a mismatch between number of channels and number of lines, but I can't figure out how to make number of lines = 1. Secondly, I'm not sure this is at all correct - I can't figure out a way to make the digital output default "HIGH", then "FALSE" as you suggested. This seems like such a simple task, but I can't find similar examples!
I would really appreciate any further suggestions based on the attached?
Thanks,
Claire
09-05-2016 09:52 PM
Hi again Gerd,
Here is my attempt at setting the inital value to "High" ("True") until the user clicks the Boolean button on the GUI, after which it should set the value to "Low" ("False"). When I run this the true/false case does not change when the button is pressed, so the digital out value never switches to "Low".
Am I on the right track at all here, and if yes, can you suggest how to fix the above unexpected behaviour?
Thanks,
Claire
09-05-2016 10:39 PM
Hi again Gerd,
I seem to have remedied the above problem by shifting the case structure inside of the while loop (see attached). I'm pretty sure that I'm now sending a falling edge digital signal from the PFI0 to the microcontroller. Would you be able to confirm I have it set up correctly to achieve this, because it is not having the effect on the hardware that it should (i.e. it is not triggering the solenoid)? I don't know if the problem lies with my labview programming or with the microcontroller, so it would be helpful to know the LV code is at least theoretically correct.
Also, I can't see how to use the DAQmx CounterOutput task you suggested earlier, perhaps that is what I'm missing?
Thanks,
Claire.
09-06-2016 01:42 AM - edited 09-06-2016 01:44 AM
Hi Claire,
shifting the case structure inside of the while loop (see attached).
What's the point of this case structure? It's a classical Rube-Goldberg! 😄
"IF button THEN FALSE ELSE TRUE" is the very same as "NOT(button)"! And when you swap the boolean ON/OFF texts you don't even need to use a NOT function anymore…
I'm pretty sure that I'm now sending a falling edge digital signal from the PFI0 to the microcontroller.
Yes, but ONLY when you switch this button.
What's the point of reading the boolean output channel immediatly after setting it?
because it is not having the effect on the hardware that it should (i.e. it is not triggering the solenoid)?
Where's the problem?
Does your microcontroller receive the trigger signal?
Does your DAQ device really output the signal as expected? Did you cross check this using a DMM or scope?
Is the solenoid working as expected? Does the solenoid get the required voltage/current it needs to switch?
it would be helpful to know the LV code is at least theoretically correct.
This VI can be used to output a digital signal - it should work…
I can't see how to use the DAQmx CounterOutput task you suggested earlier
Did you check the example VIs in the example finder related to counter outputs?
09-06-2016 02:16 AM
Hi Gerd,
Thanks for your reply.
The point of the convoluted boolean case structure was to have the Write task normally receiving a "1" (High) signal (and only received a "0" when the GUI boolean button is pressed), which I don't think I can do with just a boolean button on the GUI (because this would be normally "0" and only "1" when pressed). From your response I figure that this is ridiculous and there is a different way of doing it. I guess I'll go back to the drawing board on that.
I am reading the boolean channel immediately after setting it so I can see that what I'm doing is having the desired effect. I will remove this in the final code.
If, as you say, this code does output a digital signal, the problem must be with my downstream hardware.
RE DAQmx CounterOutput, yes I did look at the examples but couldn't figure out how they apply in this case. If its the right way to do it, in combination with the code I've already posted, I'll go back and look at this again.
Thanks,
Claire
09-06-2016 02:24 AM
Hi Claire,
but couldn't figure out how they apply in this case. If its the right way to do it
This might be another way - independently from right or wrong…
In the first message you asked for a PFI0 I/O pin: those pins are commonly used for counters (and triggers). To read or write to a PFI0 pin you should use a counter task - that's why I suggested them…
Sometimes such a PFI pin also is used for "standard" digital IO: then you can use a simple DIO DAQmx task too to read/write this IO.
Conclusion: it all depends on your requirements!
When you want to set the DIO manually you should stick with your current basic digital output task. When you want to switch a TTL signal with a precise time clock you should use a CTR task…
09-06-2016 02:40 AM
Hi Gerd,
I believe the PFI pins on the 9401 can function as both a basic DIO and to "switch a TTL signal with a precise time clock". I initially thought I just needed the former, but I'll have to re-think it based on your comments.
Hadn't used the "not" function before (didn't realise it existed), thanks for pointing that out.
Next task will be integrating this all with a producer-consumer loop to actually acquire the analog data being read...
Thanks,
Claire