odoylerules

I have struggled with this as i get more and more into labview. In general i force my process to handle its own state and GUI's to handle their own state and ignore messages based on their current state. In other words, the "Move Slowly" message could be sent at anytime to the process, but since the process is in charge of its own state, it can always choose to ignore it. I usually push process states changes back to GUI's using the GUI's own message queue. So in general i don't use the Request Response structure so much as the always send and let the recipient of the message do with it will with the message based on its state. The Request Response option gives you a very loosely coupled system, but i'm with Mike that in most cases i have not found this method absolutely necessary. In general, i usually keep a copy of the process state in the GUI but i haven't found many situations in my current work where my process needs to know my gui state. In general i think of my GUI only as a way to send message to my process. I usually keep copies of any information the process would need to function in the process so that in essence the GUI could change but the process wouldn't need to. My GUI's are tightly coupled to my process but my process is not tightly coupled to the GUI. Others with more experience may have better suggestions. I don't know if you use CRIOs, NI embedded options, or even other remote systems, but one argument for sticking with your current method is that you are truly decoupled in that situation and it makes it easier to move your code to other platforms if necessary. That way you are only passing messages between loops/processes and not references which can't cross network boundaries and things like that. Just a thought, it may not apply to your situation.

This is kind of a tricky area with GIT source control. There are a lot of factors it depends on. GIT source control doesn't work the same as SVN and its hard to pull down a single file like you can in SVN without locally cloning the entire repository. which you can do with git clone/pull and then remove all the files except the one you want. Where would this file be "hosted"? Would it be on GitHub/Bitbuck, or some remote computer? If stored on GitHub/Bitbucket i believe you can provide a download link for individual files from their webpage, however this feature is not native to remote git repositories in general. You would then have to download this file using whatever method you prefer. A quick search came up with these threads that might be of some help to you. http://stackoverflow.com/questions/7106012/download-a-single-folder-or-directory-from-a-github-repo & http://stackoverflow.com/questions/3642143/get-a-single-file-from-a-remote-git-repository http://stackoverflow.com/questions/160608/how-to-do-a-git-export-like-svn-export If you have a local copy of the full repository it appears you can parse the contents of a single file from the command line by using git show HEAD:$path_to_file I don't think this will work well for non text based files but should be fine for your config files. As far as method, if you only need to perform commands with the command line, then i might recommend using the "System Exec.vi" within labview. I have used this a lot to perform functions that require parsing STOUT from the command line. However, Python/C# obviously give you other capabilities for grabbing and parsing the file if needed.

....... I think a lot of people would disagree with that, but that's probably a topic for another thread

Thanks for the update. While i'm not using that the actor framework, i did copy the Launch Actor method you reference for opening up async processes in one of my projects. I'm not exactly sure why i did that but it appears that this might be a bad way to do things now. I'll have to go back and update that launch method. I was always slight confused why the actor framework used this 2 iteration for loop method but assumed it was a better way to do things.

I'm wondering if this behavior is related in anyway to issues we highlighted in this thread: http://lavag.org/topic/18009-lvoop-object-control-element-accessing-via-bundle-vs-property-node/ It appears to have the same symptoms of what i and a few others were seeing. A bundle by name was not correctly updating the data or was causing the IDE to crash. I have seen this same behavior before and was shocked when i too narrowed it down to a bundle by name. Mass compiles of my project were also causing a crash to desktop. My solution was the same as yours, step through the program, replace the bundle by name and problem solved. Nothing else changed.

I should clarify that... i still use it as a HAL layer as usually i deal with hardware, but i have moved away from full scale frameworks such as the actor framework or class based state machines b/c of some of these issues. I have moved away from class based messages as well and gone back to strings. I'm not trying to completely bash on LVOOP its very powerful, but as soon as you hit one of these IDE issues, the troubleshooting time becomes insane and make you regret your decision to go that route. I won't even get into how heavy labview classes feel. Right now i have a major project where one branch of the repository is totally corrupted with a strange object error that refuses to load the entire project. These are the type of things i don't have time to track down b/c of IDE issues.

