Rob Calhoun

cross-reference: 32/64-bit compatible version of stdout writer for LabVIEW 2017. https://lavag.org/topic/20360-collecting-stdout-from-labview-when-run-from-jenkins/

Hi LAVA-ers, I'm finally implementing a long-delayed transition from our homebrew LabView build system to Jenkins. The best build-step option (for Jenkins under Windows) seems to be "Execute Windows batch command". My batch command looks like this: pushd "directory-containing-lvproj" echo "Running LabVIEW build process..." start "bogustitle" /wait "C:\Program Files\National Instruments\LabVIEW 2017\LabVIEW.exe" "Build.lvproj" "BuildJenkinsProject.vi" echo "complete, errorlevel %ERRORLEVEL%" popd where BuildJenkinsProject.vi is set to run when opened. BuildJenkinsProject.vi reads some environment variables set by Jenkins, sets up the builds (multiple EXEs and installers defined in a different lvproj) builds away. But my builds take a while, and I'd like to see the output from my logging system inside Jenkins while the build is in progress. Some Googling turned up these posts re: sending output to stdout from LabVIEW: https://lavag.org/topic/13486-printing-to-the-standard-output/ https://lavag.org/topic/11719-running-a-labview-exe-from-the-console/ I'm running LV 2017 64-bit, and none of the existing examples were handling 64-bit HANDLEs correctly, so I wrote a new version. This version uses only WinAPI calls (vs WinAPI + .NET), fixes some bugs, and it stateless, so you can call it anywhere in your code. Even when flushing the buffer after every write (which some on the Internet claim is necessary to get real-time log output; I am skeptical) it is plenty fast, around 10,000 lines per second. Since jdunham had previous written a fancy object-oriented logging system, I subclassed our logging system to write to stdout as well as the regular log. When I build from cmd.exe using the above batch file, it all works as intended. My problem: when Jenkins runs my batch file, I get something rather less exciting: nothing! E:\Jenkins\workspace>labview\Build\BuildJenkinsProject.bat E:\Jenkins\workspace>pushd "labview\Source\Build\" E:\Jenkins\workspace\labview\Source\Build>echo "Running LabVIEW build process..." "Running LabVIEW build process..." E:\Jenkins\workspace\labview\Source\Build>start "bogustitle" /wait "C:\Program Files\National Instruments\LabVIEW 2017\LabVIEW.exe" "Build.lvproj" "BuildJenkinsProject.vi" E:\Jenkins\workspace\labview\Source\Build>echo "complete, errorlevel 0" "complete, errorlevel 0" Not a big deal since I have my regular log files, but having gotten this far it would be nice for Jenkins to show work-in-progress. Any ideas? In the meantime, here is a stdout writer. (Released under MIT License, copy away.) -Rob Calhoun Attached: stdout writer function for LabVIEW 2017, and save-as-previous to LabVIEW 2012. WinAPI Write to StdOut Folder.zip

Hi Ton, You did a nice job with this! The code is both easy to read and easy to use. Was your library ever incorporated into OpenG? I did not see it there, so I downloaded it from the link above. It would definitely be a useful addition to the OpenG libraries. Thanks for sharing your work. -Rob

We use FireDaemon. As Swinders said you cannot have any UI when running as a service in Windows after XP/Server 2003. In the end we found the best way to handle per-instance configuration was to pass data in environment variables, which are settable in FireDaemon (which does have a UI for configuration) on a per-instance basis and easily read from the target application using a WinAPI call. If you want a free solution, try srvany from Microsoft.

Likewise we run our LV applications as services using FireDaemon and have not had any trouble reading from serial ports using VISA under Windows Server 2003, 2008, or 2008R2. (At least not any trouble that can be blamed on running as a service...we did have an issue where the Microsoft Mouse Driver identified our GPS device as a serial mouse!) -Rob

I've been working remotely for 10 years. Generally speaking you can get more code written out of the office but meetings / planning sessions / brainstorming are a bit harder and will require more effort on your end. Job interviews and other "managerial tasks" are particularly difficult. You are using a source-code control system, right? This is the most important piece of the equation, as in addition to all of the other benefits it takes care of synchronizing your code with others. Likewise your project documentation and bug-tracking system helps keep everyone informed of what is being worked on. Communication with your co-workers needs to have a low activation energy. You'll need to be on the phone a lot of course, but IM is great for quick back-and-forths. If there is a significant time zone difference, pick a time of day that is maximally convenient for both sides and block that out for collaboration. Don't be afraid to pick up the phone; get a headset and unlimited minutes on your phone or use Skype etc. You don't want to feel like there is a clock is ticking. For code reviews you need some sort of screen-sharing technology like gotomeeting. Written project plans (that are kept up-to-date!) become more important when you are off-site. If you have hardware you need to work with, you'll want a machine set up back at home with that hardware that you can connect to remotely. We use Microsoft's built-in solution (RDP) inside a VPN. Be super-nice to the people back at the office, since there is always the occasional need to have somebody plug in a cable in for you! Finally be tolerant when people call you in the middle of dinner etc. That's just the cost of working in a different time zone. Rob

