Jump to content

odoylerules

Members
  • Content Count

    45
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by odoylerules

  1. 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.
  2. 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, repla
  3. 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
  4. 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.
  5. 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 switch
  6. 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.
  7. 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 r
  8. 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
  9. 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 t
  10. 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
  11. 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
  12. 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
  13. Out of curiosity were you ever able to finish and post this? I couldn't seem to find the thread if you did.
  14. 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 thi
  15. 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
  16. 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 compil
×
×
  • Create New...

Important Information

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