Jump to content

odoylerules

Members
  • Content Count

    45
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by odoylerules

  1. As someone who does a lot of javascript and nodejs programming. I use it all over the place and often wish Labview could parse it as well as some other languages.
  2. Its stuff like this why i don't develop a Windows target and RT Target in the same project any more. Locked classes/libraries are such a pain. I'm not sure that will solve your issue since it would still probably recompile on you. Do you know if the items that are recompiled happen to marked Read Only in the OS? That's caused me issues before on re-compiles and strange saves.
  3. Well partly yes, i do have an issues with this. However, i also have an issue with global dependencies and honestly there may not be away around that based on how labview was designed. I don't have as much experience with Labview as a lot of people here so i'm sure there are lots of use cases where it might be needed. However, i think there are two types of labview "packages". One would be your IDE extensions such as the G-code manager that you linked. These types of packages work well with VIPM and are good for extending the functionality of the labview IDE. However, i think projec
  4. I've considered writing one, however, i have a different philosophy on dependencies and prefer all dependencies not native to labview live underneath the main project file instead of sharing files across projects within user.lib and vi.lib. Pallets would be stored in the user libraries section of the pallet viewer and all pallets would be re-written to point back to the project specific dependencies directors instead of user.lib and vi.lib. Something feels really wrong having to rewrite program files directories to maintain dependencies. I've also considered using NPM, which is the nod
  5. I've been using other languages too much recently. I had totally forgotten about this thread and the general Labview name spacing issues. My dream of project dependencies solely within the project directly may be a dead one until NI changes some things. Even Git Submodules may not be a good solution b/c of the library linking issues highlighted in that thread.
  6. I've been thinking about this issue a lot lately and having recently been writing code in Nodejs, I've been considering writing a labview tool that mirrors some of the functionality of the NPM way of handing Nodejs dependencies. Unfortunately there are pro's and con's to both of the solutions your outline. I personally would avoid #1 at all cost. Checking in re-use code to your project repo is just asking for pain down the road. If you pursue this route, then i would recommend looking into Git Submodules. However, even those are pain to use but are probably a better route then checkin
  7. Welcome to LVOOP... this is one of my biggest gripes about using it for certain things. The work arounds listed above help, but using LVOOP design patterns can make some of the simplest things so heavy. LIke these guys mentioned before, you can make a new class that contains the shift register data of the NI method you want to use and write a custom method for the action want. Then include this class in your parent and pass it around in each child. This sounds like an interesting approach, but lately, LV2013 SP1, i keep getting burned by hacking around the call-by-reference nodes
  8. A tcp/ip server is going to be the most flexible, its just takes more to set up. If you do go with network streams have you seen this white paper? http://www.ni.com/white-paper/12267/en/ You have to set up your streams correctly otherwise you won't be able to connect. Also, i believe if you have to shutdown the "server" stream and re-open it if you want to have a new endpoint connect to it.
  9. He makes some good points but i would guarantee that there are a hundred articles out there that would argue against every point he makes much better than i could. I would say people just need to work with whats best for them. I use GIT and i'm sticking with it. The ease of branching is what made me switch from SVN. Making a branch, testing a change and merging it back in is fast and easy. I will say i do miss the locking aspect of SVN, especially since labview like to randomly touch files in the project.
  10. If this is really command you feel is safe for anyone to send at anytime to the CRIO, have you considered handling this "message in a separate loop on the crio that maintains some crio state information. Then you anyone can send the command at any time and if your CRIO is in a state that can process it, then process it, otherwise discard the message or queue it up for a later time. As far as implementing this i'm not 100% what to tell you. In all my applications i specifically avoid multiple host that have the ability to send commands. I'm not sure if a networked buffered shared
  11. I second Shaun's comment. I have found that using multiple network streams to connect to different clients becomes extremely CPU dependent for crio's, especially if you need fast updates. I'm not 100% sure what you mean buy " transform signal to sound ". I would probably recommend performing this action on the Host computer either way. I would push the raw data to the host and then do your transformation on the host. What i would recommend would be to make a single network stream that handles all the "commands" that the host might need to send to the CRIO. The benefit of this
  12. I've been looking at nodejs a lot lately. Its basically server side javascript. Lets you do the backend and frontend in the same language. Obviously you still need to learn HTML and CSS but i think the browser is the future for HMI and GUI's for most of my projects. Its hard to beat the amount of open source material there is out there for the front end browser experience. I still want to learn C++ for embedded stuff.
  13. This should be 2012 versions. As far as them being a CPU hog, i can't really comment on that. I'm not sure how fast you want to update or what your computer currently is but on most modern computers it shouldn't be too much of a draw. GraphTest.vi GraphUpdate.vi
  14. I was having a similar issue however mine were due to having the gui vi's i put into subpanels be reentrant. In general i've found strip charts behave kind of strangely and you can't really rely on them to update properly. In the end i ended up moving away from the strip chart and instead moving to a x-y graph. Basically i would maintain an array of points and redraw the graph whenever needed with new points. I have attached a quick example of how i did it. Hope it helps its in lab view 2013 SP1 Also, depending on how you are doing things you could simplify your array
  15. This is the real problem. To simplify my example i had two classes in a library. One was a GUI Class and the other was a Hardware class. I did this to group them together for ease of reuse in future projects. However, I had no intention of using the GUI class on the CRIO so when i re-used my hardware class, i had no idea that the gui class would become a dependency solely b/c they were both in the same library. My GUI class used subpanels and all sorts of things that CRIO's don't' like and was causing a hard crash out of lab view every time i tried to build my real time application (tota
  16. Does this happen at the very end of the build or when it starts? I've recently had a strange build error, unfortunately i didn't right it down, but it would occur at the very end of building an application. I tracked it down to a "read only" file SEH-RTEH-errors.txt located in C:\Program Files (x86)\National Instruments\Shared\LabVIEW Run-Time\2013\errors\ For some reason after every build this file was being set as "read only" and the build would not complete unless i manually unset this file back to non Read Only. In the end i had to write a script that i run before i build now.
  17. After finishing my first truly large scale Labview Project, i have also given up on LVLIB libraries. I've also given up on Xcontrol's but that's a different story. I still haven't figured out how that one xcontrol touched everything in my project after i completely removed it and never really used it. In my case i was trying to deploy code to multiple CRIO's and the cross dependency issues that you all have illustrated for libraries were wreaking havoc on my deployment. I had multiple instances of strange cross dependencies loading so much that by the end of the day most of my source cod
  18. I have seen this before as well and i couldn't track it down. There seems to be some strange issues that arise with the "Start Async Call" function sometimes. There is a thread on the actor framework board related to opening a vi reference twice and it causing issues with the async call. I'm not sure if this could be related to that at all. All i know is that there are some low level bugs that seem to pop up every once in awhile with it and they seem to come and go will not explanation :/ https://decibel.ni.com/content/message/91608#91608
  19. Bah, sorry i should have mentioned that... Also, i don't know if you are in windows or not. I really like using TortoiseGit for explorer integration for git. A lot of the folks around here also use source tree.
  20. So i use git as my version control and the thing you will find is that the issues you mention are inherent to all source control options within Labview. It just isn't built very well for this sort of thing. I would highly recommend continuing to use source control with it, but it does take some getting used to and can be a pain compared to text based languages. A couple of things i would recommend. Make sure you check the options to "Separate Compiled Code" within labview. This will save you a lot of headaches on commits due to basic recompiling of the source. Also, labview is
  21. Remember you said this.... LVOOP comes with its own set of troubles that i'm sure you will stumble upon in time. I'm not saying its not the better route, its just not the end all be all
  22. 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 w
  23. 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
  24. ....... I think a lot of people would disagree with that, but that's probably a topic for another thread
×
×
  • Create New...

Important Information

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