Jump to content

ned

Members
  • Content Count

    570
  • Joined

  • Last visited

  • Days Won

    14

ned last won the day on November 19 2016

ned had the most liked content!

Community Reputation

57

About ned

  • Rank
    The 500 club
  • Birthday 04/05/1980

Profile Information

  • Gender
    Male
  • Location
    Hayward, CA

LabVIEW Information

  • Version
    LabVIEW 2015
  • Since
    1999

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks for the notes! String to byte array wasn't an option because I needed to use a 32-bit wide FIFO to get sufficiently fast transfers (my testing indicated that DMA transfers were roughly constant in elements/second regardless of the element size, so using a byte array would have cut throughput by 75%). I posted about this at the time https://forums.ni.com/t5/LabVIEW/optimize-transfer-from-TCP-Read-to-DMA-Write-on-sbRIO/td-p/2622479 but 7 years (and 3 job transfers) later I'm no longer in a position to experiment with it. I like the idea of implementing type cast without a copy as a learni
  2. I really wanted to use that function a few years back, but it wasn't available on the cRIO I was using. In case it's helpful, here's the situation in which I'd hoped to use it: We were using a cRIO to drive an inkjet print head. The host system downloaded a bitmap to the cRIO, which the cRIO then sent to the FPGA over a DMA FIFO. I used a huge host-side buffer, large enough to store the entire bitmap; the FPGA read data from that FIFO as needed. I benchmarked this and it required 3 copies of the entire bitmap, which could be several megabytes: one copy when initially downloaded; one copy for
  3. I posted an Idea Exchange suggestion years ago that NI provide a warning about front panel property node use when building an RT executable, but sadly all we got was a VI analyzer test, which I assume you didn't run. If anyone has any pull with NI to make the build process warn about this potential problem, please try to make it happen. https://forums.ni.com/t5/LabVIEW-Real-Time-Idea-Exchange/Warn-about-front-panel-property-node-use-when-building-RT/idi-p/1702046
  4. Cross-posted here: https://forums.ni.com/t5/LabVIEW/Complex-cluster-array-with-static-size-in-calling-dll/m-p/3741685/
  5. You can turn Auto-Grow on for that loop. Then select any item in the structure and use the arrow keys on the keyboard to push that item past the edge of the structure to make it grow. Not quite the same thing, but maybe close enough?
  6. You definitely cannot use a .NET library on a cRIO. .NET is Windows-only.
  7. The most common way that the FPGA buffer fills is when the host side either hasn't been started or hasn't been read, but at very high data rates a buffer that's too small could do it too. The DMA engine is fast, but I can't quantify that. Transfer rates vary depending on the hardware and possibly also on the direction of transfer (on older boards, transfers from the FPGA to the host were much faster than the other direction, that may no longer be true with newer hardware). Is there jitter? You could measure it... make a simple FPGA VI that fills a DMA buffer continously at a fixed rate. On the
  8. First, one terminology note: NI uses "host" to mean the system that hosts the FPGA, in this case your RT system. RT and Host are synonymous here. It sounds like you have a misunderstanding about the DMA FIFO. The FIFO has two buffers: one on the host (RT) and the other on the FPGA. The host-side buffer can be many times larger than the buffer on the FPGA. The DMA logic automatically transfers data from the FPGA buffer to the host buffer whenever the FGPA buffer fills, or at regular intervals. If you're finding that you're filling the DMA FIFO, make the host-side buffer larger (you can
  9. Have you checked what methods and properties are available for the .NET class that's returned by GetActive? Are you sure that the ToInt64 method returns a memory address? How did you configure the MoveBlock call? Make sure that you configured the src parameter as a pointer-sized integer passed by value. If ToInt64 does what you indicate it should do, then the value on the wire is the memory address and should be passed directly (by value); if you instead pass a pointer to that pointer, you'll get garbage.
  10. The line at the bottom isn't a function prototype; I'm not quite sure what it's supposed to be doing. Can you include more of the header file? Data Format should be set to Array Data Pointer. You should never pass a LabVIEW handle to a DLL unless that DLL is specifically written to handle LabVIEW data types. There's no need to take an empty string, convert it to an array, then type cast that to a cluster; bundle in the cluster constant directly. You could also ignore the structure entirely, compute the size of the cluster ((256 + 4) * 256) = 66560 bytes, initialize an array of that s
  11. We're trying to acquire several more PXI 4130 SMUs, preferably inexpensively. I'm sure we're not the only company with lots of spare NI hardware around (but, of course, not those modules). Anyone have some of those modules they no longer need and would be able to sell to us? Any recommendations, other than eBay, on where to look for used NI hardware?
  12. My (least) favorite conflict with IT: we had a site-wide, network-based solution for printing product labels, which was accessed through Internet Explorer. We wanted some in-house software (that I was writing, in LabVIEW) to talk to that system, but we weren't willing to pay the exorbitant vendor fee for the SDK, so I dropped IE into an ActiveX container on the LabVIEW front panel and got everything working happily. Later, IT wanted to upgrade the version of Internet Explorer, and needed to confirm that it wouldn't cause problems for any existing applications. I mentioned that several peo
  13. Apparently we're in the minority here - we're using Mercurial (TortoiseHg). It was set up before I started, it wouldn't have been my first choice. We now have most of our code in a single repository which has grown unmanageable so we're looking at other solutions, perhaps we should consider moving to SVN (based on responses here) while we're adjusting our repository structure. I like the idea of Mercurial, but delta-based versioning just doesn't work that well for binary files. I've used SVN a bit but most of my previous experience is with Perforce and that would be my first choice if I got to
  14. For whatever it's worth, we haven't even been able to get multiple executables that use network streams, each talking to a separate cRIO, to run in parallel. Only the first one connects, and the rest don't. Coworkers investigated this before I joined the company and finally gave up; I haven't dug into it further. Instead we build a single executable that launches all the separate user interfaces, which is slightly annoying since a rebuild of any one interface requires rebuilding all of them, but it works. We recently replaced network streams with TCP communication, for other reasons, but one s
  15. MgErr is defined in "extcode.h" found in the "cintools" directory within your LabVIEW installation. When you create a C file from a Call Library Function Node, you'll notice it includes that file - it includes definitions of standard LabVIEW data types to avoid any confusion over things such as the size of an integer.
×
×
  • Create New...

Important Information

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