Confusion abt event count

hi all i have a confusion abt the event count value for the signatures.
say if i set the event count value to 5 then the signature will fire only if the event ocours 5 times right.
does it mean that when the first time the attack packet comes the signature is not fired and the action is not taken. the signature action is taken only if it hits 5 times.
is this what it means. and will the event be written to the event store.
can someone pls clarify this doubt.
regards
sebastan

Event action rules are a group of settings you configure for the event action processing component of the sensor. These rules dictate the actions the sensor performs when an event occurs
http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_chapter09186a00803eb027.html

Similar Messages

  • Help need on the event count parameter of signatures

    hi all i have a little confusion abt the event count parameter in the signatures.
    i am not sure whether this parameter is for firing the signatures or for writing the events to the event store.
    by default the event count is set to 1.
    if i set the event count to 5 for a particular signature.
    say for icmp echo request. if i set the signature event count to 5 within 10 seconds interval. and the signature action is to deny the packet inline.
    then when the first icmp echo request is send will the signature be fired i mean will the packet be dropped.
    or the packet will be dropped only if 5 icmp echo requests are send within 10 seconds.
    can someone pls clear my doubt.
    regards
    sebastan

    You can configure the sensor as like you want the sensor to send an alert only if the same signature fires 5 times for the same address set. This is how the event count works.
    http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_chapter09186a00803eb031.html#wp1049108

  • Variant "_$$audit-event-count" has not been declared in the current scope.

    I migrated my bpel process manager from Version 2.1.2 [oc4j linux] to 10.1.2.0.0 [using jboss as application server].
    The orabpel schema for 10.1.2.0.0 seems to be a bit different.
    I installed the new schema and then dumped all the data from my previous schema. I also successfully deployed the 2.1.2 processes onto 10.1.2 version.
    I can initiate a new instance of the process, however , the previously completed instances or not completed instances fail with the following error,
    16:28:06,061 INFO [STDOUT] <2006-01-31 16:28:06,061> <ERROR> <default.collaxa.cube> <BaseCubeSessionBean::logError> Error while invoking bean "instance manager": Variant not found.
    The variant "_$$audit-event-count" has not been declared in the current scope. All variants must be declared in the scope before being accessed.
    Any advice is greatly appreciated. Thanks.

    JScript is JavaScript.
    Ah, now there's part of the confusion :)
    If you're asking about a Windows Script Host (WSH) script, you don't have to declare stdin because it's part of the host.
    Ok... So if I understand you correctly, I'm actually programming in J(ava)Script on windows for WSH. Simply trying to call ReadLine fails as well, as it is not defined according to the compiler.
    Be specific: What are you trying to do? Tell what you want to do, not
    how you think it needs to be done.
    which brings me to my current issue: attempting to ReadLine() (in order to get the program to pause for a moment, from
    this example)
    I know I put up a pretty big wall of text back there, sorry about that.
    EDIT: Well, I think I've learned
    about J*script. It sounds like JScript and Javascript are more just versions of ECMAScript.

  • Event counter using USB-6210 analog

    Hi,
    Any suggestions or directions where to look to generate a VI that would record event from a magnetic counter of a mouse wheel. I would like to record up to 16 wheels using the USB-6210 device. Thanks!
    VO2max

    Thanks for the extra information.
    The 6210 actually has two counters, so you could count the edges (on two of the wheels) if the signals are TTL compatible.  You can use the Count Digital Events.vi example to help you get started.  From LabVIEW, it can be found at:
    Help » Find Examples... » Hardware Input and Output » DAQmx » Counter Measurements » Count Digital Events
    If your signals are TTL compatible, I would highly recommend purchasing a PCI-6602 and using this method for all 8 channels.  You could modify the example code by increasing the delay (software-timed sample rate) to a larger value (say 1 minute), and logging the results to a file as you run.  Doing this would log the value of the event counter every minute, and would keep the file size relatively small (about 15kB if you run for 8 hours).
    If you must use a single 6210 and require all 8 channels, the only option would be to use continuous analog inputs.  You would have to sample at a high enough rate to not skip the pulses (I am not sure what that is without knowing more about the signal), and then process the digitized signal in software to determine the information that you need.  I would use the Producer/Consumer design template in conjunction with a continuous analog input example to get started.  In the consumer loop, you would have to implement the functionality of the counter in software.
    Using a hardware counter would be preferrable to using analog inputs.  The counter is made for exactly this type of task, and implementing it in software can be complicated as well as processor intensive.  If you have any questions let me know, I'm happy to help you out.  You can always try out the counter task on the 6210 for two wheels to see how it will work before deciding whether or not to purchase a new board.
    -John 
    P.S. After your first post I had assumed that you were testing computer peripherals, but it looks like you actually have eight rodents.  We had a good laugh over here over my confusion.
    John Passiak

  • Buffered event counting. Why can't I explicitly sequence generating the Sample Clock Pulse and reading the counters?

    At irregular occasions I need to grab counts from several counters, and buffering the counts must be done simultaneously for all counters. I'm modeling my approach after zone.ni.com/devzone/cda/tut/p/id/5404 which someone kindly pointed out in an earlier thread. However, that example only uses one counter, and you can't test the synchronization with only one counter, so I am using two counters configured the same way, and they're wired to a single benchtop signal generator (for example at 300 kHz).
    What I want to do, I can test in a loop with a somewhat random wait in it. I want to drive a hardware digital output line high for a few ms and then low again. The hardware line is physically connected to terminals for my timing vi's Sample Clock Source and so will cause them to buffer their counts for later reading. After I pulse this line, when I know new good buffered counts await me, I want to read both my counters. If their bufferings are simultaneous, then each counter will have counted the same number of additional counts since the last loop iteration, which I can check by subtracting the last value sitting in a shift register and then subtracting the two "additional counts" values and displaying this difference as "Diff". It should always be 0, or occasionally +1 followed immediately by -1, or else the reverse, because buffering and a count could happen practically at the same moment.
    When I do this using a flat sequence to control the relative timing of these steps, so the read happens after the pulse, the counters often time out and everything dies. The lengths of time before, during, and after the pulse, and the timeout value for the read vi, and the size of the buffer and various other things, don't seem to change this, even if I make things so long I could do the counting myself holding a clipboard as my buffer. I've attached AfterPulse.vi to illustrate this. If I get 3 or 10 or so iterations before it dies, I observe Diff = 0; at least that much is good.
    When I use two flat sequences running in parallel inside my test loop, one to control the pulse timing, and the other to read the counters and do things with their results, it seems to work. In fact, Diff is always 0 or very occasionally the +/- 1 sequence. But in this case there is nothing controlling the relative timing such that the counters only get read after the pulse fires, though the results seem to show that this is true. I think the reads should be indeterminate with respect to the pulses, which would be unreliable. I don't know why it's working and can't expect it to work in other environments, can I? Moreover, if I set some of the pulse timing numbers to 1 or 2 or 5 ms, timeouts start happening again, too. So I think I have a workaround that I don't understand, shouldn't work, and shouldn't be trusted. See SeparateSequence.vi for this one.
    I also tried other versions of the well-defined, single sequence vi, moving the counter reads to different sequence frames so that they occur with the Sample Clock Source's rising edge, or while it is high, or with the falling edge, and they also often time out. I'll post these if anyone likes but can't post now due to the attachment limit.
    Here's an odd, unexpected observation: I have to sequence the reads of the counters to occur before I use the results I read, or else many of the cycles of this combine a new count from one counter with the one-back count from the other counter, and Diff takes on values like the number of counts in a loop. I though the dataflow principle would dictate that current values would get used, but apparently not so. Sequencing the calculations to happen after the reads fixes this. Any idea why?
    So, why am I not succeeding in taking proper control of the sequence of these events?
    Thanks!!!
    Attachments:
    AfterPulse.vi ‏51 KB
    InSeparateSequence.vi ‏49 KB

    Kevin, thanks for all the work.
    >Have you run with the little execution highlighting lightbulb on? -Yes. In versions of this where there is no enforced timing between the counter and the digital line, and there's a delay inserted before the digital line, it works. There are nearly simultaneous starts on two tracks. Execution proceeds directly along the task wire to the counter. Meanwhile, the execution along the task wire to the digital high gets delayed. Then, when the digital high fires, the counter completes its task, and execution proceeds downstream from the counter. Note, I do have to set the timeout on the counter longer, because the vi runs so slowly when it's painting its progress along the wires. If there is any timing relationship enforced between the counter and the digital transition, it doesn't work. It appears to me that to read a counter, you have to ask it for a result, then drive the line high, and then receive the result, and execution inside the counter has to be ongoing during the rising line edge.
    >from what I remember, there isn't much to it.  There really aren't many candidate places for trouble.  A pulse is generated with DIO, then a single sample is read from each counter.  -Yup, you got it. This should be trivial.
    >A timeout means either that the pulse isn't generated or that the counter tasks don't receive it. - Or it could mean that the counter task must be in the middle of executing when the rising edge of the pulse arrives. Certainly the highlighted execution indicates that. Making a broken vi run by cutting the error wires that sequence the counter read relative to the pulse also seems to support that.
    >Have you verified that the digital pulse happens using a scope? -Verified in some versions by running another loop watching a digital input, and lighting an indicator, or recording how many times the line goes high, etc. Also, in your vi, with highlighting, if I delete the error wire from the last digital output to the first counter to allow parallel execution, I see the counter execution start before the rising edge, and complete when the line high vi executes. Also, if I use separate loops to drive the line high and to read the counter, it works (see TwoLoops.vi or see the screenshot of the block diagram attached below so you don't need a LV box). I could go sign out a scope, but think it's obvious the line is pulsing given that all these things work.
    >Wait!  I think that's it!  If I recall correctly, you're generating the digital pulse on port0/line0...  On a 6259, the lines of port 0 are only for correlated DIO and do not map to PFI. -But I'm not using internal connections, I actually physically wired P0L1 (pin 66) to PFI0 (pin 73). It was port0/line1, by the way. And when running some of these vi's, I also physically jumper this connection to port0/line2 as an analog input to watch it. And, again, the pulse does cause the counter to operate, so it clearly connects - it just doesn't operate the way I think it is described operating.
    For what it's worth, there's another mystery. Some of the docs seem to say that the pulse has to be applied to the counter gate terminal, rather than to the line associated with the sample clock source on the timing vi. I have tried combinations of counter gate and or sample clock source and concluded it seems like the sample clock source is the terminal that matters, and it's what I'm using lately, but for example the document I cited, "Buffered Event Counting", from last September, says "It uses both the source and gate of a counter for its operation. The active edges on the gate of a counter is used to latch the current count register value in a hardware register which is then transferred via Direct Memory Access...". I may go a round of trying those combinations with the latest vi's we've discussed.
    Attachments:
    NestedSequences.png ‏26 KB

  • M-Series Buffered Event Counting with DMA -- gating problem

    Hi --
    I am implementing DMA-based buffered event counting on a PCIe-6259 board.  I use G0_Out as the gate for G1, which counts events on a PFI pin.   So by setting the speed of G0, I get an event count (either cumulative or non-cumulative) on a periodic basis, which is directly DMA'd to my buffer, and synchronized with other i/o operations.
    This is working well right now, except for one problem, which is that the I only get data if there is at least one  source edge between gates.  i.e. if there are no edges, nothing gets pumped to the dma buffer.
    I am guessing that a stale data error is somehow choking off the DMA transfer from the counter.   Is that possible?
    Is there some magic that I need to do to avoid this, because for this application, especially if I am counting cumulatively, I don't care about a missing edge, but I do care if the dma transfers get out of phase with the rest of my timing.
    Thanks in advance for any help!
    --spg
    Here is a snippet of the code that sets up the event counting on G1, partly based on gpctex6.cpp:
    const int sDMASelect[] = {1,2,4,8,3,5};
    // source:  pfi, or -1 for 20Khz clock
    void eventTimerSetup(tMSeries *board, tTIO *tio, int dmaChannel, bool cumulative, int source)
        int sourceSelect = (source==-1) ? 0 : (source+1);
        //MSeries.CTR.Source
        tio->G1_Input_Select.setG1_Source_Select(sourceSe​lect); // (pfi+1) or 20Khz=0
        tio->G1_Input_Select.setG1_Source_Polarity(0); //rising=0
        tio->G1_Input_Select.setG1_OR_Gate(0);
        tio->G1_Input_Select.flush();
        //MSeries.CTR.Gate
        tio->G1_Input_Select.setG1_Gate_Select(20); //the G_OUT signal from other clock=20
        tio->G1_Input_Select.setG1_Output_Polarity(0); //active high=0
        tio->G1_Input_Select.flush();
        //MSeries.CTR.IncrementRegisters
        tio->G1_AutoIncrement.writeRegister(0);
        //MSeries.CTR.InitialCountRegisters
        tio->G1_Mode.writeG1_Load_Source_Select(tTIO::tG1​_Mode::kG1_Load_Source_SelectLoad_A);
        tio->G1_Load_A.writeRegister(0);
        tio->G1_Command.writeG1_Load(1);
        tio->G1_Load_B.writeRegister(0);
        tio->G1_Load_A.writeRegister(0);
        tio->G1_Command.setG1_Bank_Switch_Enable(tTIO::tG​1_Command::kG1_Bank_Switch_EnableBank_X);
        tio->G1_Command.setG1_Bank_Switch_Mode(tTIO::tG1_​Command::kG1_Bank_Switch_ModeGate);
        tio->G1_Command.flush();
        //MSeries.CTR.ApplicationRegisters
        tio->G1_Input_Select.setG1_Gate_Select_Load_Sourc​e(0);
        tio->G1_Mode.setG1_Reload_Source_Switching(tTIO::​tG1_Mode::kG1_Reload_Source_SwitchingAlternate);
        tio->G1_Mode.setG1_Loading_On_Gate(cumulative ? tTIO::tG1_Mode::kG1_Loading_On_GateNo_Reload : tTIO::tG1_Mode::kG1_Loading_On_GateReload_On_Stop_​Gate);
        tio->G1_Mode.setG1_Loading_On_TC(tTIO::tG1_Mode::​kG1_Loading_On_TCRollover_On_TC);
        tio->G1_Mode.setG1_Gating_Mode (tTIO::tG1_Mode::kG1_Gating_ModeEdge_Gating_Active​_High);
        tio->G1_Mode.setG1_Gate_On_Both_Edges (tTIO::tG1_Mode::kG1_Gate_On_Both_EdgesBoth_Edges_​Disabled);
        tio->G1_Mode.setG1_Trigger_Mode_For_Edge_Gate(tTI​O::tG1_Mode::kG1_Trigger_Mode_For_Edge_GateGate_Do​es_Not_Stop);
        tio->G1_Mode.setG1_Stop_Mode(tTIO::tG1_Mode::kG1_​Stop_ModeStop_On_Gate);
        tio->G1_Mode.setG1_Counting_Once(tTIO::tG1_Mode::​kG1_Counting_OnceNo_HW_Disarm);
        tio->G1_Second_Gate.setG1_Second_Gate_Gating_Mode​(0);
        tio->G1_Input_Select.flush();
        tio->G1_Mode.flush();
        tio->G1_Second_Gate.flush();
        //MSeries.CTR.UpDown.Registers
        tio->G1_Command.writeG1_Up_Down(tTIO::tG1_Command​::kG1_Up_DownSoftware_Up); //kG1_Up_DownSoftware_Down
        //MSeries.CTR.OutputRegisters
        tio->G1_Mode.writeG1_Output_Mode(tTIO::tG1_Mode::​kG1_Output_ModePulse);
        tio->G1_Input_Select.writeG1_Output_Polarity(0);
        //MSeries.CTR.BufferEnable
        board->G1_DMA_Config.writeG1_DMA_Reset(1);
        board->G1_DMA_Config.setG1_DMA_Write(0);  
        board->G1_DMA_Config.setG1_DMA_Int_Enable(0);
        board->G1_DMA_Config.setG1_DMA_Enable(1);   
        board->G1_DMA_Config.flush();
        tio->G1_Counting_Mode.setG1_Encoder_Counting_Mode​(0);
        tio->G1_Counting_Mode.setG1_Alternate_Synchroniza​tion(0);
        tio->G1_Counting_Mode.flush();
        //MSeries.CTR.EnableOutput
        //board->Analog_Trigger_Etc.setGPFO_1_Output_Enab​le(tMSeries::tAnalog_Trigger_Etc::kGPFO_1_Output_E​nableOutput);
        //board->Analog_Trigger_Etc.setGPFO_1_Output_Sele​ct(tMSeries::tAnalog_Trigger_Etc::kGPFO_1_Output_S​electG_OUT);
        //board->Analog_Trigger_Etc.flush();
        //MSeries.CTR.StartTriggerRegisters
        tio->G1_MSeries_Counting_Mode.writeG1_MSeries_HW_​Arm_Enable(0);    
        board->G0_G1_Select.writeG1_DMA_Select(sDMASelect​[dmaChannel]);   
        tio->G1_Command.writeG1_Arm(1); // arm it
    Scott Gillespie
    http://www.appliedbrain.com
    scott gillespie
    applied brain, inc.
    Solved!
    Go to Solution.

    Okay, I have it working now.  In addition to your suggested changes, I had to remove the following line:
    tio->G1_MSeries_Counting_Mode.writeG1_MSeries_HW_A​rm_Enable(0);    
    It appears that writing something to MSeries_Counting_Mode causes that register to supersede the Counting_Mode register.  Is that right?
    So code that now works for  me is listed below.
    thanks Tom!
    -spg
    void eventCounterSetup(tMSeries *board, tTIO *tio, int dmaChannel, bool cumulative, int source) // pfi, or -1 for 20Khz clock
    int sourceSelect = (source==-1) ? 0 : (source+1);
    //MSeries.CTR.Source
    tio->G1_Input_Select.setG1_Source_Select(sourceSel​ect); // (pfi+1) or 20Khz=0
    tio->G1_Input_Select.setG1_Source_Polarity(0); //rising=0
    tio->G1_Input_Select.setG1_OR_Gate(0);
    tio->G1_Input_Select.flush();
    //MSeries.CTR.Gate
    tio->G1_Input_Select.setG1_Gate_Select(20); //the G_OUT signal from other clock=20
    tio->G1_Input_Select.setG1_Output_Polarity(0); //active high=0
    tio->G1_Input_Select.flush();
    //MSeries.CTR.IncrementRegisters
    tio->G1_AutoIncrement.writeRegister(0);
    //MSeries.CTR.InitialCountRegisters
    tio->G1_Mode.writeG1_Load_Source_Select(tTIO::tG1_​Mode::kG1_Load_Source_SelectLoad_A);
    tio->G1_Load_A.writeRegister(0);
    tio->G1_Command.writeG1_Load(1);
    tio->G1_Load_B.writeRegister(0);
    tio->G1_Load_A.writeRegister(0);
    tio->G1_Command.setG1_Bank_Switch_Enable(tTIO::tG1​_Command::kG1_Bank_Switch_EnableBank_X);
    tio->G1_Command.setG1_Bank_Switch_Mode(tTIO::tG1_C​ommand::kG1_Bank_Switch_ModeGate);
    tio->G1_Command.flush();
    //MSeries.CTR.ApplicationRegisters
    tio->G1_Input_Select.setG1_Gate_Select_Load_Source​(0);
    tio->G1_Mode.setG1_Reload_Source_Switching(tTIO::t​G1_Mode::kG1_Reload_Source_SwitchingAlternate);
    tio->G1_Mode.setG1_Loading_On_Gate(cumulative ? tTIO::tG1_Mode::kG1_Loading_On_GateNo_Reload : tTIO::tG1_Mode::kG1_Loading_On_GateReload_On_Stop_​Gate);
    tio->G1_Mode.setG1_Loading_On_TC(tTIO::tG1_Mode::k​G1_Loading_On_TCRollover_On_TC);
    tio->G1_Mode.setG1_Gating_Mode (tTIO::tG1_Mode::kG1_Gating_ModeEdge_Gating_Active​_High);
    tio->G1_Mode.setG1_Gate_On_Both_Edges (tTIO::tG1_Mode::kG1_Gate_On_Both_EdgesBoth_Edges_​Disabled);
    tio->G1_Mode.setG1_Trigger_Mode_For_Edge_Gate(tTIO​::tG1_Mode::kG1_Trigger_Mode_For_Edge_GateGate_Doe​s_Not_Stop);
    tio->G1_Mode.setG1_Stop_Mode(tTIO::tG1_Mode::kG1_S​top_ModeStop_On_Gate);
    tio->G1_Mode.setG1_Counting_Once(tTIO::tG1_Mode::k​G1_Counting_OnceNo_HW_Disarm);
    tio->G1_Second_Gate.setG1_Second_Gate_Gating_Mode(​0);
    tio->G1_Input_Select.flush();
    tio->G1_Mode.flush();
    tio->G1_Second_Gate.flush();
    //MSeries.CTR.UpDown.Registers
    tio->G1_Command.writeG1_Up_Down(tTIO::tG1_Command:​:kG1_Up_DownSoftware_Up); //kG1_Up_DownSoftware_Down
    //MSeries.CTR.OutputRegisters
    tio->G1_Mode.writeG1_Output_Mode(tTIO::tG1_Mode::k​G1_Output_ModePulse);
    tio->G1_Input_Select.writeG1_Output_Polarity(0);
    //MSeries.CTR.BufferEnable
    board->G1_DMA_Config.writeG1_DMA_Reset(1);
    board->G1_DMA_Config.setG1_DMA_Write(0);  
    board->G1_DMA_Config.setG1_DMA_Int_Enable(0);
    board->G1_DMA_Config.setG1_DMA_Enable(1);   
    board->G1_DMA_Config.flush();
    // from Tom:
    // The "magic" you need is referred to as synchronous counting mode (or Duplicate Count Prevention in NI-DAQmx).  
    // Try setting G1_Encoder_Counting_Mode to 6 (synchronous source mode) and G1_Alternate_Synchronization to 1 (enabled).
    tio->G1_Counting_Mode.setG1_Encoder_Counting_Mode(​6); // 0
    tio->G1_Counting_Mode.setG1_Alternate_Synchronizat​ion(1); // 0
    tio->G1_Counting_Mode.flush();
    board->G0_G1_Select.writeG1_DMA_Select(sDMASelect[​dmaChannel]);   
    tio->G1_Command.writeG1_Arm(1); // arm it
    scott gillespie
    applied brain, inc.

  • Doing Buffered Event count by using Count Buffered Edges.vi, what is the max buffer size allowed?

    I'm currently using Count Buffered Edges.vi to do Buffered Event count with the following settings,
    Source : Internal timebase, 100Khz, 10usec for each count
    gate : use the function generator to send in a 50Hz signal(for testing purpose only). Period of 0.02sec
    the max internal buffer size that i can allocate is only about 100~300. Whenever i change both the internal buffer size and counts to read to a higher value, this vi don't seem to function well. I need to have a buffer size of at least 2000.
    1. is it possible to have a buffer size of 2000? what is the problem causing the wrong counter value?
    2. also note that the size of max internal buffer varies w
    ith the frequency of signal sent to the gate, why is this so? eg: buffer size get smaller as frequency decrease.
    3. i'll get funny response and counter value when both the internal buffer size and counts to read are not set to the same. Why is this so? is it a must to set both value the same?
    thks and best regards
    lyn

    Hi,
    I have tried the same example, and used a 100Hz signal on the gate. I increased the buffer size to 2000 and I did not get any errors. The buffer size does not get smaller when increasing the frequency of the gate signal; simply, the number of counts gets smaller when the gate frequency becomes larger. The buffer size must be able to contain the number of counts you want to read, otherwise, the VI might not function correctly.
    Regards,
    RamziH.

  • Can't get counter 2/3 working in simple event counting mode for NI6601

    I have been successfully been able to get counter 0 and 1 working in a simple event counting mode. But when I read Software Save register for counter2/3 it gives me garbage values. I am doing register level programming in C.
    This is the algorithm that I follow
    In initialization:
    -> Reset the Counter
    -> Write32( Clock_Config_Reg, 0x00)
    -> Write Load A and LoadB registers
    -> Write to Input Select Register with appropriate values
    -> Write16( Command_Reg, 0x0125);
    Then when I need to read the SW save register value
    -> Write to Command Register  setting the  gi_Arm bit
    -> Reading the SW save register twice
    -> If not equal ,read again
    -> Write to Command Register  disabling the  gi_Arm bit
    This works just fine for counter 0 and 1. But I can't get it working for counter 2 and 3. Are there any other registers I need to set up correctly for counter2/3. Is the default reset values of registers different for counter 2 and 3?
    Any help would be very appreciated
    Thanks

    Hello manisha,
    Is there a particular reason for using register level programming to interact with your DAQ card, rather than the DAQmx driver?  The reason I ask is because we don't support RLP at NI.  There are some manuals that have been developed, such as this one which corresponds to your card, but I am unable to offer any support after that.  If it is necessary that you must use RLP then you should post your question to the DDK forum, as they have more experience in this area.
    Regards,

  • I am using many events structures in my applicatio​n,but i am getting caught in my problems ,can any body tell me abt events programmin​g on time out

    i have extensive gui application ,i am using events ,but i am caught,i want to konw abt events ,there pros and cons,time out ,how to program in time out

    It is unclear as to exactly what you are asking. The event structure is very handy for monitoring front panel activity and performing tasks accordingly. The default event in the event structure is the timeout. In order to set the timeout you just wire the amount of time before timeout (in ms) to the timeout terminal of the structure. You may have tasks that you want to perform at timeout or you may just have an empty case. I strongly suggest using a timeout and putting the case structure in a while loop in order to keep monitoring the events until the loop exit condition has been met.

  • Use your sound card as an oscilloscope, event counter, spectrum analyzer etc..

    If you enjoy using your computer equipment for as much as possible, here is something that I have wondered about for some time ... how easy is it to adapt your good-quality sound card to use it as an audio-range oscilloscope, event counter etc..
    I stumbled across this product last week and it looks quite neat (sorry if this is already well known in this group .. i've been away form some time :-)
    ?Daqarta
    (I have no direct interest or relationship with this company).
    ?- Mitch

    stlarch wrote:Hi, did you install alsa-utils and add alsa to your daemons array in /etc/rc.conf? Also, you need to add yourself to the audio group, #gpasswd -a yourusername audio. The wiki has an article on alsa that should help, or check the beginners guide.
    Yes, of course, alsa-utils is installed (so is alsa-firmware, and alsa-oss). I'm in audio group.
    ewaller wrote:can you post the output of
    cat /proc/asound/cards
    Also, you should have a directory /proc/asound/card0/  Which should have one or more files with names of the form codec#n, where n is a sequential integer starting with 0.  If those files are not hellaciously long, post them here (With code tags).  Otherwise, could you pastebin them and provide a link?
    Edit: fixed typo
    ~ $ cat /proc/asound/cards
    --- no soundcards ---
    The directory /proc/asound/card0 doesn't exist :
    ~ $ lsi /proc/asound/
    total 0
    -r--r--r-- 1 root root 0 Mar 5 12:38 cards
    -r--r--r-- 1 root root 0 Mar 5 12:38 devices
    -r--r--r-- 1 root root 0 Mar 5 12:38 hwdep
    -r--r--r-- 1 root root 0 Mar 5 12:38 modules
    dr-xr-xr-x 2 root root 0 Mar 5 12:38 oss/
    -r--r--r-- 1 root root 0 Mar 5 12:38 pcm
    dr-xr-xr-x 2 root root 0 Mar 5 12:38 seq/
    -r--r--r-- 1 root root 0 Mar 5 12:38 timers
    -r--r--r-- 1 root root 0 Mar 5 12:38 version
    Thanks for helping !

  • Getting 2nd TIO of the PCI6602 to perform buffered event counting via register-level programming

    I got the first PCI6602 TIO to perform buffer event counting using interrupt. However, I could not get the second TIO working. I think I have initialized the proper registers in order to work with the second TIO, i.e.
    1. Addressing all registers of the second TIO at 0x800 offset.
    2. Binding the clock to counter 4-7 (set 0x00200000 to the Clock Configuration register). I am using the internal Timebase_3 clock which is 80MHz.
    3. Tried setting 0x8000 to the Global Interrupt Control register at both its offset location (with 0 offset) and with 0x800 offset (2nd TIO offset location).
    Am I missing something here? I got no interrupts from the PCI bus and I got 0xff
    ff when I tried to read the Status register.

    Al,
    I have been experimenting with the 6602, but I have not been able to see any of the interrupts generated by the counters. I have tried both TC mode and an external signal on a single GATE (G0). The Gi_Status_Register indicates that the interrupts are occuring (appropriately for each mode), but I can't see them on the bus (my interrupt handler is never invoked; cat /proc/interrupts shows 0 interrupts).
    Could you pass along any tips on how you did it?
    Thanks!
    -Rob

  • Want to trigger event count from both counters (E) to buffer using FOUT (100kHz/16 or slower) as a trigger

    We are using a AT-MIO-16E-1 board. We would like to run an xy raster pattern from the buffer (AO) in order to reduce scan times (256 x 256 pt images). At each AO (voltage) point we would like to read from both onboard counters and store the number of events counted to memory, reading out the buffer say every 256 pts (1 scan line). In order to ensure accurate counting periods the counters need to be triggered to coincide with some "dwell time" at each AO voltage pt. We have thought of using FOUT for the trigger or perhaps out analog out scanning signal but are concerned that the FOUT freq is too high (6250 khz - we would like 100hz-10khz). Any suggestions or e
    xamples would be appreciated.

    Hello;
    The main problem there is going to be the counter triggering. I'm saying that because, there isn't a way for the Analog Input operation to send pulses that will trigger of the timer operation at multiple voltage levels. The only solution for this I can think of is, instead of having an analog voltage level which would indicate the position of xy, if you could have a device which would give a TTL pulse instead when the desired position is reached, then you could use the 6601 to have a triggered operation at the counter. Another constraint for your application right now is the fact that the E-series boards' counters don't have triggering features, only gated features.
    Anyway, you would need to have a TTL pulse either to trigger (in case of the 6601 count
    ers) or to gate (in case of the E-series board), when the desired XY position is reached.
    Meanwhile, you can refer to the Labview examples for Streaming to disk, Analog I/O and counter operations. You can go to Search Examples->I/O Interfaces->Data Acquisition->Data Logger ( for streaming to disk operations); Search Examples->I/O Interfaces->Data Acquisition->Analog Output ( for Analog Output Operations); and Search Examples->I/O Interfaces->Data Acquisition->Counters (for counter operations). Also; I'm including an Application Note which talks about synchronization of multiple DAQ tasks I think will be helpful for you also.
    Regards.
    Filipe
    Attachments:
    Advanced_Sync_Techniques_for_DAQ.pdf ‏189 KB

  • Buffered event counting: migration from E/M series to NI-USB 6210

    Hello,
    I create a project developed in LabWindows CVI that does buffered event counting.
    The project ran on E/M series for a year. Now I have to migrate to NIDAQ-USB and precisely NI-USB-6210 (that is a M-series). The problem concerns reading acquired samples. The buffered event counting that I need is performed in this way:
    1) Start a buffered event counting task
    2) After n seconds, read the number of samples and read the samples
    3) Stop the task
    This procedure works fine on E/M series on PCI bus, but it does not work with NI-USB. With NI-USB, the number of samples is always 0. I link a project that demonstrates that (the "after n seconds" clause is simulated by pressing "stop" key).
    After many tries, I saw that the problem is in reading number of samples and so I modified the sequence of operation in this way:
    1) Start a buffered event counting task
    2) After n seconds, try many times to read the number of samples
    3) Read the samples
    4) Stop the task
    After some houndreds of attempts, the number of samples moves from 0 to the correct number of samples...It seems a bad working....And I don't know after how many attempts I can surely assert that no samples effectively "crossed" card input....
    Is there an error in my procedure? Have I made some incorrect operations? Or maybe is there a inconsistency in NIDAQmx driver?
    Attachments:
    Provausb.zip ‏463 KB

    Hello Luca,
    I changed the code a bit and I found something interesting about your situation; in the attached VI there is your CVI project modified as follows:
    After the Stop button hes been pressed, and the corresponding callback function is called, we read the acquired samples two times: the first one we ask for 1 sample only. This allows to avoid the USB transfer mechanism issue and then, with the second read function it is possible to get all the remaining samples acquired (selecting -1 as "number of samples to read");
    Hope this helps you,
    Best regards
    Fabio Mussi
    P.S. A SR request about this problem has been opened too. If you need more information, call me at 02-41309217;  
    Fabio M.
    National Instruments
    Embedded & OEM Systems Engineer
    Attachments:
    Provausb_modified_2.zip ‏471 KB

  • Gated event counting for a finite time

    I am using a PCI 6110 card for gated photon counting. The digital signal is coming from a single photon counting module, which generates a single TTL pulse upon receiving a photon.  It also generates ~100 dark count /sec.  To get rid of the dark counts, I use gate pulses with very small duty cycle.  In this way, the dark counts are suppressed.  I want to operate for a fixed time interal with a resolution of ~1ms.  My gate pulses are at 800kHz.  Their duration is on the order of 10ns. Is there a way that I can perform gated counting for only 10000 gate pulses?  Thanks.

    Hi UMeng,
    Your question stirred up an interesting discussion at the office.  You can't do gated, buffered counting as the gate input is used to trigger the latch to the buffer.  We came up with a couple of ideas here, but neither are perfect.  It is important to also consider that you are running right at the specifed minimum pulse durations for the gate and source pulse durations for the 6110, which is 10 ns. 
    NI PCI-6110/6111 Specifications
    http://digital.ni.com/manuals.nsf/websearch/A9694D34EF10469386256E3000539747
    With that in mind, you could use an external high speed AND gate to generate a signal for a simple event counter to read using the laser gate and the photon detector output as input to the AND gate.
    Otherwise, you could try doing gated event counting on the signal and simple event counting on the gate as long as the gate frequency is consistent.  Then you could use the frequency of the gate and number of counts of the gate to get the total acquisition time.  This will require that you start and stop both counter tasks at as close to the same time as possible.  The start could be triggered with an Arm Trigger.  Getting the values from the counters would always require 2 software calls, but the longer the acquisition, the less important this error would become.
    Let me know if either of these sound appealing.
    Regards,
    John Bongaarts
    AE Specialist - Test Products

  • Why is buffered event counting cumulative

    I'm trying to do buffered event counting using general purpose counters on an e-series board. It doesn't work quite as advertised. Each point in the buffer is supposed to contain the count of source events that occurred between successive pulses of the gate, according to the Nidaq function reference manual. I find, however, that every point contains the cumulative number of events, so the data are monotonically increasing. Is there a setting somewhere to change this behavior, or is there an error somewhere - either in the documentation, or in the code?
    This was with NI boards 6711 and a 6035 in a G4 running OS 9.

    Gus said:
    "Where in the documentation does it suggest that buffered event counting is not cumulative?"
    page 8-51, NI-DAQ software reference for Macintosh. The example shows the buffer containing values of 4, 2, and 5, corresponding to the number of events between consecutive transitions of the gate, not the cumulative total of events since counting started.
    I have just checked to ensure that buffered period measurement is not cumulative, and it is not (which is good).
    Thanks for the tip.
    jamie

Maybe you are looking for