I too am finding this the further and further i get into LVOOP. It seems like when deciding to use classes for a portion of a project, you really have to consider the other factors you mention more so than traditional LV. To the point that if you don't make the right decision in the beginning you can really hurt yourself way down the line with IDE and other issues. Lately I've limited myself to using classes mainly as fancy clusters b/c of these issues. Maybe its a lack of understanding on my part but it seems to be more hassle than its worth in a lot of cases.

All, Recently I moved from SVN to GIT as my source control and revision manager. I'm still getting used to everything so i don't consider myself an expert yet, but i really missed the Project Provider options that I used for SVN source control within the project window. I'm releasing an open source beta project provider for TortoiseGit Integration. This addon is very similar to the current SVN options but was developed entirely from scratch. Currently this provider requires TortoiseGit to perform most of the Source Control Actions. I know a lot of you on here have recently switched to sourcetree, however, unlike TortoiseGit they do not currently offer a command line interface yet for windows that i could find. I've tried to make this project flexibile and if they offer a command line for windows eventually it should be fairly quick to re-factor for that. The project can be found here: https://bitbucket.org/jed_d/lv_tortoisegit Addon Features Tortoise Git Icon Overlays within Labview IDE Tortoise Git Commands from within Labview IDE Ability to directly reload a project from within the Project Window, as well as prompts to reload the project when performing actions that require a reload. Open Git Bash from project window I'm hoping some of you will have a chance to try this out and let me know of any issues. I would like to track issues on bitbucket if possible so that they are all in one place, but i will also be checking these post for issues as well. Feel free to fork the project and hack on it yourself. If you come up with something decent and don't mind sharing, send a pull request. One initial issues i'm hoping the community can help with is building the package for older versions of LV. Currently i only have access to 2013 so i am only able to build the package for this version. If anyone has a change to pull down the repo and build it for older versions please do. Another question i have for the community is the license i currently have on the project. This is my first open source project of any kind so i wasn't sure what license to put on it. I did not want to be too restrictive so i went with a BSD license. If any of you see an issue with this please let me know as I'm open to suggestions.

Thanks Rolf, i was initially confused how labview loaded things into memory but your description makes sense compared to my testing. I think where things get complicated is when your are performing actions on classes or libraries. My current plan is to smart reload if the user chooses to perform an action on one of these items. I'm also debating if i should force close the VI if i should present a save option/force close if the vi is currently open when the action is performed.

Rolf thanks for the summary, this gives me a better picture of whats going. I don't have much experience with other IDE's outside of labview and webstorm. I have run into the dependency nightmare you mentioned and it is a huge pain. I'll have to give that a shot Thomas. I need to dig around and see if there is a VI server method for performing this revert. The reason i bring all this up is that i am currently in the process of writing an open source project provider for integrating TortoiseGit into the project window. All the basics are there currently and i'm hoping to release a beta for people to play with shortly. The long term goal is to bypass TGIT and integrate direct GIT Source Control into LV but since TGIT is already developed its a decent place to start. Currently i've given the user the ability to reload the project from within the provider and i'm just trying to solidify which actions are going to require a full project reload. It appears that basically any situation in which you are working within the project window and you need to revert or switch branches the user is going to have to reload the project to accurately see any Source Control changes. There are a variety of issues with this, such as saving after the switch or revert but those can be overcome with prompts to the user at the right time. Does closing a project, assuming all vi's are within that projects context and are closed, guarantee that all project VI's are unloading from memory? I'm really hoping a full LV restart is not required every time you need to reload VI's.

I personally have been using BitBucket as my hosting site, since unlike GIThub they allow you to have private repos for free. I found this link to be really helpful for getting SSH keys setup for Bitbucket. I didn't have a lot of experience generating and using keys before so hopefully it helps. http://guganeshan.com/blog/setting-up-git-and-tortoisegit-with-bitbucket-step-by-step.html

