Stobber

I'm trying to use it on a Linux cRIO. The API VIs execute without errors (even the individual CLF nodes), but nothing gets written to disk. Even the "Example 1 -- Create Table.vi" example doesn't work when targeted to my cRIO. It does create a file on my Windows system. Edit: Realized that SQLite3 wasn't installed on the target. Ran "opkg install sqlite3", which put the executable in /usr/bin, but that doesn't work like a shared library for the API. I think I need to get a .so onto the target and point to that in the "SQLite Library Path" parameter. Edit 2 (SOLVED): The library is /usr/lib/libsqlite3.so . Provide that path to the API when opening/creating a file, and everything works great.

That won't work if the probe VI doesn't update its FP until called again. It'll take an XControl...or something easier and more maintainable and easier to provide support for, like launching a "debug panel" that runs in the app.

It's never worth the effort to create (and then maintain) an XControl.

Yeah, if I can't update the probe's UI, it's basically useless to me. (The probe, that is.)

Custom probes only update when the execution path runs through them, right? I have a custom probe that peeks behind a DVR and exposes lots of debugging information about the daemon VI the DVR is shared with. My application touches the DVR once and moves on, meaning the probe only updates that one time and then fails to give me information about the daemon later. How do I design the probe to continuously update without the app execution passing through it repeatedly?

It was Nagle. Summary: Connection issues between two machines because of extremely short timeouts on the TCP Open/Listen functions and the STM Metadata functions. Packet buffering issues because of the Nagle algorithm. Thank you guys very very much for all the help!

That's definitely happening, and it's the first-tier cause of my headache. I need to get heartbeating working consistently again. Huh...that's good to know. Is there a way to check the buffer without popping from it? I could add a check-after-read while debugging to make sure I'm getting everything I think I'm getting.

Actually, I'm using a patched version of STM where I fixed that issue by changing all TCP reads to BUFFERED mode. So that's not a problem. I do successfully read in a simple test VI with a large timeout, but debugging in my application which requires a heartbeat in each direction every 250 ms makes the whole thing lag and choke. I'm going to try and write a more complex test VI that does the heartbeating without any other app logic involved. Let me look into that, too. Thanks!

Seems like a commit hook would have to run that back-saves to the repo version, then runs unit tests on a test server (using the repo version of LV) to make sure the back-saved VIs still work as intended. What a pain!

Thank you all for the help. It turns out that some of the TCP Read calls inside STM.lvlib's VIs were causing error 56 or returning junk bytes when I set the timeout too low. (e.g. "0 ms" in an attempt to create a fast poller that was throttled by a different timeout elsewhere in the loop). When I increased the timeouts on all TCP Read functions, my problems went away. Well, that's how it looks right now, anyway. Incidentally, setting a timeout of 0 ms works fine if I'm asking client and server to talk over the same network interface on the same PC. That kind of makes sense. Update: I'm now having serious problems with backlogged messages. I get messages out of the TCP Read buffer in bursts, and it seems the backlog grows constantly while running my app. This is breaking the heartbeat I'm supposed to send over the link, so each application thinks the other has gone dead after a second or two. Anybody know what might cause the TCP connection to lag so badly?

I used them for two years, and they repeatedly failed on their promise. Lots of errors thrown by the API that the application had to be protected from (including error codes documented only for Shared Variables?!), lots of issues with reconnection from the same app instance after an unexpected disconnection, lots of issues with namespacing endpoints, element buffering, etc. I never kept detailed notes on all of it to share with others, but the decision to use raw TCP was actually a decision to get the hell off Network Streams. Right, thanks. Glad to know that observation makes sense. Now to debug the part where a connection is closed on the VxWorks target between "Listen" and "Read" for no apparent reason...

I'm not removing diagrams. If I take a VI saved with LV 2014 SP1 and try to open it with LV 2013 SP1, I'm greeted with an error dialog that says I can't open it. So if modifications to my reuse library are made and saved in the latest version of LV, any existing project that wants to import those mods will have to be upgraded to the latest version. This can be catastrophic for some of my long-lived projects that are still running on 2012SP1 or even older.

