counter based measurement using AnalogComparisonEvent together with analog voltage measurement, Error -200278, 0 Samples available

[JochenR]

Hello everyone,

I am having a problem with a rather complex acquisition. I want to measure the duty cycle of each pulse of an inceremental encoder using the onboard counters and I want to measure the analog output of the encoder using the analog inputs of the DAQ device. This analog acquisition has to be triggered using an analog trigger.

The encoder might have an output voltage of up to 30V, so I decided so connect the A and B signals to analog inputs, which is nessesary for both the analog acquisition and the counter based acquisition. The duty cycle measurement is using the AnalogComparisonEvent to detect the edges of the 30V signal.

I am using two PCI 6115 Cards linked with a RTSI cable. Dev1 is used to connect the encoder, Dev2 is used to control some other Devices, which I think are not relevant.

To measure the analog signal I use a standard AI-Voltage task, the internal analog filter is enabled. This acquisition is working fine, as long as I don't try to measure the duty cycle using the counters.

To get the duty cycle of each pulse I am measunging the pulse widths:

dc=highPulseWidth/(highPulseWidth+lowPulseWidth)

Dev1/ctr1 is measureing the high-pulses, while Dev2/ctr2 is measureing the low-pulses. I could do that using one counter, but since the measurement can't be triggered, I wouldn't know which pulse is a high and which is a low.

The duty cycle measurement is working fine and the analog acquisition is working, too, as long as I don't try to use the counters. When I do that the duty cycle is measured ok, but when I try to switch back to the analog task it might fail.

As I said the analog measurement is triggered using an analog trigger. If I define this trigger as a start trigger, the DAQmx-read VI yields Error -200278, which is strange, because I don't specify the amount of samples to read. The error should only occour, when trying to read more samples then where acquired. The error message says, that sample number 0 (zero) could not be read. The configured amount of samples to read ist about 80.

Now if I change the trigger to a reference trigger, I don't get that error, but the result can't be right. This morning I had readings from +150V to -150V, this evening it was between +1 ant -0.8V and the result was perfectly constant over many acquisitions.

I said the analog task might fail, because this error isn't always happening. Today it was working fine for many minutes, but yesterday it was very reproducable after a couple of seconds.

I suspect that this is somehow related to the analog triggering. Both measurements need the analog trigger. The counters need the trigger to react on Dev1/ai1 and ai2 for the A and B signals, while the analog task needs to trigger on ai3, which is the encoders reference signal Z. As you can see the analog trigger needs to be reconfigured quite frequently.

The attachmant is the test VI I am using. To try it you need an incremental encoder mounted to some engine.

The VI was made using LabVIEW 7.1. The PCI-6115 cards have to be a couple of years old, too.

I am using DAQmx 8.6

