codcoder

Do you have any examples about this you can share? Becuase I tried using NI-Trace -- and perhaps it's about my lack of knowledge about the tool -- but to my understadning what was logged was nothing but the "high level" writes to property nodes and sub-vi's which I did in my top-level vi's. There were no information about the underlying USB communication.

For posterity: I've been in contact with NI Technical Support who confirms that the USB-8451 isn't designed to work with PXI Real Time controllers.

Thanks for quick answers. I was afraid changing hardware would be the answer. Doing that isn't that easy either as the hardware configuration is quite fixed at the moment. My current "temporary" solution is to use a Windows PC connected directly to the USB device running a looped LabVIEW *.vi which constantly writes i2c to the device every second or so. This works. I will look into other neater solutions as soon as I get the time. I promise to post an update here if I figure out anything useful.

Hi, I have a problem here. Hope I can get some help for a solution. The task at-hand is to use an NI USB-8451 to communicate with a device over I2C. This would have been trivial if it wasn’t for the fact that the USB-8451 is connected to a PXI controller running LabVIEW Real-Time OS (Phar Lap ETS) and not a Windows PC. I haven’t chosen the hardware combination personally and the person who did just assumed they would work together. And I did too… I mean, it's NI's eco system! Just download the NI-845x Driver Software from NI’s webpage, install it on my PC and then install whatev

Couldn't agree more. I also believe NI really need to push LabVIEW more aggressively to the maker community. This is a group of people who adores things that are "free", "open", "lite" and today, LabVIEW simply doesn't make the cut. Of course the coolness factor will still be an issue (a night/dark mode could probably help?) but surely there must be a way to position LabVIEW as a great tool to help creative geniuses to focus less on grit and more on, well, actually creating stuff. I work in the aerospace-defense-industry. With hardware. But we are fewer and fewer who does. The majori

Extremely bold. I work in a conservative organisation who uses NI's offerings a lot and I know many collegues who will not take this lightly. And it will probably bug me a little that any future NI hardware we purchase will not visually match current gen. But subjectively I like it. Feels contemporyary. But will it stand the test of time?

I like the side discussion here. About the future of LabVIEW. I've been in the field for close to seven years now and I constantly ponder if relying my carrer on LabVIEW is a wise decision. Because I mean, I'm no junior anymore, and just as much as by chance as by choice LabVIEW has become my speciality now, and changing track is harder and harder for each year. Last year I attended my first NI Week and to judging from NI's marketing it was clear, according to me, that they have moved away from the use case of an engineer/scientist with a benchtop instrument controlled by a Windows P

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?

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

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

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

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

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 f