While agree merging can be pain, i personally find the way labview "loads" files into memory to be the largest issues with using source control within labview. Unfortunately for labview, if working within a project or library, this means that you must completely reload the project after branching just so that you can reload all the updates VI's into memory. Maybe i'm missing something but i can not seem to find a way to reload a single VI into memory. I think the main reason that GIT is so popular is that branching is so easy compared to other source control providers. Being able to branch, test a feature and then merge it back into your current branch is where git shines. All of those actions are extremely lightweight within the GIT environment. Its actually forced me to rethink how i treat source control. Like ShaunR i typically was using SVN as a backup/restore system. However, since moving to git i find myself branching a lot more. Like i mentioned, the LV VI in memory issues seems to be the main hiccup for making this process a lot more fluid.

Having just switched to Git versioning from SVN, i think it would be great for more of the LV community to get into the open source GitHub sharing paradigm. Or even just Git source control in general

This is what my current default .gitignore looks like..... *.aliases*.lvlpsBuilds~*.* Hosted here if anyone wants to pull it down or add to it. https://bitbucket.org/jed_d/labview-gitignore.git

I'm sure you all are aware of it, but there is a TortoiseGit option as well. It allows you to configure LVMerge/LVCompare exactly like TortoiseSVN and has the same windows integration. https://code.google.com/p/tortoisegit/ I personally just switched from SVN to Git source control and so far i like it much better. The ability to branch so easily is great for test code. The only issue is that you typically have to reload a project after a branch switch but this is a Labview issue not source control. I tried the Atlassian windows options since i also host code on bitbucket, but i found it too heavy and the TortoiseGit option was more familiar since i was coming from SVN. I'm actually getting ready to start work on a TortoiseGit project provider for integrating Git into the project window similar to the current SVN options. i'll post it in this forum once it gets further along.

Out of curiosity were you ever able to finish and post this? I couldn't seem to find the thread if you did.

I don't have a lot of details to share, but in the past i have specifically looked at the 0MQ labview driver for interfacing labview components with Nodejs. Since both languages are currently supported, it provided an easy, turn key method for passing data without having to develop the communication protocol from scratch. However, given the that labview implementation of ZeroMQ does not currently support VxWorks this was a dead end for me as i was really hoping to use NodeJS and the browser as the front end for my CRIO interfaces. If the 0MQ library could be updated to support VxWorks i think that would fill a gap for interfacing NI hardware with other software options. I had not yet looked at RabbitMQ as this was a quick side project. As a side note, i have been able to use low level TCP functions to facilitate nodejs to labview communication but as i mentioned it wasn't implemented as well as the ZeroMq library.

Sorry to dig up a really old topic but i was curious if anyone has experience reloading the project if you are not using Labview's integrated source control. I ask because i'm currently using the TSVN toolkit and obviously if you a revert, merge etc..., a file that has been loaded into memory, your source control updates are not reflected in the project. You are forced to close the project and reopen, sometimes even all of labview, to get your changed updated. I'm getting ready to swtich from SVN to GIT since branching is so much easier, which makes loading the project an effort that must happen a lot more often. Maybe this is a workflow issue, but currently i only develop by myself, so i could see this becoming an even larger issue when doing team development. Thanks for any insight.

LVOOP Assistant

That's very strange you posted this today. I had the exact same issue this morning and i was about to pull my hair out. I had a bundle by name that just seemed to refuse to actually accept the data that was being passed to it. I could probe the wire of the data being passed to it and see it was there, but when i probed the class wire after the bundle, the value was not updated. This was in Labview 2013. In addition, when i tried to CTRL-Shift-Run, labview would hard crash to desktop with no apparent error message. I assumed it was some very strange corruption happening on the compiling of the code. My situation was very similar. I was un-bundling data from Class A,another class in this case, reading a public value out of that class using a property node and then bundling that data back into the main Class A. The strange part was that i was i was actually bundling another piece of information into that class and it was being accepted but another was not. In the end, to fix the issue i had to use a completely separate bundle by name further down the wire. I can't seem to attach a pic of my code since this is my first post