My question is: Is there a mistake I am doing? (And I hope I'm doing one)

Or might the DAQ hardware be defective?

Best regards

Jochen

[JochenR]

Can I edit this somehow?
anymay: What I forgot to mention: Once the error happens, I have to reset the Device Dev1 in MAX or programatically to reenable analog input acquisitions, otherwise the error won't go away.

[Christian Mergl]

Hey Jochen,

Your code is quite confusing and there are many things which could be changed, but maybe the following part is the error producing:

You will notice that you wired the error not from the DAQmx Start VI to the Read and the Stop, so it can happen that you stop the Task while or before reading! Just wire the error from the DAQmx Read.vi to the Stop.vi, maybe this solves the error.

Christian

[JochenR]

Hi Christian,

your suggestion would explain, why there aren't any samples to read and why the measurement is working sometimes, but I don't think you have a point here, because the sequence of start -> read -> stop is defined by the task-wire as well as it could be done by the error-wire.

It is also very reproducable that the analog measurement is always working, as long as I don't try to measure the duty cycle with counters.

I'm sorry that you find my code confising. If you have some good hints for me how I can improve it, I'd appreciate that of course. I tend to avoid using the error-wire to define sequences, because an error might prevent the execution of code. For example if I got an error in the read, I might not stop the task. I guess in this case there won't be any negative effects if I use the error-wire as you suggest.

Jochen

[Christian Mergl]

Hey Jochen,

Maybe exactly this error wire is the problem, but for another reason. If you would wire it trough the Start>Read>Stop I think you would get another error than the -200278, maybe a timeout error. You have configured a timeout of 2ms for the DAQmx Read.vi which could then run in the timeout if no rising analog edge trigger occurs within this time.

Another thing could be, as you allready mentioned, that the Analog Comparison Event blocks another Start-Trigger because you allready configured one (ai1, ai2), and to don't get two differnt triggers it's not possible to set another Start-Trigger, but I'm not sure about this assumption. Out of DAQmx help:

AnalogComparisonEvent

A terminal within a device where the output of the analog comparison circuit, the Analog Comparison Event signal, can be found. This circuit is active whenever an analog edge or window trigger is configured.

Are you running a hyperthreading machine?

Some hints: Build SubVIs out of your code (see attached .jpg as example), comment your computations, better wireing, switch to a state machine architecture, if you dont connect error wires to avoid or ignor specific errors just wire the error through instead and erase the mentioned error, ...

Christian

[JochenR]

Hello again Christian,

I still don't get why it would change something in the program flow, if I wire the error as you mentioned. My thoughts on this are simple: why would the stop task vi be interested in the error coming from the read? I tend to give a subVI only the input it really needs. But just in case I'm doing a mistake here, I checked back how the stop is working and indeed it alwas stops the task, whether or not there's an error on the input connector.

So I changed my test.vi and now the error line is going straight throu, but it didn't have any positive effect. I have to admit, I had some trouble reproducing the error. Yesterday I wasn't able at all to get the error with the new version. But the same with the old one! Today finally the error came back to me. Both the new and the old version of the test.vi are affected. I bet Mr. Murphy would love this.

I've attached a couple of screenshots to illustrate how this error is looking like:

• analogWithoutDutyCycle_OK.jpg: Shows the frontpanel while executing the analog task in a loop.
• dutyCycleAfterAnalog_OK.jpg: Shows the frontpanel after switching to the counters with AnalogComparisonEvent
• analogAfterDutyCycle_Error.jpg: Shows the error on the frontpanel after switching back to the analog task. This only happens when a reference trigger is used. A start trigger will produce error -200278 during read and no values are returned. To get the analog task working again, I have to reset the device.

• highlightNoError.jpg: Shows the highlighted blockdiagram of the part where the analog task is started and stopped, while everything is working fine.
• highlightNoError2.jpg: Same as above, only using the old way to wire the error line
• highlightErrorRefTrig.jpg: The same part of the blockdiagram while the error is in effect. The task is using a reference trigger. No error is visible.
• highlightErrorStartTrig.jpg: The same using the start trigger. Error -200278
• highlightErrorStartTrig2.jpg: Same as above, but using the old error-wirering

My best bet at the moment is a problem with the analog trigger. Sometimes, right after switching from analog to counters, I get some false values from the counters at the beginning of the first measurement. The following measurements are all working. I know the encoder is working perfectly, so the analog trigger might not have switched fast enough. But on the other hand: the counter measurement is continiously switching the analog trigger from ai1 to ai2 and back. Shouldn't I get false values in this case aswell?

Yes, I am using an Intel Pentium4 with HT, no dual core.

Your coding style hints are of course very important. Particularly a good commentation is importand if I want to ask someone for help. I promise I will clean up my code if I upload a VI next time 😉

Please understand, that the test.vi is only for testing and demonstration purposes. I intentionally didn't use any subVIs so I could upload it more easily. It is also very comfortable if you can see every computation in the same blockdiagram if you are searching for bugs.

Best regards,

Jochen

[Christian Mergl]

Hey,

Did you also try increasing the timeout of the DAQmx Read.vi, e.g. 10ms?

Christian

P.s.: The only reason why I wanted you to change the error wireing was that it could be possilbe that the DAQmx Stop.vi produces another error than the DAQmx Read.vi, which then were lost because the merge error function only routes the first error through out. So to be sure to get the first error in your case this change made sense.

[JochenR]

Good morning Christian.

No I didn't, because I do get timeout errors if I configure the wrong level for the analog trigger, or if the rotation speed is too low. Nb: the timeouts unit is seconds not ms.

Also the timeout theory wouldn't explain, why I have to reset the device.

I guess I'll have to use an analog measurement and find my edges using software, although thats alot slower and consumes a lot of memory.

[Christian Mergl]

Hey,

Sure, the timeout is in seconds, sorry thats the force of habit! Another hint would be to turn of hyperthreading, could you test this please.

Christian

[JochenR]

OK, I just gave it a try and I wasn't able to reproduce the error within at least 20 minutes. I'll have to try again the next days to make sure it's working reliably.

Did you just make a wild guess, or is HT known to cause problems with NI hard- and software?

Greetings,

Jochen