Jump to content

AlexA

Members
  • Posts

    225
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by AlexA

  1. Ahh, apologies for the split. Could I request a mod merge this with this thread: http://lavag.org/topic/14883-examples-of-massive-programs-and-your-block-diagrams/ and a change of title to that thread, something like "A conversation on factoring code" (and a subsequent lock to this thread). I intend to upload an example of my now factored code into that thread shortly once I'm happy with some of the functionality.

    As I hope this thread will be merged I'll add the following comment here:

    I've managed to figure out how to dynamically load VI's and leave them running in the background. It might be overkill but boy do I like it! It really compresses things and makes the block diagram easier to intrepet and modify in my opinion.

  2. So, I've learned the value of scratch pad VI's :). I've figured out how to run a VI in the back-ground, haven't tried listening to its queues yet but that's next. Still a little bit stuck on how to close it properly. When I call close VI reference it works but leaves the VI running, when I use abort, then close, it doesn't actually stop and then close reference returns an error. Anyone got any insight into this behaviour?

  3. Hey guys,

    I imagine you're getting heartily sick of my flurry of questions by now. This one's been bothering me for a couple of days. Is there a conventional way for triggering a continuous process inside a state, without locking the state machine? The only hint I've seen how to do this is to place the process inside a sub-vi and launch it with "wait until complete" set as false.

    I've also read a little bit about Daemon's on the lava wiki, is this what I should be looking at?

    What I'm trying to achieve is:

    I have an FPGA which performs two functions, generates a stream of images, and performs a set of calculations resulting in a single number out which describes a characteristic of each frame. In my host code, I want the user to be able to interact with these two functions independantly. I currently have a state machine/producer-consumer architecture. The UI loop is the producer and loads commands into a queue which is unloaded by the consumer and acted upon. Currently I have a third loop bolted on to this which when triggered, starts listening to the FPGA FIFO for data and packaging it up into a Queue.

    I would like to if possible, move this bolted on loop into a sub-vi which can be triggered and stopped all from inside the state machine. I would also like to create a similar sort of triggered "listening" state which dequeues from the FIFO gathering loop and processes.

    Anyone got any good ideas for dealing with the goal of triggering continuous processes (and stopping them arbitrarily) from inside states, without locking the state machine.

    Regards all,

    Alex

  4. Yeah, there's a problem in that I also need to pass information to the "consumer" loop along with the "go" type instruction. I need to pass a reference to an FPGA vi. I got really excited and started off using a JKI state machine to handle the user interface and a few calibration routines. Now that I want to listen to the output of the stream from the "consumer" loop at any given time, the JKI architecture doesn't make as much sense. To go into a listening state locks up my user interface so the listening state can't be cancelled.

    I think I'll have to move to a 3 loop architecture. I saw it around on these forums but can't remember what it's called, MVC maybe? I'm thinking a UI loop based on an events handler which enques messages for a general loop which handles messages and acts on them and a "stream" loop which starts and stops the data stream from the FPGA. When started the stream loop loads data via lossy enque into a queue and the act of dequeuing and processing is handled in the "general loop".

    Should I handle constants which are initialised at program start-up, but subject to future reinitilisation depending on the result of a calibration routine, in the UI loop? Or in the "general" loop?

    Arrgghh, started with a bang into this state-machine type coding and now it's all spaghetti but I just can't see the wires :(. Could someone link me a "getting started with state-machine/producer consumer" type reading, preferably free if such a thing exists.

  5. Hey guys,

    Some of you may have looked at the thread I posted recently about trying to refactor my code to not be a squiggly mess. I'm trying to break apart the functionality of the program into sub-vis as well as decoupling the UI from the processing. One of the problems I'm having is that I have a series of loops which are interacting with an FPGA. Most are listening to FIFO's waiting for blocks of data to arrive suitable for processing. One is triggering the initiation of data capture. I'm trying to wrap my head around how I can trigger these loops to start listening once the user is ready for that to happen (after they've performed some calibration and constant initialisation), but also to trigger the stop condition on these loops when the user doesn't want to listen anymore, and then to start it again when they're ready to.

    Mostly I'm struggling to figure out how I can pass the stop condition across the multiple parallel loops (is the best way really to use a local variable like I have been)? I have tried to diagram below the structure of the code in abstract as I currently imagine it. Can anyone point me in a better direction for what I'm trying to do?

    post-16778-0-24330900-1315517888_thumb.p

    As a general question, is it ok to nest event structures and while loops like that?

    Your wisdom is much appreciated.

    Regards

  6. Hey everyone,

    This is exactly the sort of advice I was looking for, some really beautiful little block diagrams. I'm definitely going to work on getting the code broken down into sub-vi's. Thanks for your examples.

    @P de Boevere: Hahaha, I wish I had that luxury, unfortunately I'm a lowly PhD student trying to thrash out all the stuff I've been tasked with doing.

    For your entertainment pleasure, I've included the block diagram of my main vi:

    post-16778-0-60969500-1315433060_thumb.p

    Obviously I've got a lot to learn...

  7. Hey all,

    I'm currently constructing a whopping program that after tidying (and commiting the crime of hiding a routine in a stacked sequence structure) is a couple of screens across horizontally. I was wondering if anyone would be keen to upload a screen shot of the block diagram of their current massive project. I'm not really interested in what it does, just the individual approaches people are taking to keep their code tidy and easy to interpret. Also, if anyone knows of a really good resource for tips regarding organising your code elegantly in labview, please let me know.

    Regards all,

    Alex

  8. How exactly does the different buffer size thing work? If I'm writing data into the DMA FIFO in the FPGA and it's got x elements, but those elements fill up before I can get a read command off, how does having a bigger buffer on the host side help? I would love to use DMA, but in my experience I can't balance the read commands accurately. Either I call for too many elements and get a "read could not be processed in the specified time out" or I don't call for enough and the buffer over runs, I start losing data.

  9. Yeah, DMA doesn't really work at the throughputs I'm talking about either. I'm streaming images out from the FPGA at least 52MBs/s, you can't build a DMA FIFO big enough to handle that sort of throughput due to the differences between the speeds of write in FPGA and read in windows, whatever size you build is going to fill up. Because of the non-determinism you can't reliably hit a certain number of elements in the FIFO on every read call, which makes handling the data a bitch in the host code. My skin crawls at the idea of trying to rely on a-priori knowledge about the different data rates to get the read quantities right given how variable windows is.

    The best I've come up with is to use the onboard DRAM to handle high-speed writes then read it out at a later point at a much more sedate rate, hence the hand shaking.

  10. Ok, I couldn't figure out the best way to synthesise my problem down for a title but that will have to do. I'm trying to send information around between the target FPGA and a windows host machine. The problem is that, because the information coming from the FPGA is from a single-cycle timed loop, and the windows host code is slow and not deterministic, I can't rely on polling a "data ready" type indicator to begin the transfer without latching said indicator. If I latch it, I don't know how to unlatch it so it's not a one off event.

    Does anyone have any good advice for this sort of problem?

  11. Hey all,

    I am using a PXIe-7965R in a PXIe-1073 Chassis. This box is connected to a computer running Labview RT via a MXI cable to a PCIe receiver card. The 7965R has a NI 1483 cameralink adaptor module plugged into it, this is in turn connected to a Photonfocus camera with an 80MHz pixel clock. 8bit pixel data is gathered at a rate of 100MHz, using at least 512 lines.

    The problem is that the system bandwidth listed on the NI website for the PXIe-1073 Chassis is 250MB/s. To stream 8bit at 100MHz (if I just use a to host DMA FIFO) requires 800MB/s. So, I'm stuck with some architectural issues on top of some fundamental questions. Given that an RT system can't perform read operations as fast as the FPGA can perform writes, I think I'm always going to get write timeouts and data loss, would this be correct?

    One solution, assuming that the aforementioned problem is not as important as I think it is, would be to use a really big DMA FIFO and only trigger the capture on a succesful read out, this has issues in that it wastes FPGA resources which I want to use for other image processing functionality (FFT's etc.).

    An alternative solution (which I believe may not be possible after reading the help file) Is to use the onboard DRAM to store the images, then read out from it later at a slower rate. According to the help file, you can not use memory to transfer data between clock domains on the FPGA, is this the case when using DRAM?

    Does anyone have any insight on this issue? I'm prepared to accept less than optimal streaming, (I'm thinking of bursts of high-speed images stored in DRAM and read out slowly) if it's possible, or am I stuffed?

    Regards everyone,

    Alex

  12. The frequency domain is made up of positive and negative frequencies. If a signal is real, then X(f) = X(-f). It's just the way the math works. Now since we are dealing with a digital signal, the spectrum repeats every Fs (sampling frequency). So if Fs is 1000Hz, you will see the spectrum that was centered around DC repeat at 1000Hz. If the spectrum bandwidth is greater than the Nyquist rate (Fs/2), then these negative frequencies that I mentioned earlier will show up in the band you are looking at. This phenomenon is called aliasing. So if you have a sine wave at 600Hz and Fs = 1000Hz, you will see a signal alias into the band at 400Hz (1000Hz + -600Hz). If you care about that 600Hz signal, then you need to up your sampling rate (and thereby increase your Nyquist rate). If you don't, filter it out before sampling.

    Thanks, I managed to find a really helpful book after posting the OP. So if anyone wants help with DSP it seems to be a free online book.

    http://www.dspguide.com/ch16/3.htm

  13. Hey,

    I'm not sure if this is the right subforum. I'm in the process of trying to recreate the approach taken by the tone search algorithm in FPGA hardware. I've read through Alain Moriats 1999 presentation on the algorithm and spent a lot of time figuring out the maths myself, and finally googling a phenomenon that Alain makes note of, specifically, mirroring or wrapping round of the sinc (or Hanning modified sinc) envelope in the frequency domain off of DC and Nyquist.

    My question is, what is the basis of this phenomenon? I can't find a reference to it in any literature so I was wondering if someone could illuminate by what mechanism the envelope is mirrored off DC and Nyquist?

    Regards,

    Alex

  14. Hey Mark

    Thanks for your solution, I had a little trouble implementing it initially because I didn't put in the case structure, i.e. if no error -> do code, otherwise -> do nothing. As an aside, how much does having the error checking case slow the code down in your experience? Is an error signal a logic 1 or 0? If so I can't imagine it slowing things down too much, if it's a package containing error information with every check that might slow things down. Your thoughts? I ask because speed is crucial in the application I'm trying to create.

    Kind Regards

    Alex

  15. Hey everyone

    I'm reaching the end of my tether with these while loops running in parallel. My program seems to run fine but then when I hit the stop button it just hangs and doesn't exit. Can someone tell me, or link me to an explanation of how to propagate a stop condition in producer consumer loops, in addition, how should I destroy the queues so that they are destroyed in the right order?

    My code is attached if it's of any help at all.

    Regards and thanks for your time.

    Alex

    post-16778-126576501268_thumb.png

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.