NI PCI 6289 and Gurley VX35H encoder and Gurley VF decoder. Coding LabVIEW program to read 25 analog inputs and the reading from the encoder/decoder.

[wolvie]

Coding LabVIEW program to read 25 analog inputs (pressure transducers, load cells, etc) and the reading from the encoder/decoder. Both the analog inputs and the encoder reading must be sampled at 200 Hz. All ideas will be considered. Since communication with encoder/decoder is digital, synchronization is major issue. Other issues include ensuring that the encoder/decoder reading is sampled every 5 mS. Attached are information sheets on the encoder and decoder as well as subvi planned to be used to communicate with the encoder/decoder.

Other information includes:
Using SCXI-1001 chassis, SCXI-1125 modules for analog inputs, and SCXI-1302 feedthrough used with SCXI-1180 to communicate with encoder/decoder. LabVIEW version is 8.2.1 in windows XP.

Also interested in knowing if real-time system will help? If so how? Will using queues help? if so how?



Thanks

Carlos

[Ed W]

Hi Carlos,

Thank you for posting to the NI forums.  There is an example program that installs with the DAQmx driver that synchronizes analog input with digital input.  It can be found by opening the LabVIEW Example Finder and navigating to Hardware Input and Output >> DAQmx >> Synchronization >> Multi-Function >> Multi-Function-Synch AI-Read Dig Chan.vi. 

Using this example, you can set the sample rate for both the analog and digital inputs to 200 Hz. 

I hope this helps – please post back if you have any further questions.

Ed W.

Applications Engineer

National Instruments

[wolvie]

Ed, Thanks for your responce. I looked at the example that you mention. Unfortunately I can not use that example. Getting a value from the encoder takes seven steps communicating back and forth. Becouse of this, communication with the encoder is "On Demand" instead of "Continuous". For the analog inputs communication is "Continuous". The issue I am having is synchronization. The encoder is sampled every 5 mS and the samples are grouped in groups of 50. This way every 250 mS the group is incorporated into a group containing 50 samples from all the analog channels, the new group gets processed (calculations and display data in graphs) then written to an ASCII file. What happens to the encoder data is that the time between any two groups is longer than 5 mS (another way to look at it: the time between the last sample from the previous group and the first sample from the present group is longer than 5 mS. In some cases it has been around 600 mS). Which means that the encoder is no longer in synch with the analog inputs. I have different versions of the program. I have versions of the program with a while loop for the analog inputs and a while loop for the encoder, I have versions with while loops and queues. I have versions with one single loop where the encoder gets read (50 times, 100 times, 200 times) then the analog inputs but no luck. Any ideas Carlos

[Ed W]

Hi,

Since you’re using “On Demand” mode for your acquisition, all of the timing will be done in software.  Therefore, the 600 ms delays that you’re seeing are expected. 

Also, I am a little unclear about your application.  You mentioned that you’re using an encoder/decoder, but are you using any digital I/O?  If you’re just using the analog inputs, you could perform hardware-timed retriggerable analog acquisition using an external digital trigger.  There are numerous Knowledge Base entries and example programs. 

How Can I Perform a Retriggerable Acquisition?

Make sure to check out the related links as well.  Post back if you have further questions.

Ed W.

Applications Engineer

National Instruments

[wolvie]

Ed,

Yes I am using DIO to communicate with the encoder/decoder. 

Like i said initially I am looking for a way to synchronize the reading of the analog inputs and the digital communication with the encoder/decoder.  My goal is for the analog data and the encoder/decoder (digital) data to be sampled every 5 mS.  The reasonf or choosing "On Demand" for the communication with the encoder/decoder is because everything else I tried did not work.  I am hoping someone has done something like this and can give me some ideas.

Thanks

Carlos S.

[Brian F.]

Hello. 

Traditionally, the example that Ed provided in his first response works well for the application that you are describing.  Could you please explain to us why this doesn't work?  Do you receive errors or does it not fit the solution that you are looking for?  You mention that 7 steps of communication are required for you to read from the encoder.  Can you describe these steps?  Usually, communication with an encoder is more straightforward than 7 steps of communication.  Any clarification would be very helpful.

Let us know and we will be happy to help further. 

Brian F
Applications Engineer

National Instruments

[wolvie]

Brian,

Thank you for your support. 

I am new to DAQmx so it is possible that I am not seeing how the example that Ed provided applies to what I am trying to do.  I will go back and take another look.   The reason I believe that the example does not fit with the solution I am looking for is that the example tries to do both the reading and the writing in parallel and I need it to be serial: 2 commands -> get low byte, 1 command -> get mid byte, 1 command -> get high byte.  Once the three bytes are obtained, they get combined and the highest four bits get removed (not part of data).  That is how the 20 bit data is obtained.  I have attached the VI that  I use to communicate with the encoder/decoder so that you can see what I have done so far.


Thanks again Brian

Carlos

[Brian F.]

Hello Carlos. 

Thanks for that explanation and your code.  The issue is much clearer to me now.  I still believe that Ed's example provides a great starting point for your program. 

The issue that we are going to see as this application progresses is that there is no way for all of the digital inputs to be synchronized with the analog input since the digital information will be read in series.  However, if you follow the framework that has been built, you can start the reading of the analog inputs and the reading of the digital input at the same time.  So, right when you read the analog data, you will be writing the first 2 commands to the encoder.  If you wish to read the low byte in sync with the analog data, you could write the first 2 commands to the encoder before you start both read tasks.  The other consideration is that if the 7 steps of encoder communication take longer than the rate at which you wish to acquire your analog samples, your program will become out of sync. 

The second point of consideration is that the timing considerations that this program brings will probably require the use of a producer/consumer architecture.  Place the acquisition tasks in the producer and the processing code in the consumer loop.  Then, you can use queues to pass data from the producer loop to the consumer loop processing the data only when you have time (ie, the processor is not busy acquiring).  

Let me know if this helps you with your program.  We will be happy to help you further in any way we can.  

Brian Fleissner

Applications Engineer
National Instruments

[wolvie]

Brian,

Yes.  You hit the nail right on the head as far as the issues that I am having in coding this program. 

As for the seven steps taking longer than the analog sampling rate, thankfully, the seven steps take around 2 mS and the requirements call for sampling all data no faster than every 5 mS. 

In thinking about what you said about the using the built framework (LabVIEW example), am I correct correct in assuming that the analog data, along with the digital data, will sampled by the LabVIEW program one sample at a time?  A different way to phrase it : Is the producer loop's loop time 5 mS? 

After reading your responce, and if the producer loop's loop time is 5 mS then I believe I understand how Ed's recommendation will work in my program.   I will work  with Ed's recommendation. 

Brian, thank you very very much. 

Carlos

[Brian F.]

Hello Carlos. 

I have modified the example that has been the center of discussion to reflect your application needs a bit better.  Since we have the need to only acquire one sample at a time, we will want to use Hardware Timed, Single Point Mode.  If we set this to 200 Hz, then the loop will execute about every 5 ms.  Then, I placed a digital task in parallel, which will also execute at the 200 Hz frequency as a result of it being in the same loop as the analog input read.  All you need to do now is set up a series of digital write and read VI's that will perform the communication necessary to get the information from the encoder in less than 5 ms.  Please note that this execution will be based on software timing so please minimize the number of programs running in the background when you run this application. 

Let me know if there is anything else we can do for you!

Brian F
Applications Engineer
National Instruments

Message Edited by Brian F. on 06-01-2007 11:33 AM