Jump to content

John Lokanis

Members
  • Content Count

    797
  • Joined

  • Last visited

  • Days Won

    13

John Lokanis last won the day on February 2 2017

John Lokanis had the most liked content!

Community Reputation

80

About John Lokanis

  • Rank
    The 500 club
  • Birthday 04/13/1970

Profile Information

  • Gender
    Male
  • Location
    Seattle, WA
  • Interests
    Music, Fly Fishing, Snowboarding

LabVIEW Information

  • Version
    LabVIEW 2015
  • Since
    1993

Contact Methods

  • Twitter Name
    @jlokanis

Recent Profile Visitors

4,402 profile views
  1. Does anyone know if there was a change in the format of the NI Week conference this year? I am presenting and my session was scheduled for Monday afternoon. I don't remember there being any sessions on Monday other than for Alliance members (of which I am not). Seems odd. Anyone have the scoop on this?
  2. Looking for info on the BBQ signup this year. Google came up empty. Is it still happening?
  3. And they spelled LabVIEW wrong. Not sure if this person intended to use this for the same purpose you are intending.
  4. Back to the original topic: What is the best way to share reuse code that other code depends on? My reuse code is deployed in user.lib so that it appears in the pallet and can be found by quick drop. I have seen some suggestions that reuse code should be in the project folder for each project. This seems to be more portable but then leads to multiple copies of the same code on your system, making maintenance difficult. Another issue is using SCC with code in the user.lib. You don't really want your SCC system to be placing files in your program file directory. So, you end up with storing the code elsewhere for maintenance and then needing to package and deploy it after each edit. This make adding new functions and fixing bugs cumbersome. So, what solutions have others used? What are the tradeoffs? And what process should we adopt for reuse libraries we wish to share online? I would like to find a solution where we can get the benefits of the code being in user.lib without having to keep it under the LabVIEW installation folders.
  5. That is a good point. The code I would want to share includes one-off examples, reuse libraries and full frameworks. Not sure how to deal with all the dependancies. It seems like you would have to first share all the reuse components before you could share the higher level projects that rely on them. Also, how should we be packaging the reuse libraries? VIPM packages? Source code distributions? Zip files? And what level of documentation and testing is going to be expected and accepted? I think we need to come up with a baseline of what shared code should include so it has some value and is not too hard to use. But I guess we could let the market decide that. I would still like to hear what everyone thinks is needed at a minimum.
  6. One of the main topics of the 2018 CLA Summit was the need to improve access to open source code in the LabVIEW community. This is something that I have tried to do in the past with limited success. After hearing what others are doing and discussing the issues, I am inspired to take on the task of getting as much of my code that is shareable out into the open for others to use, improve, learn from and critique. So, the point of this thread is to figure out how best to do that. I have tried posting code to forums in the past. I have even posted to the code repository here on LAVA. I have used code posted here and via the tools network and VIPM in my own projects. But I am not sure if any of those avenues are the right path forward for me. There was much discussion about different open source repositories on the interwebs that we could leverage. There was also some discussion about how to help others discover the code you shared. What I did not hear was any definitive conclusions on how best to do this. So, the point of this thread is to try to solicit feedback on code sharing and come to some sort of consensus on the best options out there. If you have an opinion on this please join the conversation and share what you think is the best solution. Here are some questions I am trying to answer: 1. Where should we share code? What system works best for LabVIEW code and is user friendly enough to not discourage people from using it? Please share links and how-to documents for your preferred site/system. 2. How should we license code? I heard some discussion about the various type of licenses. I am not interested in retaining any rights to code I share and do not want to put any burdens on those who want to use and learn from any code I share. What licence is accepted in the open source community that supports this kind of sharing? 3. Once we post, how do we make our code discoverable? Do we need to post links all over the place or is there a better way? Here is one attempt at making that better you should check out if you have not already: I am not just interested in putting the code out there, but also trying to explain why I think it is worth your time to take a look. I am willing to post on forums, create a blog, even produce some vlogs on YouTube if it is the best option. Please let me know what format would motivate you to take the time to learn about the open source code out there. Either way, thanks for taking the time to read this thread and contribute what you can, even if it is just to follow the discussion and learn from others like I am trying to do. -John
  7. Did they forget to use their 'Where's Jeremy' app?!??
  8. We will miss you. I hope to attend both, but with the move to the later half of the week, if I go to the summit, I will have to miss the last day. :-(
  9. I can't seem to find the post or links to sign up for the LAVA BBQ this year (2018). Is it still on? Thanks for any info...
  10. I'm in! Looking forward to having BBQ and great conversations while not sweating to death in the process for once...
  11. I want to call my installer I built from a project in silent mode. (arguments: /q /acceptlicenses YES) But if the installer has no changes to install I want it to skip silently. Unfortunately the behavior I am seeing is the installer will run and reinstall everytime in this mode. Does anyone know how to get it to try and skip silently if there are no changes needed?
  12. Confirmed that the firewall kills stale connections after 1 hour. I'll add a timestamp to refresh the connection if it is over 55 mins old. Still want to know why the timeout for call by reference is so long. It appears to be 60 seconds and there is no way to change it.
  13. No proxy but there may a firewall. Need to talk to the IT guys. Keep alives would work but the system is not designed for that and it would add to traffic. Especially when across large distances with limited pipes. I wish there was some docs about how long the call by ref timeout is and how to control it. Another option is to store a time-stamp with the refs and refresh them if enough time has elapsed. Wish there was an easier solution.
  14. I could make a simple VI, but there is not much to it. Open app reference followed by open VI reference followed by call by reference. Save the app and vi refs for later. Then wait awhile and try to call the remote VI again with the cached refs. I am sure that IT is to blame for my open connection going bad, but I can't really control them and just need a way to recover quickly. I don't want to incur the cost of opening the app and vi refs for every call. Looking for an alternate solution.
  15. I am running into an issue where my VI Server connection goes stale after a few hours. Looking for a fast way to detect this and recover. Currently here is what I am doing: On first call, open the application reference and then open the VI reference. Cache both of these. Use the VI reference to call the remote VI. On subsequent calls, test the cached references to verify they are still valid and then call the remote VI. What appears to be happening is the references still appear to be valid in the caller but the connection is broken so the remote call fails. Then I detect this and reopen the app and VI refs and can again call the remote VI. The issues are: The failing remote call takes a long time to timeout and I do not see how to control this timeout. The test of the refs does not actually test to see of the network connection is still good. The result is it takes a long time to recover and this is upsetting the user since it appears the system is locked up. What I need is a way to control the timeout of the 'call by reference' node or a way to quickly test the references to verify the network connection is still good before I attempt the remote call. Any ideas? thanks, -John
×
×
  • Create New...

Important Information

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