Writing Encoder Data to Waveform

[JSuschana160]

Hi all,

I'm working on a project where I need to run an encoder using LabVIEW and using a cDAQ 9185 with the NI 9361 module. I took the example counter code that NI provides and combined it with the Function generator they also provide. I'm trying to get the data to read to the waveform in real time. I didn't receive any errors with pin connections so the pins are connected correctly. Is there any way to tell if the encoder is actually being read? Also, how would I go about making it read to the waveform? I tried using the write function but the data types would not match properly. I've attach snips of the code below for you to look at. Any help is appreciated. Thank you!

[cbutcher]

Difficult to see what's really happening from these cropped images (by the way, when talking about LabVIEW code, snippet has a different and specific meaning - a snippet can be generated from the Edit menu and contains drag and droppable code).

Please upload the VI you're trying to run and perhaps also expand on how you verified no "errors with pin connections".

[JSuschana160]

Thanks for the reply. I've attached the LabVIEW VI to this. For verifying the pin connections, I looked up the pinout for the specific NI module and encoder. I had also ran the VI prior to connecting the encoder and received and error stating that there was no device connected. After connecting the encoder, I no longer received that error message.

[cbutcher]

Thanks for uploading the VI. I can see a little better what you've done now, and maybe make some comments - I'll number them for ease of reference but they aren't necessarily in any useful order or implied importance/priority...

1. You have one loop acquiring "Samples per Loop" samples from the Angular Encoder task, but the time required for these samples to appear depends on the "Sample Clock Source". Depending on this sample clock, you will get simulated data at different speeds (currently there's no connection between the two - this might be by design or by accident)
2. Depending on your hardware, you might be getting a sample clocked input, in which case the "Sample Rate" input is important for the same reasons as 1. Since you mentioned the 9361 module, I'm going to guess you're using this sample clocked acquisition mode. That will at least make your loop rate repeatable in principle.
3. There are a lot of property nodes being written in the loop that probably don't change all that often. A more typical design with almost certainly better performance would move these settings into a separate loop and use an Event Structure to only update the property nodes when their inputs changed. 
4. You use a local variable to pass data from the acquisition to the graph. There's no need to do this, you can wire it directly and avoid race conditions.
5. I don't know what the behaviour will be at the Merge Signals node near your Waveform Graph 2. Generally, the Dynamic Data Type (blue wire) can hide a lot of details and make it harder to understand what's happening - you might have better luck if you stuck with the arrays or waveforms (orange or brown respectively).
6. You can acquire the encoder data directly as a waveform using the polymorphic dropdown menu (I guess maybe you already know this)
7. You can get waveforms for the generated signals via the Signal Processing > Wfm (waveform) Generation palette. It has VIs for each of the waveforms you want (triangle, sine, etc). Making this change might simplify the series of nested case structures you have. The use of enums could also be useful - then you can get the case structure case labels (the bit that appears in the dropdown at the top of the case structure) to have a nice/useful string rather than just "0", "1", "2", etc...
8. Moving the file writing code into a separate loop (via a Producer/Consumer architecture) will probably improve your loop rates, which might be desirable. Similarly, the processing (spectral/tone measurements) could also be done separately from acquisition. Some of the "Channel Wire" examples might be of interest for this - they support "pipeline"-style systems nicely. Otherwise, there are many examples of Producer/Consumer using Queues (which are much older within LabVIEW, and are perhaps "lower level", but also easy to read, use, control, etc).

Let me know if any of these sound useful but you can't make them work from what I've written and I'll try expand. Alternatively, maybe you'll change a few bits and it'll work better quite quickly 🙂 Good luck!