writing complex arbitrary waveforms

[falkpl]

I am using a 6534 to communicate over a three line custom protocol with to an asic.  The chip expects a clock line (~4Mhz) a frame sinc bit on another line and 16 bits of data on a third line.  each command is 17 bits long, a frame sync bit on line 1 and 16 bits (the command word) on the data line.  I was able to implement this by using a port to make the approperate wave form (using 3 of the 8 lines in a digital out port).  Now the problem, I will need to issue 48 different command words in a specific order and the commands must be seperated by an exact number of clock cycles.  I can generate a very long waveform and do this but the waveform becomes extremly long (10's of MBs).  Is there a methot of creating 49 different buffers (one for each command word and 1 for the clock cycles) and then queuing them up to issue in a specific order without any dropped clock cycles between digital out writes?  I am relativly new to digital output streaming and am stuck.

Paul

[Kevin_Price]

Don't consider this the last word on the topic, but I don't think NI's high-speed digital boards are a particularly good solution here for exactly the reasons you're dealing with.  I've groused and moaned for a long time about the need to support a feature like "buffered pulsetrain output" by counters which could be put to excellent use for apps like yours.  You'd simply define a buffered pulsetrain with pulses only at the times when a bit needs to change, and also define the digital data only at those same times.  You shouldn't need to write 10's of MB worth of the exact same digital state in order to maintain precise burst-to-burst timing.  But as far as I've been able to figure, that's exactly the wasteful approach that NI's boards have always demanded.

There's a chance that one of NI's arbitrary waveform generators might be able to handle such a thing more cleanly, but I really don't know much about them.

Now then, here's what I can recommend enthusiastically: the PCI DIO-64 put out by Viewpoint Systems, one of NI's Alliance Partners.  It works just the way such things ought to work.  You define the digital states to generate at each transition time, coupled with the transitions times themselves.  It sounds like you may only need 17 bits / burst * 48 bursts = less than 1k worth of samples rather than 10's of MB.

I've posted about the board in the forums before too -- maybe I described it better one of those times?

-Kevin P.

[falkpl]

Changing hardware is not a realtiy.  The system is already in place and I am trying to enhance it unfortunatly.  I could however try to augment it with an external pulse train to send out finite timed sections of the buffer.  That is, make one buffer consisting of all the commands (17bits each on 3 lines) and send them out on a triggered edge, would be very nice if the dio card had atleast one counter onboard.  But you dont think there is a way to conmtrol the buffers more precicly on this card?  Not exactly the news I was hoping for.  I will keep banging my head in search of a solution.  Thanks anyway.

Paul

[Kevin_Price]

I don't know the 6534 all that well, but have done a fair amount of hw-timed DIO with the newer M-series boards.  I would expect that you can control your waveform with good precision, but not without some hassle.  If the onboard memory isn't deep enough to hold your whole waveform, you'd have to do just what you figured on -- write the 10's of MB of samples down piecewise using the right bite-sized chunks at the right time.  You'd probably have a loop to query the output progress status which would then alert a different loop that'd write another chunk to the task.  Something like that.

Should be do-able, but it feels kinda dirty and inelegant.  I think that's what you're stuck with though.  Anyone out there know otherwise?

-Kevin P.

[Yardov]

Hello Paul,

Kevin is right that waveform generators are ideal for these situations since you can use scripting and only wait for some event to happen to move into some waveform in the buffer (devices 654x and 655x). The PCI express version of the card you have would easily stream that amount of data in the buffer (devices 6536 and 6537).
Since other device is not an option lets work out something with the one you have:
You will have to stream the data from PC memory since there is no counter we can generate. Since you have some on board memory this is feasible if you write the first couple of commands in memory and then as you start streaming you will write the following data. This benchmark will give you some insight on what to expect and this document can explain how this process will work if you want to use the disk.
As we said, this is not the ideal product, but is feasible and hope this tips helps you get going,

[falkpl]

Thanks for all the input. Since changing the card is not really an option it might be easiest to add a simple timer card (6601?) and use the pulsetrain to write sections (1 command at a time) triggered by the pulse train.  Should this work, ie write n(17 bits) samples on each rising edge of the puste train where the edges are set to time the command writes?  I can use rtsi bus to avoid any additional external wiring. 

Paul

[Yardov]

Hi Paul,

Excellent! Complementing your application with this card would be more adequate for the task you want to do. You can start using the shipped example called "Gen Dig Pulse Train-Finite-Retriggerable.vi" to create a pulse train that re trigger itself.
Then you can route this clock (exactly using RTSI) and then use the 6534 to output the data. The shipped example "Multi-Function-Synch Dig Read Write With Counter.vi" can help you with the structure of the combined program.
Best of lucks,