Fehler -200292

[Ymelli]

Hello,

I am currently working with a Chassis cDAQ-9191 and a Modul Ni 9403 with a Wireless connection. I want to create a PWM signal. At first I had a problem with the empty Puffer, that is the reason for creating some data before starting the task, but now I always get the error that the Puffer is full. I was looking into things and I got the feeling, that the task is initialized at the Chassis, but I get no actual output. So I guess the data in the Puffer is piling up and no date is "released", because I get no Signal from the channel. So maybe I just missed something for triggering the actual signal output. I hope you can help. I put my Program into the attachments so you can have a look.

Greetings

Ymelli

[TroyK]

It could have something to do with having a sample rate of 20,000,000 samples per second and only giving it 10,000 samples. It will be done in 500µS.

It will be difficult to supply it with data fast enough at that rate. Check the maximum update rate for a wireless DAQ. I'm pretty sure you can't write data to them that quickly.

At the timing VI you specify 100,000 samples per channel and when initialising the aray of data you only specify 10,000 samples. Is that a typo?

[Ymelli]

Hello Try,

thx for your answer, the 1000 was kind of a tipo, but now, I tried to run the prog with one more zero (10 000) and I don't get my PWM pattern, I only get an Signal, that is going up one time and stays there.

Regarding the 20 000 000: because I put my Timebase at 20 MHz the program is demanding me to put a similar rate at this position (I guess for relating the samples to the time).

The 10 000 Samples that I create: I put this number there because it is working better then the 1 000 I had before. But I did check for the datasheet of the Chassis. It is able "to continuously acquire up to 51.2 kS/s of simultaneous 24-bit data on four channels". So I thing this rate should be ok.

But you put a "Sample Clock" at the Dmx-Timing and I put a Sample-Takt, that might explain the difference in needing the 20M or not.

I hope you have another idea about, why my Chassis is creating the Task put don't put out any signal!

Greetings

Ymelli

[TroyK]

The problem is that you are using the 9403 in a CompactDAQ (the cDAQ-9191).

The 9403 datasheet states "When incorporated in an NI CompactDAQ chassis, the NI 9403 can be used only as a static (software-timed) digital input/output module. With the NI 9403 in a CompactRIO chassis, you can use LabVIEW FPGA to program the NI 9403 for implementing custom counter/timers, pulse generation, and much more."

You are trying to do custom pulse generation with a CompactDAQ when it will only work as a CompactRIO.

The CompactRIO allows an FPGA to control the IO. Hence a phenomenal update rate.

In the wireless CompactDAQ you are limited to software timed updates. The rate you can send updates is stated a "system dependent" in the 9191 datasheet.

From what I can tell, you may be able to download a waveform of up to 2047 points to the device and have it clock that out. It appears to be the only way to achieve what you're trying to do with the components you have.

Then when the user changes the desired PWM, send a new waveform with the new PWM. You may find that the update occurs randomly in the waveform cycle instead of neatly at the end/beginning of a cycle.

[Ymelli]

Hello Troy,

we just changed some parts of the program (you will find two solutions at the attachments). Now both programs are able to get the wave form correctly out of the chassis and modul. The problem that remains is, that the change of the signal length reaches far too late the oscilloscope (controlling our output signal from the modul). In the software we see the change fast and correct. The same problem appears in both programs and we suspect it might be a problem with the buffer. Maybe he first reads out all the stored information, before the new signal reaches.

Ymelli

[TroyK]

I like the look of "DIO Case.vi" much better.

If you write the data to the device once, and allow regeneration (the data will be continuously output until updated or stopped) you should only need to update the data on change.

I don't have the actual hardware so I can't test this is working (it doesn't throw any errors on a simulated device).

See attached.

[Ymelli]

Hello Troy,

your prog really helped! thx!!!

We made some changes, due to my exercise. But the trouble with the late reaction of the hardware still remains. Could it help to let the chassis synchronize with the software more often or every time after running through the case? Maybe you can help me with that a little. I put my prog with the sub at the and.

Greetings

Ymelli