Jump to content

Rob Calhoun

Members
  • Content Count

    33
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Rob Calhoun

  1. 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/
  2. 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 rea
  3. 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
  4. 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.
  5. 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
  6. 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 wor
  7. 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
  8. 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
  9. 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
  10. 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 ju
  11. My comment above was written a year ago and refers to LV 2009 SP1. How did this thread get renamed "LabVIEW 2010 SP1"?
  12. 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" chec
  13. 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 alwa
  14. 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 mod
  15. 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
  16. OK, now I have some experience with this feature and my experience has not been so good. First the good news: you don't get dirty dots all over the place when you change a typedef. Yay! Also VIs are (a little) smaller. Yay! The bad news: The converter tool in the project doesn't work at all, but you knew that. It makes building an application slower and less reliable. I'm not sure how much of the speed reduction is just the (more complex) LV 2010 compiler, but it takes just under 2 hours to build our product now vs about 50 minutes under LV 2009. Sometimes the builder stops working (st
  17. We've been having a hard time building consistently. We build 5 related apps out of one project, and (aside from it being slow as the dickens) the builder frequently throws bogus errors ("can't save a bad VI without a block diagram") or just gets stuck. I didn't see this during the beta, possibly because I hadn't yet split source and object code on the whole hierarchy. (Blasting the object cache can fix it.) There are some workarounds but it's annoying. We're working with NI on the problem.
  18. So it turns out this is called a reverse proxy server and there are a wide number of free and commercial implementations. If your web service will still work through the proxy, this is a good solution.
  19. For reference Chris is referring to this tutorial: Tutorial 7749 The NI security model is weird. I looked into it and decided it was focused almost exclusively on granting access to an application rather than to a user in a browser. (I mean, sure, you could write javascript to generate the hash from security keys embedded in the javascript, but given that the javascript code is in plain sight, what is the sense in that?) What I ended up doing was using IIS and ASP for most of the web stuff. When I needed something LabView-specific, I used IIS as a proxy server. (Client authenticates with and
  20. The data types that can be passed via ActiveX are determined by COM, not by LabView. I'm not sure that there is a way to pass a cluster/struct directly using COM. You might be able to pass it as a variant type. That is the usual catch-all in ActiveX world. See this link. Or just throw a simple-types wrapper around your LabView function.
  21. I haven't had stability problems with LV 2010, but I've only just started using it. (I'm hoping it is ok, because I for one would really like to get a functional Suspend When Called again!) This "silent crashing" behavior started with LV 2009, and boy is it irritating. We eventually traced one cause of this to an excessively long type descriptor inside a class, but it was very difficult to track it down because of the total absence of failure logs.
  22. One of the most compelling features of LV2010 is the ability to remove the object code from VIs. This should greatly reduce the number of "recompile only" changes, which are a big headache for projects with multiple developers. Early in the LV2010 beta this feature was applied automatically across the board when upgrading; in the final build it is disabled by default and controlled with a Project switch. The Project Properties window has a "Mark Project VIs..." button that (theoretically) can be used to split up source and object code en masse. I found the "Mark VIs" button didn't work with m
  23. It did. I eventually figured this out by comparing a web service brought over from LV 8.6 that worked with one created under LV 2009 that didn't. (Of course I would have saved myself a day of hair-pulling if I'd just come back to LAVA to read your reply!) Thanks, John. I'm trying to write this up on the ni.com forums so that the build & deploy process gets improved in future versions of LabView. I haven't tried deploying on a machine that doesn't have LV on it yet. -Rob
  24. Any chance this LV 2009 Known Issue applies? They say it only happens when the properties page is open. http://zone.ni.com/devzone/cda/tut/p/id/9951#139588_by_Category On a mostly unrelated issue, I've been debugging a web service for the last day. It is very slow going. Simple stuff works, more complicated stuff simply doesn't. It just returns http error 404. The only hints are in the LabView_Trace.log in %CommonAppDir%\NationalInstruments\Trace Logs. I'm starting to suspect the Windows path limit of 255 chars as the problem: LV puts web services 4 directory levels down in %CommonAppDir%
  25. LabView mathscript's syntax is very close to Matlab's mscript. You should be able to run matlab code inside a mathscript node with few changes. However, it is more designed for running specific chunks of code as functions inside a LabView application than for running a monolithic Matlab program from inside LabView. Also, as of LabView 2009, mathscript is now an add-on package.
×
×
  • Create New...

Important Information

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