vbnet counter input channel read

[Kaxten]

Hey,
Some more questions. IRQ, does this still record data at the same time or does this switch between channels to record data sequentially?

I have been working with my customer and he has noticed something peculiar. With 2 analog and 1 counter input channels active, the analog data seems to start recording before the counter data starts showing that the encoder position has changed.
    I destroy and start each task from scratch.
       Create analogchannel, configure timing, start task. The timing is set as such task.configuresampleclock("dev2/ctr3", 1000, rising, continious, 1000)
       Create  angular velocity channel, configure the timing. The timing is set as such task.configuresampleclock("dev2/ctr3, 1000, rising, hardwaresinglepoint)
  The counter output channel (ctr3) is stopped.
    when I Start everything off I start the counter output task (starting the pulse train) and then start taking asyc readings. In the code I start a read from the analog before I get to the counter, but shouldn't the start of the tasks be tied to the start of the pulse train and not to when I ask for a reading? Or is there something else I have configured incorretly?

As to the current value. Do I have to use the z index or can I do this without it (the origional vb app didn't use it, is why I am asking). I see that that the number the counter input returns for a current location matches what the encoder software says (in ticks). When I set the task to nothing and then recreate it passing in the previous value in ticks (or even the current value in ticks from the encoder software), the value I read out from the first time I attempt to read is greater by x times than it should be (as I haven't moved the encoder). I would expect the first number out to match the position I put in if the encoder hasn't moved from where I recieved the last reading. The only difference is that it is a newly created task. I always use one routine to configure this task with these settings task.cichannels.createangularencoderchannel("dev2/ctr0", "", x4, false, 0, AhighBhigh, 20000, CurrentTicks, ticks) - The CurrentTicks is my variable for that.

Thanks again,

CM

[Kaxten]

An example of the reading shift I am tying to describe.

CM

[MickeyD]

Hi CM,

The IRQ is going to switch between channels.  It does so based on hardware buffer requests, so it is not as fast as DMA.

Your customer should configure his tasks so that He starts the analogchannel and angular velocity first.  You say counter 3 the pulse train output is stopped.  I am assuming you have set up all the code, but just not started the pulse train yet?  I also suspect you would get better results not using hardware singlepoint timing, but setting up your counter for continious timing as well.  Assuming your setup is as I described, then try changing the timing of the counter task.  I will see if I have seen issues like this before.  Is the offset always consistent?

With regards to your last question.  I assume in the function you describe you make a call to

int32 DAQmxCreateCIAngEncoderChan (TaskHandle taskHandle, const char counter[], const char nameToAssignToChannel[], int32 decodingType, bool32 ZidxEnable, float64 ZidxVal, int32 ZidxPhase, int32 units, uInt32 pulsesPerRev, float64 initialAngle, const char customScaleName[]);

Current Ticks is your input for the float64 initialAngle parameter?
I set this up on a simple application and got my initial value, but are you putting in the number of ticks initially or the actual initial angle you want to be located at?  You say you are off by a factor of X, I assume you are always off by the same amount, this means we are probably initializing it, but not correctly.  Let me know what that factor X is and also if changing your initial ticks to initial angular position gives better behavior.

Have a great day,

Michael D
Applications Engineering
National Instruments

[Kaxten]

Sample app I used to figure out the current value. Not sure if it will help others or not.

Sample is yanked from a couple of NI provided samples and cobbled together in vb.net (vs 2005)

cm

[Kaxten]

Hello Michael,
So the IRQ while still not as fast as DMA, I will still be able to get values from all of my enabled channels at the same point in time, correct? Can this be configured on the fly (can I change a setting to use one or the other in code?)

In the code I configure the channels and set up all the tasks. I then have the pulse train stopped and the ai task started, ci task started and the last thing before taking async readings is starting the pulse train. So they should all  start at the same time since they are based on that pulse train, correct? The ai is actually further up in the code and gets started first, as well starting the reading first (so really not sure why ai values would lag behind the ci values). I am not using start triggers, I just have everything based on starting that pulse train.

Initial Angle - I have that one figured out. The offset was caused by the x4 encoder. So after playing around a bit longer, I found out what was happening.

Thanks again for the help,

cm

[MickeyD]

Hi CM,

The typical change in speed is 150 kb/s for IRQ vs 20 or so Mb/s for DMA.  Using the following property you can set how your counter data is transferred.

Ci.DataXferMech is the specific property

When you say you have the pulse train stopped?  You mean that you just don't start it, that it is waiting for a DAQmx start command, not that you have put in a physical DAQmx stop?
I am going to have to look further into the counter issue, because it seems you have that set up correctly.  The pulse train provides the clock for both the acquisitions, so they will not begin till it begins.

I will get back with what I find.

Have a great day,

Michael D

[Kaxten]

Hello MickyD,
I will be attempting the IRQ instead of the DMA here very shortly (Been caught up in solving other errors).

Pulsetrain stopped = yes, just not started.
I believe that I have solved the syncronization of data problem.
    1st error - I had the counterinput timing set to hardware and the analoginputs timing set to continous  - this was giving me a small spike in my readings. When I matched them all up, it worked correctly.
 2nd error - I was starting the pulse generation and then my code attempted to use the various readers to get values. I switched this to read and then start the pulse train and the values are now starting off at the same point.

I have a new error, but need to research it a little bit more before I can post it.

cm

[Kaxten]

Hello MickyD,

Attempted to use swtich to the IRQ collection method... Emphasis on attempted. The application doesn't error out, but does appear to hang until finally forcing it to shut down using control + alt + delete (can't even use visual studio to stop the application). Not sure what to try here instead as I think there is too much going on in windows for it to adequately control the interupts (my wag).

