Jump to content

codcoder

Members
  • Content Count

    6
  • Joined

  • Last visited

Community Reputation

0

About codcoder

  • Rank
    LAVA groupie

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2015
  • Since
    2012
  1. This is simply amazing! Speedy answer, working solution. Thanks enserge! To be clear for anyone with the same problem it is the two steps YScale.ScaleFit=0 and YScale.ScaleFit=2 that does the trick (I guess you force LabVIEW to internally update the chart or something). Will you report this to NI enserge?
  2. Hi guys, I'm trying to programmatically update the names of five plots in a digital waveform graph. The plots are in a particular order which corresponds neatly withe the order in the legend as in the order under the "Plots" tab in the properties window. However when I try to update the Plot.Name property for each plot by stepping through the ActPlot property the order seems to be 1-2-3-4-0, i.e. when I try to change the name of ActPlot=0 it affects the last plot instead of the first. What gives? Is there any other indexing property instead of ActPlot I can use which LabVIEW uses to keep track of the plot order? I'm just updating an old vi so it would be nice if it could be solved without altering the waveform used as an input to the graph.
  3. You've probably already decided which system to go with but I would recommend the cRIO over the PXI any day of the week. The cRIO is rugged, very cheap (compared to PXI), is more modern, has no irritating fan and is far more flexible with the built in FPGA capabilities. The PXI has some modules with mechanical relays (the cRIO only has one) and a lot of modules for radio applications (but I find them somewhat archaic and with the current progress in SDR and USRP we'll hopefully see some sort of useful radio module soon). So if you don't have a specific request only the PXI can fulfil I honestly can't see any pros with it.
  4. Good news everyone! Couldn’t find the SSD but I hooked up an old hard drive to the sbRIO with a SATA-to-USB adapter. Ran some benchmarking on forehand which reviled it to be around 10x faster than my USB flash drive. And sure enough the sbRIO had no problem storing data to the hard drive while simultaneously streaming the data over Ethernet to my PC. The next step is to find a suitable storage medium but I know now that the sbRIO itself is capable to handle my application. Thanks for the help guys! Cheers, CC
  5. Thanks for the input so far! For obvious reasons (as stated) I will never reach the theoretical maximum of 480 Mbit/s, and nor do I need to, but still 0.2% of that is "amazingly" poor. I use the FPGA on the sbRIO to store the bit stream in a DMA FIFO consisting of uint8 elements. On the RT processor I have two timed loops: one that pops a fixed number of elements from the DMA FIFO and pushes them as a byte array element on a queue and another loop that simply pops an element (a byte array) at a time and stores it on the USB flash drive using the standard write-to-binary-file block (with byte order set to native). I’ve set the number of elements I read from the DMA FIFO in each iteration as a multiple (currently x8) of the sector size of my storage medium. I’ve tried to replace the USB storing with both storing on the internal memory of the sbRIO (thanks for the tip smithd!) and sending the data to my PC as a network stream. Both these variations have worked successfully with no loss in data, i.e. the sbRIO can send data fast enough both over Ethernet and to its internal memory, but the system design requires the data to be stored locally (and the internal memory is too small for my application). I’ve also tried a couple of different USB sticks I have lying around with no better result but I’m gonna get my hands on an external SSD later this afternoos. I’ll let you know if that works. Cheers, CC
  6. Hi guys, Long time reader, first time writer. I'm currently trying to develop a data gathering system using a NI sbRIO-9606. The premise is quite straight-forward; I have a digital signal (data and clock) with a bitrate of 10 Mbit/s which I want to store to a USB flash drive in real time. The single-board RIO has no problem reading and processing the bitstream but storing the data to the USB flash drive is apparently not as easy as I thought. According to the manual the USB port supports a transfer speed up to 480 Mbit/s (USB 2.0 standard?) but I've been unable to achieve any faster transfer speed than around 1 Mbit/s (1.3 Mbit/s worst-case). This is unaccaptable for my application! I'v tried to disabeling buffering for the Open/create file function and only storing files in multiples of the sector size but it does not seem to help. Are there any preferrable USB flash drives one must use? Or am I unaware of any "high speed file streaming" options in LabVIEW? Sincerley, CC
×
×
  • Create New...

Important Information

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