Triggering DAQmx from a GPIB device

[JimLifshitz]

Hi,

We have a GPIB device that sends out trigger signal to the computer, and we want the DAQmx card (PCI-6052E) to listen to that trigger signal. We tried doing this:

m_referenceTriggerEdge = DAQmxAnalogEdgeStartTriggerSlopeRising;

    try
    {
        // Create the voltage channel
        m_task->AIChannels.CreateVoltageChannel(channelName, "",
            static_cast<DAQmxAITerminalConfiguration>(-1),
            minimum, maximum, DAQmxAIVoltageUnitsVolts);

        // configure the internal clock
        m_task->Timing.ConfigureSampleClock("", rate, DAQmxSampleClockActiveEdgeRising,
            DAQmxSampleQuantityModeFiniteSamples, samplesPerChannel);

        // Set up the start trigger
        m_task->Triggers.StartTrigger.ConfigureAnalogEdgeTrigger(triggerSource,
            m_referenceTriggerEdge, triggerLevel);
        m_task->Triggers.StartTrigger.AnalogEdge.Hysteresis = hysteresis;

        (omitted a few graphing codes in between)

        // Begin the reading or whatever
        m_reader = std::auto_ptr<CNiDAQmxAnalogMultiChannelReader>
            (new CNiDAQmxAnalogMultiChannelReader(m_task->Stream));
        m_reader->InstallEventHandler(*this, OnEvent);
        m_reader->ReadMultiSampleAsync(samplesPerChannel, m_data);

}

By default, triggersource is set to "PFI0" and triggerlevel is set to "1.00". The result, however, is rather peculiar: There will always be a 200284 error, unless the triggerlevel is set to "0" while its previous run is set to "1". In other words, if first run the acquisition using triggerlevel "1", which would still give the error, but then if the next one is set to "0", DAQ sees the trigger. However, if one continues to run using triggerlevel "0", the subsequent runs will give the error. Where did we do wrong?

Also, is there a way to use Measurement and Automation to measure the trigger signal coming cross GPIB?

Thanks,

Jim

[Jacob_R]

Hello Jim,

That is interesting behavior. A first good step that you mentioned would be to see what the device is actually outputting. Unfortunately we can't monitor the trigger lines in MAX; however we can see what is being outputted by connecting to an AI channel.

What is the message for that error code?

Could you also provide some of the configuration settings you are using?

Thanks,

[JimLifshitz]

Hi Jacob,

Thanks for the reply! The error message is as followed:

-------------------------------------------------------------------------------------------------------------------

Some or all of the samples requested have not yet been acquired.

To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples available sooner, increase the sample rate. If your task uses a start trigger,  make sure that your start trigger is configured correctly. It is also possible that you configured the task for external timing, and no clock was supplied. If this is the case, supply an external clock.

Property: CNiDAQmxStream::ReadRelativeTo
Corresponding Value: DAQmxReadRelativeToCurrentReadPosition

Property: CNiDAQmxStream::ReadOffset
Corresponding Value:


Task Name: aiTask

Status Code: -200284

-------------------------------------------------------------------------------------------------------------------

And the rest of the default parameters are below:

minimum = 0.000

maximum = 10.000

samplesPerChannel = 1000

rate = 1000

hysteresis = 0.00

Thanks,

Jim

[Jacob_R]

Hey Jim,

So there are a number of potential sources of this error. It looks like your code is set up properly, although we will need to configure the settings. Luckily we have a great KnowledgeBase article that goes over some of those troubleshooting options. I would suggest troubleshooting the acquisition in MAX, where we can be sure it is not related to coding.

Have you read the value of the analog trigger to see if it is behaving properly?

[JimLifshitz]

Hi Jacob,

The problem is solved, which the problem itself is much more benign.

We thought that the trigger is transfered via GPIB. But after the pin measurements and some digging through the manual, it turns out that the trigger signal is transfered via another port, which worked after we connected that port to PFI0 on the analogue box.

Nevertheless, thanks for your assistance.

Jim