05-18-2013 06:28 AM
Hi all,
I'm working on a project with a 6014 board and Real-Time Windows Target of Matlab. I need to interface the signals from two incremental encoders. The qudrature signals are converted into a direction signal and a pulse train signal with the idea to feed them to the counters of the board, configured as bidirectional counters in up/down mode. The connections are as follows:
For Counter 0 - the pulse train signal is fed to PFI8, and the direction signal to DIO6.
For Counter 1 - pulse train signal to PFI3, direction signal to DIO7.
The problem is that Counter 1 is working properly, while with the same signals fed to Counter 0 what I read makes no sense. The counter increments by very large values at once and behaves erraticaly.
I'm seeing this behavior on two different boards.
Any help please!
Thanks in advance!
Stanislav
05-20-2013 03:22 AM
Hi Stanislav,
I would suggest you to make a loop back test to test your counter on the board.
You can use counter 1 to generate 100Hz signal and wire it to counter 0. And see if you can read the frequency of the signal.
This way you can find out if you have HW related issue.
Best regards,
I.R.
05-21-2013 10:39 AM
Hi,
I appreciate much the response.
I tried what you suggested on one of the boards (as I wrote, I'm seeing the same problem on two different boards). Only I generated the test signal with one of the DIO of the board and not with the other counter (I didn't find a way to do so with the available blocks in Simulink library for Real-Time Windows Target). So what I found is the following:
The counter (counter 0) increments and decrements with the expected number of counts, depending on the level of the signal applied to the direction pin (DIO6), only when configured to never reset. When I configure it to reset each time when read, it actually fail to do so and as counting, within a regular interval, the counter value jumps with bigger steps that seem to be 2^n.
The other counter (counter 1) performs as expected in all configurations.
I intend to try the same with the other board that I have to see what happens there.
Any suggestions?
Thanks again!
Stanislav
05-23-2013 10:36 AM
Hello again,
I did similar tests with the second board with pretty much the same results.
I managed though to obtain stable and predictable behavior by resetting the counter in hardware, that is, by an external signal through PFI9/GPCTR0_GATE pin (the signal was actually generated by one of the board's DIOs). Here, of course, another "problem" appeared, since the counter seems to reset not on the rising edge of the gate signal, as configured, but rather on the next count event. This is another topic I suppose.
In the end, I don't think it is a HW problem since the counter works. (moreover the same problem on two different boards seems unlikely).
It may be a problem with the RTWT drivers (as far as I know, different drivers are used and not the NI ones), but still, counter 1 works perffectly in all configurations.
That's it.
Stanislav
05-27-2013
01:51 AM
- last edited on
06-12-2024
08:04 AM
by
Content Cleaner
Hi Stanislav,
My recommendation will be to install Signal express (it is a free application that you can use to generate or aquire data)
and DAQmx driver available at the following location https://www.ni.com/en/support/downloads/drivers/download.ni-daq-mx.html
After you install the two software mentioned above, launch Signal Express and it should be straight forward how to program because it is a configuration based programming. You can use the menu to generate a train of pulses on counter 1, also you may use an oscilloscope to validate the generation part and than use your software to acquire on CTR0. If you still have the problem to acquire on CTR0, you can reverse it and use Signal Express in the acquisitioin part.
Best regards,
I.R.