Disconnect counter output line

Hello,
I have a question that has been bothering me for awhile. I'm using an M-series DAQ card which allows the ctr0 output to be placed on any PFI line. Is there any way to disconnect the ctr0 output from all the PFI lines? I'm only using the ctr0InternalOutput and I don't want it routed to an external pin.
The reason I ask is because the ctr0InternalOutput was being used as timing for several acquisitions, but the output was also appearing on it's default output pin. However, this DIO/PFI line was being used as a digital output for relay control and every time the counter was used, the relay would switch. I "fixed" it by routing the counter output to an unused PFI line, but I would like it not to appear externally at all.
Thank you for your help,
Jon

Thanks, I will give that a try. Seems so obvious now...
Jon

Similar Messages

Can I generate pulse trains on more than one counter output at the same time?

I have a PCI 6601 card with a BNC 2121 to connect the signals to two devices. The card is used as a trigger for both devices and I want to be able to generate pulse trains on two output channels at the same time, with a time delay between the two. How do I do that in Labview 7.1 Development with DAQmx?

I feel foolish for not being able to figure this out, but it still doesn't work. Attached is the VI I use now. Counter 0 generates a finite pulse train and I programmed Counter 1 to generate a retriggerable single pulse triggered by CtrOinternaloutput. I still get the same error message: -50103 The specified resource is reserved. The operation could not be completed as specified.
The same happens if I set the trigger for counter 1 at PFI36 (default output of counter 0) or any other PFI line. If I try a pulse train generation on only one of the counters, both work fine.
If I try the example in traditional DAQ for multiple counter outputs with phase delay, it works fine.
Can you tell me what I'm doing wrong?
Attachments:
Shutter_AND_lamp_trigger.vi ‏103 KB

Counter Output/Counter Input PXI Signals Behaving Erratically

Question for all your LabVIEW guru's out there,
I am running a frequency loopback test using the NI PXI 6229 MIO DAQ card. I am generating a "Counter Output" pulse train signal which feeds through my device under test and then back out of my device under test and back into the PXI 6229 for a "Counter Input" frequency measurement. Both the "Counter Output" and the "Counter Input" are assigned different PFI lines using DAQmx in LabVIEW.
I have 4 lines to test on my DUT. All four lines run this same frequency measurement but with different PFI lines on the PXI 6229. Each line is test independently.
This is my setup for the 4 lines:
Path 1: P2.0 (Counter Output - Pulse Train) -> DUT (Device Under Test) -> P2.1 (Counter Input - Frequency Measurement)
Path 2: P2.2 (Counter Output - Pulse Train) -> DUT (Device Under Test) -> P2.3 (Counter Input - Frequency Measurement)
Path 3: P2.4 (Counter Output - Pulse Train) -> DUT (Device Under Test) -> P2.5 (Counter Input - Frequency Measurement)
Path 4: P2.6 (Counter Output - Pulse Train) -> DUT (Device Under Test) -> P2.7 (Counter Input - Frequency Measurement)
where:
P2.0 = PFI8
P2.1 = PFI9
P2.2 = PFI10
P2.3 = PFI11
P2.4 = PFI12
P2.5 = PFI13
P2.6 = PFI14
P2.7 = PFI15
I have a LabVIEW VI which generates the "Counter Output" and reads the "Counter Input" frequency. I am seeing weird behavior from the PXI 6229 card. I can test "Path 1" and "Path 2" and the frequency I read is what I generated. No issue there. However, when I test "Path 3" and "Path 4" the frequency measurement is erratic. The readings are two different frequencies repeated over and over again and none of those frequencies are the expected frequency which was generated out of the "Counter Output." If I reset the card, and start by testing "Path 3" and "Path 4" the frequency readings are correct and the erratic behavior is gone. However, when I try to then test "Path 2" and "Path 1" now those lines have the erratic frequency issue. I can continue resetting the card and see same issue. The PFI lines that I test first will always pass.
To summarize:
Steps Taken:
1. Test Path 1 = SUCCESS
2. Test Path 2 = SUCCESS
3. Test Path 3 = Erratic Frequency (Two Frequencies repeated over and over again in my frequency results array)
4. Test Path 4 = Erratic Frequency (Two Frequencies repeated over and over again in my frequency results array)
5. Reset the PXI 6229 Card
6. Test Path 3 = SUCCESS
7. Test Path 4 = SUCCESS
8. Test Path 3 = Erratic Frequency (Two Frequencies repeated over and over again in my frequency results array)
9. Test Path 4 = Erratic Frequency (Two Frequencies repeated over and over again in my frequency results array)
I am wondering if Port 2 (P2.0-P2.7) on the 6229 card has certain dependecies and this is why I am seeing issues. I am trying to get around this issue so that I don't have to always reset the card.
Are P2.0-P2.3 (PFI8-PFI11) and P2.4-P2.7 (PFI12-PFI15) treated differently or require different setup? How do I resolve this issue?
Thanks so much!

