Jump to content

GregFreeman

Members
  • Posts

    323
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by GregFreeman

  1. To follow up, when I launched with "start /b /wait" I was then able to redirect my stdout from LabVIEW to a file. Before it would print to the console but it was like that stdout stream wasn't seen as the one that the start command was referencing because the redirect just left me with an empty file. start /b /w LabVIEW.exe <VI Path> > %USERPROFILE%\output.txt Haven't checked if Bamboo captures this yet, that is my next step. But, the fact that i can now redirect an output from the start command to a file gives me hope. If nothing else, I should be able to execute a loop on the stdout from LabVIEW and echo the response which I know Bamboo can get. FOR /F ["options"] %%parameter IN ('command to process') DO command Just in case it helps anyone else... Edit: Just confirmed, the /b option allowed bamboo to capture what I wrote to stdout
  2. Thanks, that direction should get me started.
  3. How did you go about writing to the output stream? I used the VI found here and it writes to the console, but it isn't captured by Bamboo (although my echod commands in my batch file are, so I know bamboo does get this stuff). I may just write to a file and have my batch script read from the file and echo its contents after the fact as James mentions but it would be nice if I could get it to update in real time and let the tool stick everything in its native log file. In the meantime, I will confirm Bamboo will get StdOut so I'm not chasing something that's impossible
  4. There is one case, however, where I have used this successfully. Functional globals inside a VIT seem to get their own "namespace" of sorts. This allowed me to launch multiple VITs but use a functional global independent to each one. (Ever wanted to reference the same timer in multiple cases in your code...now you can). I know this is unrelated to the original post, but maybe someone will find this convenient.
  5. I thought about this route but if it fails I wanted to be able to add errors to the file. I suppose I could do if finished and file doesn't exist, success, if finished and file exists, failed.
  6. What I am doing is launching LabVIEW from the command line, via a batch script that is called from bamboo. I have an input variable that is the path of the VI which does the build using the build API that ships with LabVIEW. Bamboo relies on the response from the application that was launched to determine a passed/failed build. I am now taking the approach my batch file waits for the call to LabVIEW to return, my build VI dumps a log file which holds success/failure inside, and my batch script looks at the file to determine a pass fail. Then, the batch script can return exit(0) or exit(1) itself, which bamboo captures. To get out of LabVIEW, I am fine with just putting an exit LabVIEW function in my VI that does the build, since this VM will be dedicated to builds. Whew. Edit: I did try launching LabVIEW directly from Bamboo. While this did launch LabVIEW, calling exit (0) or exit(1) from LabVIEW using the CLFN crashed LabVIEW. So, there was no way to tell Bamboo that the build failed or succeeded, as it would always fail. This is why I wrapped it in a batch script and let the script return 0 or 1. Edit #2: I am open to more robust ideas here
  7. I know this is old but I couldn't resist. The answer is yes. The person that did it: me, even when the ES was no longer new (although I was new at this time). I had no knowledge of right clicking and adding event case. http://forums.ni.com/ni/attachments/ni/170/363372/1/VI.PNG
  8. Thanks guy, good responses. This is the feedback I have been looking for. AK_NZ this is pretty much the route I have been beginning to take so that at least confirms I am on the right path. Danny, I don't have the same licensing issue luckily. But, I really appreciate those links. I hadn't come across them and they seem pretty valuable.
  9. Yes, the build can be finicky for sure. I'll see how this works out. Anyways, I am making some headway and when I have something that's at least somewhat substantial I'll post back with my findings.
  10. You're a week late. I just implemented one of these for a project (only for one data type). Would have preferred to use yours. The xnodes make this about a factor of 10 better than mine . If it's any consolation, I rotate the array as well.
  11. Has anyone here set up CI with Bamboo (or Jenkins?). I am working on this now (with Git) but starting with a blank slate with something you hardly know anything about is tough, especially with LabVIEW that doesn't have really any plugins available for it on this front. I would like to first start with just automating a build, then I can start adding in the more complex stuff like kicking back merges etc if the build fails. But, those things are a task I will tackle later.
  12. Really neat! Mind providing any insight on the gradients? Was it an intensity graph behind a transparent MC Listbox?
  13. For now, yes. Won't be a deep directory structure. If I build something that is to be more than a one-off subVI, I can consider other routes.
  14. Well that became trivial. Done in 10 minutes.
  15. I haven't. I'll give it a whirl. Was hoping to roll my own "real simple one" because I thought making it for a specific use case wouldn't be too big a deal. But it's proving to be more time consuming than I thought.
  16. Won't work because of string vs object formatting in JSON.
  17. I had another thought, since yes, I just need the JSON. Rather than make the children an array of by value nodes (which I can't because I'd have a recursive node cluster), I can make them an array of strings. I can go through recursive call, formatting all children nodes to an array of JSON strings and flatten that array to a single string to be passed up the stack. Then, I just have a bunch of nested JSON strings already formatted, and when I get to the top level, I can just do flatten to JSON string...I think... We'll see if it works.
  18. So, I'm just trying to recursively go through a directory list and build up a jsTree structure in JSON to send from a web service to a browser. But, I am having a heck of a time doing it. I was hoping I could just build this up into a cluster and pass it to the flatten to JSON function but for obvious recursive loading reasons that won't work because my structure will have an array of itself inside it as the children variable. When going the references route like you normally would a tree, I now am having a hard time going back up the call stack to build up the JSON structure. I could post what I have tried but I assume it won't be much help. I figured I'd just see if someone here wants to take a crack at it for me so I don't keep spinning my wheels. Feel free to scrap the li/a attributes for now. // Expected format of the node (there are no required fields) { id : "string" // will be autogenerated if omitted text : "string" // node text icon : "string" // string for custom state : { opened : boolean // is the node open disabled : boolean // is the node disabled selected : boolean // is the node selected }, children : [] // array of strings or objects li_attr : {} // attributes for the generated LI node a_attr : {} // attributes for the generated A node }
  19. Nice, I never even thought to try this. Ironically, I have often said to people, "I wish LabVIEW had callbacks support" (other than .NET and ActiveX like you noted). Well, whaddaya know...
  20. We have conquered this using DVRs, but unfortunately I didn't work on any of the projects that have done this, so I don't have a lot of familiarity with it. I'll see if I can get a chance to look at the work that was done and provide some feedback. As for the plots, just make sure you decimate the data.
  21. This is fairly inline with what I have been doing, and your third paragraph with regards to extensibility is what I have found as well. In fact, just yesterday, I tried seeing if a cluster of event registration refnum clusters would wire into the terminals on an event structure. Alas, I got a broken run arrow. Too bad those terminals can't recursively register through clusters of clusters of event registration refnums, or an array of them, or something so I can have a "get events" method that I override in the children, which calls the parent "get events" method and appends events then returns them all. Maybe this is unnecessary but I can think of a couple of places in my code it may prove useful.
  22. This thought crossed my mind the other day and I pinged AQ on it offline and got a good response. I just thought I'd open it up to the community as well. In more complex UI frameworks, they enhance UI reusability. For instance, with my limited text based experience I realize most frameworks allow you to create a dialog class that inherits from some parent dialog. You then, by default, get the onOK and onCancel methods. If you just have a simple dialog you don't have to do anything for these methods the parent method will just be called. And if you need something more complex, you can override them. After talking to AQ he pointed out that is because of dynamic event registration. I already knew we had the ability to dynamically register with controls but I never put two and two together. He also mentions this "for most UI deisgns, it is more work to pass around refnums and dynamically register than to just statically register. It is only when you start designing and inheriting UI frameworks that the balance of effort shifts in favor of dynamic registration." So, I guess I am just curious if anyone has gone the route of implementing things this way and found it beneficial? This is pretty much just an open ended question; just curious on people's responses. I just have found myself rewriting almost identical event cases in most of my dialogs, and was trying to mitigate the need for having to do this. That is what prompted this whole discussion.
×
×
  • Create New...

Important Information

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