My other error: I have found that counter input channel 1 (which is wired to the encoder) will only return 0 values when my application starts up after the computer is rebooted. This persists even after enabling /disabling, resetting this channel and even after restarting the application, until exiting the new application and starting the old application and closeing it. The encoder returns its current postion via the com6svr com object and I have chassed it down to verify that values are actually coming in. They are, but they are all 0's. After using the workaround, the counter channel correctly reports position and behaves as I would expect. Any thoughts?

Thanks yet again,
CM

[Sandra_T]

Hello Kaxten,

I see that you were able to figure out the first error you were receiving, but now you running into additional issues. Can I get more clarification on the issue?

From your post, I understand that you are using a property node to switch to the IRQ collection method. Is this correct? How are you doing this?
The behaviour you see is your program hanging. Clicking on the stop execution or exit button does nothing.

Can you clarify on what you mean by (my wag). Did you mean my way, therefore referring to the way you set the IRQ collection method?

With regards to your other error, your counter is reading a value of 0. To reset your counter you need to end the task and restart it. For your posting I am uncertain of what you are seeing. What workarround are you referring to?

Please clarify and I would be glad to address some of your concerns.

Regards,
  Sandra T.

Applications Engineer | National Instruments

[Kaxten]

Hello Sandra,
I would be happy to provide more information.

wag = Wild ass guess (sorry, it was vague).

I was setting the task.CIChannels(0).datatransfermechanism = (CIDataTransferMechanism.Dma or CIDataTransferMechanism.Interupts) depending on if I had more than one counter input channel enabled at that time. I set this before running the task. When I tested this with 2 counters active, the application & and visual studio(vs) would lock up forcing me to use ctl + alt + delete to kill off my app and vs in order to get windows functioning again. My wag(guess) is that windows was unable to handle the additional overhead of handling the interrupts, which kept coming on backlogging and overloading the system and making it look like everything was frozen. I tried this multiple times with the same result, while dropping the sampling rate down.

My current work around is to use a windows timer to signal when to get a sample and set my counters to hardware single point timing. I then get a sample when the tick on the timer fires. This works, but I am really unable to go faster than 1 sample every 5 seconds or so.

Yes, I have the counter value resetting appropriately now.

Thanks for your assistance,

CM