I have a theory...
The DAQ card follows a policy called "lazy uncommit" wherein the terminal used for the output will continue to be connected to the counter even after the task has completed (until the terminal is needed for something else). So as you run more tests, the counter output will end up driving more lines. This behavior should be easy enough to confirm.
As the DAQ card drives more lines, I'd imagine this affects the actual signal. You could scope it to check, but it sounds like either the rise/fall times are becoming longer or some extra noise is being introduced on the line.
The readings are two different frequencies repeated over and over again and none of those frequencies are the expected frequency which was generated out of the "Counter Output."
This implies you are picking up an extra edge during transitions--this isn't too uncommon if the signal is noisy since there is no built-in hysteresis on the DAQ card. I would expect the measured frequencies to have periods that sum to either the full period or the semi-period of your actual signal (depending on how many duplicate edges are detected).
Suggestions are as follows:
To stop the DAQ card from driving multiple PFI lines, it would probably be easiest to just programmatically reset the device in between your tests (using DAQmx Reset Device). If you can't reset the device (e.g. because you are running some other task that can't be interrupted) then you can instead configure a dummy task that uses the PFI line in question as an input.
To stop the DAQ card from picking up multiple edges during transitions, you should configure a digital filter on the input terminals. If you reset the device it sounds like this might not be necessary... it's up to you if you want to configure this or not.
Best Regards,
John Passiak

How to filter starttrigger on counter output precisely

