RTSI cable with PCI 6034 and 6602. Sanity check of LabVIEW code.

[_Ian_]

Hi All,

Please could someone take a look at my code (LabVIEW 8.5) and tell me if it is doing what I hope it is? (!)

My aim:

To log analog voltages from a PCI 6034 and angular encoder data from a PCI 6602. I want my voltage and angle data to be synchronised.

My intended approach:

The two cards are connected with an RTSI cable and configured in MAX. One of the counters on the 6602 is set up as a clock. I think I am using this clock to make sure that my angles and voltages are synchronised. I want to read in a load of data from both sources, process it and then repeat.

The synchronisation game is a bit new to me - The code runs, but at present I am unsure if I am getting the sychronisation I require. Please could someone comment on whether this looks right and/or give me pointers for improvement?

Thanks!

Ian

[MHutch]

Hi Ian,

Making a few changes based on our DAQ course material, I have made some changes to your code. The main thing was removing the counter, as this was unnecessary to synchronise the devices. If you could give the code a try and see if it all works as expected, that would be great. 

Any problems or questions, don't hesitate to let me know. 

Kind regards,

[_Ian_]

Hi Matt,
Thanks for the update - are you able to save your version to 8.5 please? (edit: or just post a screen shot - I'm happy to work from that if it is easier for you)

(I should shortly have access to a newer version but right now am limited to 8.5)

Thanks,

Ian

[MHutch]

Hi Ian, 

Sorry about that! I posted in somewhat of a hurry, Here's a compatible version. 

Kind regards,

[_Ian_]

Thanks Matt,

I seem to get a timeout error when I try this version:

Error -200284 occurred at DAQmx Read (Analog 2D DBL NChan NSamp).vi

Could this be because your version does not explicitly tell the counter when to start so no measurements ever get clocked in?

Is there anything 'wrong' with the inclusion of the counter in the original version?

I guess that my main question is whether I am actually synchronising my two cards correctly.

All the best,

Ian

PS - As an aside, using a Build Array function prior to a Merge Error function looked a bit unusual to me?

[MHutch · Accepted solution]

Sorry Ian,

That code was a little thrown together so you might need to disregard it. The build array was incorrect, and I don't know entirely how it got in there. 

The counter output in the middle of your task isn't actually doing anything. You could remove this, and so long as you had one start task dependent on the other as you do already, and share all the same clock settings, that should start the tasks at the same time and maintain synchronised readings. 

My one piece of advice for better start synchronisation on top of that would be to use a hardware trigger to start the tasks. so the start is reliant on a hardware clock and not software. 

Kind regards,

[_Ian_]

Thanks Matt,

Its good to have some feedback on this as synchronisation of hardware is new to me.

All the best,

Ian

[Kevin_Price]

Here's a few more comments as you get started with hardware syncing, all in reference to the code screenshot in the original post.

1. Your sequencing is correct -- both the AI and encoder tasks are started before you start generating the pulsetrain they use as a (shared) sample clock.  This was an important step to make sure that they both start sampling at the same time.

2. Consequently, there is no need to add hw triggering to the tasks.  The shared sample clock alone is sufficient here.

3. As constructed, your middle counter task *is* necessary.  Without it, you'd no longer be generating the pulses that the other tasks are told to use as a sample clock.

4. An alternate construction is possible that doesn't require the middle counter.  You could allow the AI task to generate its own 5000 Hz clock by leaving the sample clock source input unwired.  Then you could configure your encoder task to use "/PCI-6034/ai/SampleClock".   You would also then need to start the encoder task *before* starting the AI task.

5. I'm wary about seeing several unwired error terminals on DAQmx functions.  Some errors will show up again on subsequent calls with the DAQmx tasks, but any error on your pulse generator will be lost.

6. Also wary about the slim margin on your DAQmx Read timeouts.  I'd make a little breathing room between the theoretical 1 second to accumulate 5000 samples and the timeout value that's also 1 second.  You don't want to time out unnecessarily, right?  I'd bump that timeout up, probably up to 2 seconds lacking info that might dictate differently.

7. All in all, looks generally good, just a couple things to touch up.

- Kevin P

[_Ian_]

An excellent post Kevin, thank you.

I think I tried something along the lines of 4th point at one point but got confused somewhere along the way.

I guess I need to start trusting the DAQmx functions to have a bit of intelligence - at first sight it feels like there can't possibly be enough code for everything to know what it should be doing and when! (although I suppose that is the whole point of these functions )

Comments on errors and timeout duly noted.

Its a shame I can't share the marked solution between you and Matt...

Thanks again,

Ian