Analog Discovery 2, analog input problem

[S.Kagawa]

Hello.

 

I am developing a system with Analog Discovery 2 and SDK (C++).

It uses 1 channel DA output, 2 channels AD input, and 1 channel DIO output.

I use "FDwfAnalogInStatus" command to detect the end of AD input. (Refer to the sample program.)

Normally, returned status should be "DwfStateDone" (2) or "DwfStateRunning" (3).

But sometimes it returns "DwfStateReady" (0) and never return "DwfStateDone".

I wonder if AD was not triggered to start for some reason at that time.

It seems that it occurs frequently when input voltage was high at previous measurement.

I wonder if there were some errors in previous measurement. (Over range or something?)

If it become that situation, it cannot recover until closing and opening the device again.

It cannot recover if "FDwfAnalogOutReset" and "FDwfAnalogInReset" commands were sent and setting parameters from the first.

I want to know how to detect the error status of the device that AD cannot start, and how to recover that situatuion.

 

[S.Kagawa]

Thank you for information and sorry for late reply.

After that, I found that the status value was not abnormal, but  the return value of status getting function ("FDwAnalogInStatus") was ERROR (0).

 

We are developing measurement system with Analog Discovery2.

It judges if electric discharging (spark) phenomenon was occurred through near 2 probes charging high voltage (MAX 250V).

It uses 1ch DA, generating 0-4V and boosted to 0-250V by amplifier.

It makes output wave data by custom setting mode. (0V->250V->0V)

And also it uses 2ch AD for recording voltage and current, which are synchronized with the start of DA output.

It watches the end of AD by poling AD status getting function ("FDwAnalogInStatus") until the status value would be "DwfStateDone"(==2).

 

Problem:

Sometimes "FDwAnalogInStatus" function returns "0" (== ERROR).

Once it become such a situation, "FDwAnalogInStatus" and other communication commands always return "0".

In short, the USB communication become broken.

It would not be recovered until executing device open from the first.

This problem used to be occurred when electric discharge (spark) phenomenon was occurred actually.

I think there maybe the influence of noise of discharging (spark).

But it would not be improved if shield reinforced.

 

Environment:

Host PC: Windows XP (32bit),  Visual Studio 2008 (VC++)

PC and Analog Discovery2 are connected with USB cable, but isolated by USB isolator. ("USB-029L2" by HUMANDATA Co,Ltd., corresponded to High Speed USB)

 

Is there any solution to prevent this problem?

If there were some similar case, please give me information.

[attila]

Hi @S.Kagawa

With the default acquisition mode when the FDwfAnalogInStatus returns done it also rearms the instrument. This is done to improve the capture rate.

[S.Kagawa]

Thank you for information.

 

It is not the cause of the problem, but I met a strange phenomenon.

 

After AD input, returned status code by "FDwfAnalogInStatus" command changed from "DwfStateRunning" (3) to "DwfStateDone" (2).

Normally, then break from the while-loop like sample program.

But I just do "FDwfAnalogInStatus" again for debug.

Then return status code changed from "DwfStateDone" to "DwfStateArmed" (1).

In case of DA output ("FDwfAnalogOutStatus" command), this phenomenon did not occurred.

After returning "DwfStateDone" by "FDwfAnalogOutStatus" command, "FDwfAnalogOutStatus" again, but returned status code also "DwfStateDone".

 

Is it a specification?

 

 

 

 

[attila]

Hi @S.Kagawa

Depending on the configuration and inputs the state can be: ready (configured and not started or stopped), config (doing internal configuration), prefill (pre-trigger stage), armed (waiting for trigger), triggered=running (post-trigger stage), done

See the examples in the WF SDK/ samples/ py and the manual:

You could also send or post your code.