HW PCI6602
Measurement studio 2008 (C#)NI-DAQmx 9.02I’m trying to trig a camera using the output from a counter.
The camera should be trigged when the counter input pulse width is larger than approx (filterPulseWidth 10us).To do this a have set up the following tasktask.COChannels.CreatePulseChannelTime(counter, "TriggerTaskChannel", COPulseTimeUnits.Seconds, COPulseIdleState.Low, 0, 80E-6, 0.007); task.Triggers.StartTrigger.Type = StartTriggerType.DigitalEdge; task.Triggers.StartTrigger.DigitalEdge.Edge = DigitalEdgeStartTriggerEdge.Rising; task.Triggers.StartTrigger.Retriggerable = true;task.Triggers.StartTrigger.DigitalEdge.DigitalFilterMinimumPulseWidth = filterPulseWidth; task.Triggers.StartTrigger.DigitalEdge.DigitalFilterEnable = true;Unfortunatly this filter has the following behaviour”If the period of the filter clock timebase is tfltrclk, this filter guarantees topass pulse widths that are 2*tfltrclk or longer and to block pulse widths thatare tfltrclk or shorter. A pulse with a width between these two ranges may ormay not pass, depending on the phase of the pulse with respect to the filterclock timebase”.It means that I have no sharp distinction on my filter as one would when applying a filter to an ordinary pulse width measuring task. Implementing this with via the software in a callback is to slow.The bottom line is that I would like to generate a pulse on my counter output when the trigger/counter input is greater than say 10us. The output pulse could be predetermind as in the sample code above or as long as the filtered input (I.e counter just pass filtered input to my output).How can this be done? BR
Jongas
Solved!
Go to Solution.

Hi Jongas,
Is it OK if the trigger is sent once the pulse hits 10 us, rather than
on the exact falling edge? I'll assume the exact timing isn't as important, but you would like the trigger to occur very close to the falling edge (within a couple of us). The important thing is that we trigger as close as possible to when the PWM has hit 50% duty cycle.
Some brainstorming:
Digital Filtering on the 660x Isn't the Best for This:
Digital filtering might not be as practical here on your 6602 due to the region of uncertainty between 5 and 10 (or 10 and 20) us pulses. The TIO boards count two consecutive edges of a filter clock to determine when to pass a signal through so the guaranteed rejected pulse width is always half of your guaranteed passed pulse width (providing an external filter clock timebase that is synchronized with your external signal could potentially reduce this uncertainty but I honestly haven't tried this before and I would imagine it is not going to be very straightforward).
X Series Alternative:
Our X Series devices use a different method of digital filtering that would work better for you. If a hardware change is an option (and you can use PCIe) then you might consider this. You could use the 20 MHz timebase as your filter clock timebase and could guarantee to pass 10 us (200/20M) and reject 9.95 us (201/20M). The 6320 is currently our lowest cost X Series board. A couple of points about this solution:
1. To configure the PFI filter, you need to use some sort of dummy task to
access the property nodes. Here is an
example of this (although it is written in LabVIEW).
2. You can route the filtered PFI signal to be exported on another PFI line, but this will reserve Counter 3. This is documented in the Device Routes tab of Measurement and Automation Explorer.
3. The filtered output will be 9.95-10 us delayed from the input signal, so you could trigger the camera off of the rising edge of the filtered output directly and be fairly close to the actual falling edge.
External AND Gate Alternative:
You could configure a Counter Output to generate a re-triggerable pulse with a 10 us initial delay (to be triggered off of the rising edge of your PWM signal). Assuming the pulse is short enough to complete before the next period of your PWM signal, the counter output would only be high at the same time as the PWM signal if the signal was longer than 10 us. Use the external AND gate to combine these two signals and the result would be the trigger for your camera (the rising edge would correspond to 10 us after the PWM signal first goes high).
If you wanted to you could make the counter output pulse a little longer (say 8 us) and trigger the camera off of the falling edge out of the AND gate (a.k.a. rising edge out of a NAND gate) which would line up with the exact falling edge of the PWM signal. Don't make the CO pulse too long or it will overlap with the next period of the PWM.
Another Idea:
One idea that I keep coming back to is to use the internal rollover event of a counter input task (a pulse is generated whenever a counter rolls over on its Internal Output which can be routed to a PFI line). I don't think this will work, but the idea in theory would be to:
1. Set Default state to known value (e.g. 2^32-200).
2. Gate the Counter so it only counts during the time PWM is high. Have it count the 20 MHz timebase.
3. Reset the Counter to default state on the falling edge of the PWM signal.
4. The counter would rollover if 200 pulses occurred of the 20 MHz timebase (10 us), and the Counter Output could be routed to a PFI line to trigger the camera.
The problem is that there is no good way to reset the counter except for an encoder measurement (Kevin has already made a nice suggestion about this). A Pulse Width Measurement would technically reset the counter, but you cannot currently set the default value of a Pulse Width Measurement task so there is no way to make the rollover happen prematurely).
Configuring an encoder measurement and working with the multiple counters on the 6602 to produce appropriate A,B, and Z signals might be a method to look into further, but at this point I think you'd be better off with an external AND gate.
I don't want to say it's impossible with just the 6602, but I can't think of a straightforward way to go about it without external hardware (although maybe I can sleep on it and think of something later... how many counters do you have to work with?).
With your current NI Hardware, I think your best bet is to go with an external AND gate. If you're planning on purchasing an X Series card the digital filtering idea is actually not a bad way to go.
I hope this is helpful!
Best Regards,
John Passiak

How to Immediately Change Counter Output Rate?

I have a piece of code that largely works like this example: http://zone.ni.com/devzone/cda/epd/p/id/5493
In other words, I set up the Counter Output with some initial frequency and duty cycle, but then during the main loop of my program I continuously change the frequency to a new value based on other criteria.
I'm using an M-series PXI card and LabVIEW RT.
The problem I'm having is that the card waits for the next edge before changing the counter output rate. For instance, lets say it is going at a low frequency and I am upping to a high frequency. If the command arrives in the middle of the current pulse, it will wait to complete the low-rate pulse before starting the high frequency output. Is there a way to make it interrupt the current count and immediately start counting at the new rate?
Thanks,
Isaac

Hi Isaac,
I posted the code in LV 8.2 so you should be able to open it now (it sometimes takes several minutes to upload).
There are a few limitations to using the digital lines instead of the counters:
1. The digital lines are updated off of a sample clock which will be much slower than a timebase. For example, on the 6221 the maximum update rate is 1 MHz, while the counter output has a max timebase of 80 MHz. As a result, the number of frequencies you can generate are going to be more restricted (divide down from 1 MHz vs. 80 MHz).
2. On M series devices, the digital lines must be clocked from an external source. This could be generated from a counter
3. You have to build the digital waveform, which is a bit tricky (I think the example code should help out with that but I haven't had time to thoroughly test it).
4. If you are generating digital lines at fast rates, you will need to write quite a few samples at a time to the output buffer to ensure the data does not underflow. If the buffer includes multiple periods of the digital signal, you would have the case that using the counter output would still update more immediately.
Again, to determine the best course of action it would be useful to know what frequencies you want to generate and which exact hardware you are using. I just mentioned the digital lines as an alternative to the counters, but it might not be ideal for your situation.
-John
John Passiak

Display counter output on graph

I have two counters generating continuous digial pulse trains from my PCI 6010, and I'm trying to display the output on a graph. I've got the output of one counter connected to an AI line that leads to a waveform graph, but I can't get anything on the graph. I've measured the output via external means, so I know the counters are generating the appropriate pulses.
Eventually I'd like to have some sort of indicator for each counter that indicates whether the counter is in the 'on' or 'off' state, but I figured getting the counter outputs to diplay on a graph would be a good first step.
My VI is below; the display part that isn't working is at the bottom of the case structure.
Thanks.

Once your code goes into the inner while loop your graph will never be updated since it will only execute one time. In order to update the graph continually you will need a parallel which handles the graph updates. A good way to pass data between the parallel tasks is a queue.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

"loopback" counter output without wiring

Cross posted from another forum for more visibility:
Basically, I have a counter output being generated on a trigger line. It's just a pulse at defined intervals of 1 hz. The problem is, the card that is generating the output needs the trigger itself, but if it is using the trigger line to output the trigger itself, it can't read it. I know I can get around this with a timing and synch card, and possibly with external wiring, but is there any way to do this all in the backplane?
In summary, can I have a AO card generating a counter output on a trigger line use that output as a trigger for itself in some way, without extra wiring or a 6672 card?
CLA, LabVIEW Versions 2010-2013

Jeff·Þ·Bohrer wrote:
Greg,
What are you really triing to do? your post is a bit more cryptic than usual.
My instinct says "a single board RIO" would do the trick. but, that's a lot of capability to throw at a simple PFIO line. What did you get yourself into this time?
NO NO NO. No sbRIO. Did NI pay you to help market now?!
All I want to do is have a digital pulse, which I can use as a start trigger for ALL my AI and AO. Some tasks stop and restart while others keep running continuously. When the select tasks restart, they need to sync back up with the continuously running tasks, and they do so by using this start trigger again. This is not a clock sync, think of it like a "wait until next ms multiple." I resolve this by having a digital pulse happening every "x millseconds" which I use as my start trigger. If a task restarts, it will again wait for this pulse.
The problem is, if I am generating this trigger on PXI1Slot12/PXI_trig0, I cannot also trigger off of this trigger line in slot 12.
CLA, LabVIEW Versions 2010-2013

How to copy, rather than export, a Counter output?

Hi,
In DAQmx (in C++), using an E-Series board, I have exported a Counter output to an RTSI line. This works fine. However, perhaps to be expected, the signal disappears from the Ctr0 output. For debugging and logging purposes, I would like to retain a copy of the original Counter pulse, while Exporting it to the RTSI line.
Is there a way to copy, say, a control signal? i.e. set up a 1-to-2 terminal routing?
Specifically, I want /Dev/Ctr0 to still be accessible on PFI6 and the SAME signal to be copied/routed/exported to an RTSI line.
Thanks for any advice.
- Per

Hi Per,
Yes, you can do this using DAQmx connect terminals.
int32 DAQmxConnectTerms (const char sourceTerminal[], const char destinationTerminal[], int32 signalModifiers);
You can locate this in the DAQmx C reference help by searching "route terminals".
Regards,
Greg H.
Applications Engineer
National Instruments

Counter output becomes unsnchronized when gated with an other counter

Dear all
i'm using a PCI-6602 to generate a range of different pulse trains / retriggered pulses. Ctr0 is running at the experiments base frequency (T0) and is configured like this:
Error = DAQmxCreateCOPulseChanTicks(T0TaskHandle, "Dev1/ctr0", "", "20MHzTimebase", DAQmx_Val_Low, 0, T0Low, T0High);
Error = DAQmxCfgImplicitTiming(T0TaskHandle, DAQmx_Val_ContSamps, 0);
A second counter (Ctr2) produces pulses synchronized with T0 but with n times longer period:
Error = DAQmxCreateCOPulseChanTicks(BlockTaskHandle, "Dev1/ctr2", "", "20MHzTimebase", DAQmx_Val_High, 0, BlockLow, BlockHigh);
Error = DAQmxCfgImplicitTiming(BlockTaskHandle, DAQmx_Val_ContSamps, 0);
Error = DAQmxCfgDigEdgeStartTrig(BlockTaskHandle, "/Dev1/Ctr0InternalOutput", DAQmx_Val_Rising);
A third counter (Ctr3) produces retriggered pulses from Ctr2 that will serve as a gate for the 4th counter output:
Error = DAQmxCreateCOPulseChanTicks(BlockEnableTaskHandle, "Dev1/ctr3", "", "20MHzTimebase", DAQmx_Val_Low, 0, BlockEnableLow, BlockEnableHigh);
Error = DAQmxCfgDigEdgeStartTrig(BlockEnableTaskHandle, "/Dev1/Ctr2InternalOutput", DAQmx_Val_Rising);
Error = DAQmxCfgImplicitTiming(BlockEnableTaskHandle, DAQmx_Val_FiniteSamps, 1);
Error = DAQmxSetStartTrigRetriggerable(BlockEnableTaskHandle, true);
Ctr4 should now output pulses at the frequency of Ctr0 but only when Ctr3Out is high. I tried along the lines of:
Error = DAQmxCreateCOPulseChanTicks(TriggerTaskHandle, "Dev1/ctr4", "", "20MHzTimebase", DAQmx_Val_Low, 0, TriggerLow, TriggerHigh);
Error = DAQmxCfgImplicitTiming(TriggerTaskHandle, DAQmx_Val_ContSamps, 0);
Error = DAQmxSetPauseTrigType(TriggerTaskHandle, DAQmx_Val_DigLvl);
Error = DAQmxSetDigLvlPauseTrigWhen(TriggerTaskHandle, DAQmx_Val_Low);
Error = DAQmxSetDigLvlPauseTrigSrc(TriggerTaskHandle, "/Dev1/Ctr3InternalOutput");
This works in terms of gating, but the gated pulses are no longer synchronized with the Ctr0 (they "move" through the gate when looking at it on an oscilloscope).
DAQmxCfgDigEdgeStartTrig does not work for Ctr4 as it is not possible to use start and pause in the same task (at least that's what the error message said).
I tried to synchronize using:
Error = DAQmxSetArmStartTrigType(TriggerTaskHandle, DAQmx_Val_DigEdge);
Error = DAQmxSetDigEdgeArmStartTrigSrc(TriggerTaskHandle, "/Dev1/Ctr0InternalOutput");
Error = DAQmxSetDigEdgeArmStartTrigEdge(TriggerTaskHandle, DAQmx_Val_Rising);
which works if i uncomment the three PauseTrig lines (no more drifting pulses, but no gating either). Using it all together produces no errors but the gated pulses still walk through the gating window.
Any help is deeply appreciated
Best regards
Christian

Hello Wolfgang
thank you for your reply. I finally managed to get the 6602 to do what i want it to. The key was to use
Error = DAQmxSetDigEdgeArmStartTrigSrc(TriggerTaskHandle, "/Dev1/Ctr2InternalOutput");
instead of
Error = DAQmxSetDigEdgeArmStartTrigSrc(TriggerTaskHandle, "/Dev1/Ctr0InternalOutput");
and to make sure that Ctr4s task was started after the tasks of Ctr0 and Ctr2.
Now Counter 4 is pulsing at the frequency of Ctr0 (even with selectable delay and pulse width) but only when Ctr3Out is high without the need for an external AND gate or other hardware.
Best regards
Christian

Counter output, on demand

I'd like to have a counter output a single pulse whenever a condition occurs within a loop. My current solution (in pseudocode; I use LabWindows CVI on a RT target) looks like this:
DAQmxCreateTask(...);
DAQmxCreateCOPulseChanTime(...);
while (true)
if (condition)
t1 = Timer();
DAQmxStartTask(...);
t2 = Timer() ;
DAQmxErrChk (DAQmxWaitUntilTaskDone(*th,2));
DAQmxErrChk (DAQmxStopTask(*th));
DAQmxClearTask(...);
Unfortunately, the delay between t1 and t2 is at least 0.142ms, and sometimes 2ms. Is there an elegant way to decrease this and not having to call StartTask again and again?
Thanks,
Jonas
Jonas Zimmermann, PhD
Neuroscience Department
Brown University
Solved!
Go to Solution.

Try explicitly starting the triggerTask before the loop and set auto start on the write call to FALSE (it's the 3rd input). This should make a big difference.
Situational: You might want to split up the write call--set the line high when you need to send the trigger (assuming this is the time-critical portion of the code) and re-arm the trigger by setting the line low whenever you have time to spare later on. Overall you'll probably end up taking up more time with 2 calls vs 1 but I'd expect each individual call should take less time so it might be advantageous to split this up and make the calls on your own terms.
EDIT: You might also try enabling memory mapping on the digital output task (call DAQmxSetDOMemMapEnable before starting your task). It might not be supported on your device though (you didn't mention which device you are using).
I'm still not sure how this will compare to just outputting the counter directly--I thought it would have been faster but then again this probably varies quite a bit across different product lines and different busses.
Best Regards,
John Passiak

Synchronize two counter outputs on 6071E card

Well, it's the usual how do I synchronize two counters problem.
I'm using the 6071E with DAQmx .NET 4.0. I define a Task and attach to it two counter output channels with implicit timing and zero initial delay . When running the program
I catch the first edge with a scope single trigger. There is always a delay between the first edge of ctr0 and the first edge of ctr1 of 16.3 microsecs. Is there a way, besides setting the initial delay of ctr0 to 16.3 microsecs, to make the counters to always start together? what is the source of the delay(software/hardware) and should it always stay constant.
any help is welcome
Solved!
Go to Solution.

The source of the delay is that despite being in the same tasks the counters are still started sequentially by software. I'm surprised the delay you are seeing is constant.
If you want the counters to start together you should configure a start trigger. Once you start the counter tasks in software, issue the start trigger to begin generating your output pulses. The start trigger must be a hardware signal--as an example you might configure a software-timed digital output and wire it back in to one of the PFI lines.
If you want to avoid any additional wiring, you could split the counters into two separate tasks. Trigger one counter with the internal output of the other (start the task that is going to be triggered first). Doing this instead of using an external trigger, I would expect an additional delay between the counters on the order of 100 ns as the initial delay is at minimum 2 timebase ticks.
Best Regards,
John Passiak

Two counter inputs and counter output NI 9401

I am trying to configure two counter inputs and one counter output on one NI 9401. I have looked and found how to configure digital lines in booth directions but it seems like I can only do two counters in all on one module. Can someone verify this for me or let me know how to get all three on to one module?
Thank you

Hi mschoenwald,
The counters are actually located on the backplane of whatever chassis you are using--I'll assume you are using cDAQ and not cRIO.
If you have the older <link no longer exists>, then there are only 2 counters available in general. You can access both from a single parallel (8 lines or less) digital module in slot 5 or 6 of the chassis.
The 2nd generation Compact DAQ chassis (including 9174, 9178, 9181, 9188, etc.) includes 4 counters. You may access them from any slot with a parallel module. There is no restriction preventing you from accessing all 4 simultaneously from a single module.
The 9401 is bi-directional and configurable by nibble (line0:3 may be configured one direction, and line4:7 another). However, it is quirky in that it requires the line direction to be configured before any of the tasks are started. This is because the data lines themselves are used to set the line direction behind the scenes. The best way to work around the behavior is to use DAQmx Control Task to explicitly reserve your tasks before any of them are started (see here). Keep in mind that the counter output should use the opposite nibble from the two counter input tasks.
Best Regards,
John Passiak

VPN Client disconnection from command line

Hi,
I want to connect to IPsec VPN on ISA500 by VPN Client (v 5.0.07.0440, the last version, I think), using command line parameters.
I can connect with the command:
"%programfiles%\Cisco Systems\VPN Client\ipsecdialer.exe" -c -user myUser -pwd myPassword "MyConnectionEntry"
but i don't know the command to disconnect from command lines.
If I do
"%programfiles%\Cisco Systems\VPN Client\ipsecdialer.exe" -?
I obtain the list of parameters
vpngui [-c | -sc [sd] [-user <username>] [-pwd <password> ! -eraseuserpwd]] <connection entry>
but I don't unterstand what I have to do... I try every combination using -sd parameter (I think means for silent disconnect), but in every case I can only to show VPN interface without disconnect anything...
Can anyone help me?
Thanks

Prasath,
This appears to be a data flow issue. You need to look in the dataflow log file. Your information indicates the project name is SAMPLES.xml, and the data flow ID is D20091213_014350765. Look at the data flow log file in
C:\dqxi\11_7\repository\configuration_rules\runtme_metadata\project_SAMPLES\D20091213_014350765
Alternatively, you can temporarily replace the transactional reader and writter transforms with their corresonding batch transforms, and run the job from the Project Architect. Any errors will be displayed in the Running window.
Paul

How to give delay in switch on digital output lines

Hello All,
I am working on PCI-6514 Digital IO card, I am writing a sequence to my application using DAQmax for Digital input and output lines
I want to switch on one output line0 and after a delay 5sec switch on line1 output and after a delay of 3sec switch on line2 output and sense input line 0 and line 1 .
How can we know the status of output ie output is on or off.
Since i am using the IO card for first time suggest me in this.

Hi
I am going to assume that you are using LabVIEW 7.1 for this application. If you are trying to acquire data from an external device after outputting data to that device, the DAQmx tristate property node will give you this functionality.
You will then need a DAQmx write.vi to output your digital data followed by a DAQmx channel property node. Select Digital Output>>Tristate on the property node and wire a true constant into it. After the property node, you can use a DAQmx read.vi to read the data coming into the digital lines. By using the tristate property node, you can avoid stopping the digital output task and starting an entirely new task. I am attaching an example program that will demonstrate this.
Regards,
Hal L.
Attachments:
digital input and output.vi ‏39 KB

I am using NIPCI6229 card i want to generate 5 V in the digital ouput line . it has to be there in the output line only for 100ms please help me

i am using NIPCI6229 card i want to generate 5 V in the digital ouput line . it has to be there in the output line only for 100ms please help me. aftwer 100ms it has to go to zero state

hi,
You can try generating 5V continously for 100ms in a loop later on you can make it low.
Hope this helps you.

Disconnect counter output line

Similar Messages

Maybe you are looking for