I too have used LabSSH and concur that its developer is super nice and quick to respond to emails. However in the end we did not use it because of how it handled timeouts and because of the licensing, which was per-machine rather than per-developer. (We have separate boxes for development, test, build etc and that was just not going to work.) We ended up installing cygwin and shelling out to it using the LabView System Exec function. It's kind of a brute-force solution but it is free and it works great. That gives you access to all of the usual ssh functionality, such as using RSA keypairs instead of passwords. Note that ssh is not included in the "standard" cygwin install but it is easy to add. -Rob

Alas, poor LabView 6! I knew him, Horatio: an application of infinite fast launch time, of small memory footprint and most excellent stability! But, one cannot use LabView 6 forever. I think you have a serial port configuration issues. I am no great fan of VISA, since all I ever need to do is read from a few COM ports and it is horribly bloated for that. VISA's serial port implementation had more than its fair share of bugs over the years, but the more recent versions seem to work pretty well. I suspect you are encountering something where the default configuration changed, or your code was relying on some bug (such as VISA ignoring what you told it to do) that was fixed in later versions. What properties are you setting on the serial port when you initialize it? I would in particular check flow control and make sure that is correct for your hardware (that it works with some serial ports and not others sounds very much like a CTS/RTS issue).

Hi LAVA, We've been using a build system that uses multiple instances of LabView to execute the build process in parallel. Each build is single-threaded, but by running multiple builds one can use all the cores available on the machine. I posted some implementation details over on the NI forums, if anyone is interested. -Rob

We use subversion for both source code control and storing build products. (The cool kids are all using git or mercurial these days, but subversion is better in my opinion for binary files like LabView.) As long as subversion is using FSFS (the default) it works fine for multii-GB repositories with tens of thousands of revisions. Set "separate object code" flag on all VIs, and change the environment to make new VIs follow this. (It is annoying that LabView doesn't provide an easy way to do this; there are some workarounds posted on lava.) Otherwise, you run into "conflicts" that are really just recompilations. There are those who feel committing build products to a source code system is an abuse. To me subversion is just a distributed file system that provides a traceable history of what was put in when. It works very well for this. Putting builds in a different repository is one answer to complaints about repo bloat. -Rob

My comment above was written a year ago and refers to LV 2009 SP1. How did this thread get renamed "LabVIEW 2010 SP1"?

I have caught this three times "in the wild" but unfortunately I do not have a synthetic example. I am still working on it, and will post one when I can. You are correct. The LV runtime does not have a compiler in it, so yes, the object code must be re-integrated into each VI/control as part of the build process. I recommend you trash the object cache before building to prevent incorporation of any corrupt object code. (There is a VI Server method to trash the VIObjCache; it works in-process and it is fast.) We did have problems building projects that had "Disconnect Type Definitions" checked. Unchecking (which is the default for new buildspecs) and re-integrating the object code into controls programmatically before invoking the App Builder allowed us to build. (Builds failed two hours into the process with useless error messages; it was tedious to track this down.) But once built we have not seen any issues with the executables.

This issue is real, and I am working with LabView R&D on it. In the meantime, I have a workaround that avoids (as far as I know) potential block diagram corruption caused by separating obj code from source code. Quit LabView, delete everything in your VIObjCache folder, and then make your VIObjCache folder unwriteable with directory permissions. LabView tries to save the obj code and fails silently (yay!); as a result, when a VI or control is loaded from disk the cached object code is never found and it is always regenerated from the source code. This ensures the object code state is always matches the block diagram state. (After the initial compile, there is no speed penalty; whether freshly recompiled or loaded from the disk cache, the obj code is held in memory during execution.) The cost of doing this is significantly increased load times, especially for large projects. I view this as preferable to going back to recompile-only conflict heck. (And, obviously, it is much preferable to code corruption.)

I have more evidence of block diagram corruption as a result of using this feature. After modifying the type definition, a block diagram const array containing 11 type-defined enums was set to length 0 by LabView. I noticed, and therefore was able to recover my code by quitting LabView, trashing the object cache, and re-launching LabView. This makes the array re-appear. But if you run it in the corrupt state, you get an empty array on the wire, and (from my experience with another bug) if you modify and save a VI corrupted in this manner, you make the corruption permanent. We have already modified our build procedure to trash the object cache before building, but I am pretty close to throwing in the towel on this feature. It corrupts my code, which is completely unacceptable. If you're inside NI, I'm going to attached this to my previous CAR 277004.

Like Mark said, just set "Wait Until Done" = F and "Auto Dispose Ref" = T. But it's sort of a pain to get all of the details right with passing arguments. Jason Dunham and I wrote a library that handles most of the nitty-gritty of spawning off a new process, including passing arbitrary arguments via a queue that shares the clone name and taking care of the handshaking. We think this is a better (albeit more complicated) approach than setting control front panels because sometimes you want the caller to be blocked until the spawned process completes some specific action. Our plan was to clean it up for release it through OpenG, but there never seem to be enough hours in the day. (How does Jim K. squeeze 56 hours into his day?!?) Here is a screenshot of a fairly complete example as a teaser: