Stobber

The standard warranty is 1 year. People expect NI's hardware to break down that fast, huh? Seems like a poor choice for an OEM, or even a process controller, if that's the case.

I have a cRIO-9064 with the desktop stand accessory to sell. Where do people sell these things to one another?

djpowell, could you add support for extended error codes to this API? I'm struggling with a SQLITE_CANTOPEN error on a cRIO that never used to appear, and I don't have enough context to know what the heck is wrong. Also, could you modify SQLite.lvlib:Format Error.vi to yield the full call chain? Figuring out where an error came from without it is sometimes really hard. If you don't want to stringify the call chain all the time, maybe make it an option I can toggle on Open?

Had to swim far upstream to find the instrument config for this app. Yes, it's terminated by 0xA, as usual. Their query function is definitely looking for a byte count, though. I don't want to have to understand the design goal of the entire API, so I think I'll stick to the edit I have as long as it doesn't cause any regressions or new bugs.

Thanks, guys. The instrument's data width is fixed all over the API, probably a fixed memory width baked into the hardware design. So there's no apparent need to code the 64-bit case. Here's an attempt to make the serial query VI a little less moronic. I'm pulling into a fixed-size buffer while reading, and then doing a single copy afterward to get the string I need. The buffer grows only when a bigger string is called for and never shrinks. This should limit the number of allocations caused by serial queries.

I'm using a Keithley instrument driver that works over RS-232 on a cRIO. Our app is leaking memory somewhere, and the component that uses this library is highly suspect. I've been refactoring a bunch of it to use shift registers and IPE structures, and I just found these two doozies (attached, LV 14.1). Together, they build a string byte-by-byte when read from VISA and then convert it to an array of DBL element-by-element. Here's a screenshot of one of them: What's the best way to modify these two so they're better citizens of LVRT (i.e. no memory copies, or as few as absolutely possible)? Query Command.vi Real 64 Converter.vi

I'm using it in 2014.1. I would wait for a major upgrade to break compatibility. Shaun's suggestion of back-saving makes sense to me. I've done that with concat tunnels, and the code generator replaced them with old constructs appropriately as I recall. If you don't wait for an upgrade, then I'd bump the revision by a major number anyway. You even might consider setting the major rev to the version of LV it's developed in.

I wrote all the articles and APIs you linked when I worked for NI. Those APIs only work for the HS-DIO line of products, which are digital vector generator boards. You're looking for LVFPGA code, but I can't find any for a JTAG controller. You'll probably have to develop your own or use the IP Integration Node to import a pre-built JTAG core (if one exists).

Test it with a cluster full of big arrays. You should see an allocation when you unbundle/bundle without the magic pattern.

No, I don't have documentation. I learned about it when I worked at NI as a Systems Engineer and had access to unpublished documents about LV, as well as people who had developed the language. I verified it with an NI R&D engineer while developing a project in March of this year. IPE does add logic for other nodes, like the DVR node that adds a mutex when popping the value from the pointer.

Trivial examples have trivial impact. Anyway, this is still a derailing of the thread's topic, so let's agree to disagree. Edit: Found this on an article linked below and just had to post it as a counter-point: https://i1.wp.com/www.notatamelion.com/wp-content/uploads/2015/07/Read-and-Decimate-Big-Data.png

I haven't looked at his code, but I want to clarify this: for unbundle/bundle, the IPE structure just enforces the "magic pattern". It doesn't add any logic behind the scenes at all. As for diagram legibility, that's subject to preference. (The magic pattern is when you use unbundle by name on the same items, in the exact same order, in a path of unconditional logic (i.e. bundle node not in a case structure). If you change the order, or fail to bundle an item, or bundle an extra item, or put the bundle in a case structure the compiler will duplicate the entire cluster in order to finish the operation. If you follow the pattern, it'll update the items in-place.)

No thanks. I simply changed the pattern, and it works fine without having to introduce new dependencies to the app.

Thanks, Rolf. That email thread is 6 years old, so I sent a message to Ed Scherer to see if he ever found a solution. Who knows, he might be able to help.

I know; I'm using that as a succinct way to say "when a row in a table changes in an interesting way". Are you being pedantic and ignoring my actual points for fun?