Few problems with acquiring and generating data from 3 modules (cDAQ 9178 Chassis)

[ngio]

Hey Tom,

Thanks for the great info.  I suppose performing the sequential error connections is a great replacement for the sequence structure.  Although I guess its probably just something overlooked but wouldnt it be a good idea to connect the error out terminal of the DAQmx Trigger (for AI) to the start task vi of the CI? or would this upset the sequence of events?

Also, good note on using the rate input instead of a specific external sample clock.

Thanks again for the help.

Nick

[Tom_W_[DE]]

Hey Nick-

Great catch.  Yes, I would recommend that change that you mentioned.  Unfortunately this shows that I didn't really fully execute and debug that code , but hopefully it will at least get you started.

[ngio]

absolutely, i just wasnt sure if that was a "convention" that people usually use... (circling back to the creat task.vi).

Thanks again for the great help, I'll run it tomorrow and see what happens.

Nick

[ngio]

Hi Tom,

So some good and not so good news I suppose,

Good News: the start trigger seems to be functioning (in the sense that DAQmx Read.vi begins to collect samples on all channels)

Bad News: The sample clock is still giving me issues, at the "reserve task.vi" for the CI Angular Encoder task I get the error that the sample clock source is /cDAQ1/?/SampleClock from AI task, basically it can't determine which clock to use.  When I hardcode the sample clock source for the Analog Input channels as the cDAQ2/100kHzTimebase and set the rate to 100000s/sec the "reserve task.vi" does not error out, it reads the sample clock as cDAQ2/100kHxTimebase/SampleClock and everything functions.  Although I can't change rate in this case.  

Any Ideas why this is happening?

Nick

[Tom_W_[DE]]

Hey Nick-

Would you mind posting your VI so I could give a pass at the errors you're seeing?  I could write up an example myself, but it might be faster (and more helpful) to just glance at yours.

Thanks-

[ngio]

Not a problem...  its attached below.

Nick

[Tom_W_[DE]]

Hey Nick-

I'm glad you brought up this issue, because I learned some valuable info about routing on cDAQ that I didn't properly understand before.  Thanks to RCampbell from my team for some assistance with this.

What you actually want are the Terminals for clocks and triggers and not the Sources as I suggested before.  Because of the myriad routing options on cDAQ, the Sources are signals that aren't particularly useful (like timebases and the like, as you noticed).  The Terminals, on the other hand, represent named routing sources that can generally be routed as needed within the chassis.  Some of the Terminals aren't fully determined until the master tasks are Reserved by DAQmx due to shared resources, so it makes for a complicated scenario at configure-time.

As it turns out, all you need to do additionally is Reserve the master task to make sure all Terminals are properly chosen and reserved, and then you can route those terminals to your slave tasks and fire everything up.

I borrowed some portions of your VI for testing and cleaned things up a little bit in the interest of helping the example be a bit more readable.  But, your code can be re-used with only a couple of slight modifications.  Take a look at the attached VI and/or screenshot (in case you don't have access to LabVIEW 2011).

[ngio]

Hi Tom,

Thanks for the input.  I have incorporated your ideas into my vi although I keep getting the error that there are no registered trigger rlines between the devices in the "Delayed counter output" start trigger input and the "Non-delayed counter output" start trigger terminal.  Is there a way to make these two terminals connect or is there something wrong with my vi?  I have attached a screen pic and the vi.

Nick

[Tom_W_[DE]]

Hey Nick-

This is a shot in the dark, but is there any possibility that '/cDAQ2/...' on your 'source of ticks' input should point to a different chassis?  The only time I would expect to see that error about missing trigger lines for routing is if one task refers to lines or channels on an inaccessible second chassis.

If I'm missing the mark, please post a screenshot of your MAX configuration with the cDAQ chassis and modules of interest displayed so I could get a better idea of the routing requirements.

[ngio]

Yes you were right!  I guess I changed it once while not plugged into the chassis so it tried to connect to the "imaginary" chassis in my computer.  Unfortunately though my vi does not give me synchronized data between the modules.  I read in the data from the analog channels on a 9201 module mounted in slot 2 of the 9178 and the encoder data (9401 DI/O) in the 5th slot of the 9178.  If you look at the vi .png i posted in my last post I thought it would have produced synchronized data sampling but unfortunately not.  I'm trying to coordinate angular position of a shaft (read through an angular encoder) and the relative pressure in the cylinder (analog input).  I have attached another photo plotting the encoder data (0--360degrees) and the pressure data (in PSI).

 Something that is really strange is that the output pulse train does not have this issue, only the inputs!  I'm very confused now since I am running the engine (spark ignition timed by encoder angle throuhg the CO Output Pulse.vi).  If you need more clarification as to what's going on feel free to ask, although I appreciate any help you can give.

Thanks,

Nick