Embedded Data Logger triggered by digital line

[swenp]

Hi everybody,

is it possible to use the embedded data logger in some kind of hardware triggered acquisition?

The PLC has to run at 2kHz with an inline model, but the data logger shall only log channel data upon rising edges of a digital line acquired by a DAQ card. The frequency of this signal will be somewhere between 0Hz-33Hz.

I'm thinking about making the Embedded Data Logger to be an ansynchronous device and trigger the TimedLoop by e.g. a RTSI line, but maybe there is an easier solution?

Cheers,

Swen

[Pie56694]

Hi Swen,

Assuming NI VeriStand 2010...To use the built-in EDL custom device in this manner, you'll trigger off of a channel in your system definition.  The most direct implementation is to include the trigger source in the system definition by means of built-in hardware support (DAQ in your case), and map the trigger source to the "Log Trigger".  The "Log Trigger" channel is found in the "Commands" section of the EDL custom device.  You won't see this section until you add a log file to the EDL.  The EDL is open source.  If you look at the code (Custom Devices\National Instruments\Embedded Data Logger\Embedded Data Logger - Engine - PharLap.llb\Embedded Data Logger RT Driver VI.vi) you'll see it's an Inline Custom Device but it dynamically launches an asynchronous processes for File IO.  That design mitigates the jitter that would be induced by doing file IO inside the Primary Control Loop.

One concern I have is your trigger signal rate, but it would help to have more information about your requirements.  Do you want to log a set of channel values only at the exact instant the DI line transitions?  If that's the case, mapping "Log Trigger" to the DI line might not work depending on the tolerance of the sample time (e.g. 'sample all channel values one time within 500 us of the trigger').  More information would help.

Steve K 

[swenp]

Hi Steve,

mapping the DI line to the data logger trigger is an option, thanks for the hint.

I will check the requirements for the maximum time between occurence of trigger signal on hardware and acquiring the data by the logger.

Another thing is that logging shall only be done once upon a low->high transition. If I directly map the DAQ line to the trigger channel values will be recorded as long as the line state is high. I.e I will have to buffer the current line state into an user variable and check the current line state to the n-1 line state by a calculated channel (conditional). Then map this calculated channel to the logger trigger channel. In which order are these steps done? Will I get the result of a low->high transition during a single iteration of the PLC?

Cheers,

Swen

[Pie56694 · Accepted solution]

Hi Swen,

It order of execution depends on the controller's mode: parallel or low latency.  You'll need to refer to Understanding the VeriStand Engine also.

Engine Step	Target in Parallel Mode	Target in Low Latency Mode
1.	Read HW inputs	Read HW inputs
2.	Read asynchronous custom device FIFOs (N-1)	Read asynchronous custom device FIFOs (N-1)
3.	Read Data From HW of inline HW custom devices	Read Data From HW of inline HW custom devices
4.	Read from models	Read from Data Processing Loop (N-1)
5.	Read from Data Processing Loop (N-1)	Process system mappings
6.	Process system mappings	Execute Model of inline model custom devices
7.	Execute Model of Inline Model custom devices	Process system mappings
8.	Process system mappings	Execute generators
9.	Execute generators	Process system mappings
10.	Process system mappings	Write to models
11.	Write to Data Processing loop	Wait for models to finish
12.	Write to models	Read from models
13.	Set HW outputs	Process system mappings
14.	Write to HW of inline HW custom devices	Write to Data Processing Loop
15.	Write asynchronous custom device FIFOs	Set HW outputs
16.		Write to HW of inline HW custom devices
17.		Write to asynchronous device FIFOs

An important note about NI VeriStand 2010: Data obtained in a previous step is not available to a subsequent step until a Process system mappings step has executed.  If I understand your proposal correctly, then your system definition would contain the following:

DAQ digital input

One user channel for buffering

One calculated channel for comparing the buffer to the current data

System mappings for:

• DAQ to user channel
• Calculated channel to log trigger

In parallel mode (default) I thinik things would run like this:

Iteration Y

• Read from DAQ digital line (Step 1)
• Read result of DPL calculation during iteration X (Step 5)
• Map DAQ value to user channel, map result of calculation to log trigger (Step 6)
• Write DAQ value and user channel to DPL and perform calculation (Step 11)

So, to answer your question directly, you won't trigger the log from a DAQ read in the same iteration of the PCL.  If everything's running on time, you'll have a one-tic delay because calculations happen in the DPL, but you'll still start logging within one dt of the PCL.

Regards,

Steve K

[Pie56694]

Another solution is to perform the calculation in an Inline Model custom device.  This would get rid of the 1-tic delay.

Create a custom device input and an output channel.  Map the DAQ input to the custom device input.  Perform the calculation inside the custom device and write the result to the custom device output channel.  Engine step 8 will map the result to the log trigger channel in the same iteration that read the hardware.

Steve K

[StephenB]

You can also do this calculation in a model (LabVIEW, Simulink, C, etc) and run in low-larency mode to avoid a 1-cycle delay

[swenp]

Thanks Steve and Stephen,

I checked the requirements and the 1-cycle delay will be ok. No need to build a custom device.

Regards,

Swen