A sage LV developer recommended that I stop building my internal LV reuse libraries into VI packages and just link to them from my project repos as git submodules. Sounds interesting, especially given how much work I put into creating, testing, distributing, and documenting VIP and VIPC files. I poked around with svn externals a little bit years ago and thought they were neat. So I went snooping around the blogosphere for awhile to see what git submodules are all about. Submodules in git are pointers to a specific commit in a repository at a specific URL. This is evidently different than externals in svn, but both are intended to solve the same set of issues. http://somethingsinistral.net/blog/git-submodules-are-probably-not-the-answer Right on! #2 seems right up my alley. However, everyone in the git universe abandoned them over the last couple of years because of several issues with brittleness and complex git workflows. https://github.com/cristibalan/braid Still, I can't help but wonder if these complaints would be minimized in my use case. Then a really important, LabVIEW-specific issue hit me: LV code is compiled to its version, and it can't be opened by an older version of the LV dev environment. I wouldn't be able to push changes made in a local submodule back to the remote library repo unless my code were back-saved to the remote's version of LV. (For example, I made a pull request against NI's STM repository recently but had to leave my code in a later version than theirs.) How the heck do we use tools like submodules/externals and the fork-pull workflow without being forced to upgrade all our LV code to the latest version (and re-test it, often against RT or FPGA hardware) every year when NI releases a new runtime? That's a dealbreaker for me because of the risk involved in upgrading existing projects to new drivers, runtimes, etc. (I've seen bugs introduced with a new version of LV that broke previously working code.)

I have a small LV code library that wraps the STM and VISA/TCP APIs to make a "network actor". My library dynamically launches a reentrant VI using the ACBR node that establishes a TCP connection as client or server, then uses the connection to poll for inbound messages and send outbound ones. When I try to establish a connection using my Windows 7 PC as the client and my sbRIO (VxWorks) as the server, it connects and pushes 100 messages from the client if the server was listening first. If the client spins up first, sometimes it works and sometimes I get error 56 from the "TCP Open Connection" primitive repeatedly. Other times I've seen error 66. When I try to make Windows act as the server, the sbRIO client connects without error, but it returns error 56 from "TCP Read" on the first call thereafter (inside "STM.lvlib:Read Meta Data (TCP Clst).vi"). This happens in whichever order I run them. This test, and all others I've written for the API, works just fine when both client and server are on the local machine. ------------------------------- I'm tearing my hair out trying to get a reliable connection-establishment routine going. What don't I know? What am I missing? Is there a "standard" way to code the server and client so they'll establish a connection reliably between an RT and a non-RT peer?

I do mark them binary in my repos. You can't even manually merge most changes because there are interrelated tags and mystery hashes designed into those file types. They aren't "pure" XML.

If you're the only developer, sure. But merging changes to any of the impure XML files NI uses (.lvclass, .lvlib, .lvproj) or to the same VI is basically impossible. I've always ended up just stomping on one developer's changes instead of trying to merge them.

http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/# He calls forward lots of niggling doubts that I've deliberately squelched over the last few years, but I can easily recall a time when trying to learn gitflow that I paused and asked myself, "Is SVN really so bad that I'm spending my evenings trying to do this instead?"

Glad to hear it! For my own needs today, I found an MGI API that wraps .NET's System.IO.Compression and seems to work fine.

I'm building a 64-bit binary using LVx64. My build tool uses the ZLIB package. I could change it to use the command line, but that complicates distribution of the tool. A counter to your post, since we're questioning one another's motivations (or possibly justifications for making a request?): What use is this information anyway? Am I missing something obvious?

Rolf, I can provide some testing in Win7x64 with LVx64 if you need it. I'm in dire need of an update to the OpenG ZLIB package for one of my build tools.

Is this where I revive discussion of ZLIB support for 64-bit LabVIEW? Because I need it.

Sorry for not replying to update everyone. I have some quick and dirty code working to create junctions (a type of folder-based symlink in Windows NTFS) from specific config and data paths to my Dropbox folders. I'm not looking to share anything related to build or things that should be in a project repository; just general config and customizations. I started work on the code to detect and remove the junctions so the user can "unlink" a computer/VM, but it involves UAC elevations and a bunch of calls into the file system to figure out whether a given path is a reparse point or not. I'll post the proof of concept here when I have it working (or the final state of it if I don't finish before Christmas, so someone else can pick it up and keep poking at it).

Has anyone put effort into defining a roaming environment configuration for LV? I work on several virtual machines, and keeping my LV settings, probes, glyphs, QD extensions, labview.ini tokens, etc. consistent across all of them is a nuisance. I'd like to put all that stuff in Dropbox so it syncs automatically. Are there known drawbacks or existing tools I should know about before I funnel several hours of tinkering into it?

Accepting both and outputting the spec-conformant version seems like the right thing to do, especially if that version is smaller and can be modified by the application to add escaping for that character as needed.

ShaunR, is this thing still alive? I'm curious about using it on a VxWorks target, since common (non-NI) libraries like 0MQ and nanomsg aren't available for that OS.