Jump to content

All Activity

This stream auto-updates     

  1. Past hour
  2. Doubtful. You went from Git from SVN, I'm coming from Hg. In Hg, if you want to go to an earlier commit, you just go to that commit. If you want to make changes, then you make a new branch coming off at that point. If you like those changes, you might merge that offshoot branch with the main one. I have yet to find anything in Git over Hg that is actually useful. I consider the possibility of losing committed work because I didn't realize I was in an "anonymous/unnamed branch" to be a strong negative.
  3. Today
  4. I switched from Subversion to Git many years ago and encountered quite a steep learning curve but it was well worth it in the end -- Not having to be connected to the server all the time was a great boon. I haven't used Mercurial much, but from what I read Hg and Git were supposed to be similar to each other (at least when compared to SVN or Perforce) Yes, your choice of client has a huge impact on your experience. I find GitHub Desktop far too limiting; I like the power of SourceTree but I wouldn't recommend it to newcomers of Git -- too much power and too many options can overwhelm. Having said that, SourceTree supports Mercurial too. Perhaps @drjdpowell can use SourceTree to create and manage a Mercurial project, and then repeat the same steps for a Git project? This might help you to see the parallels between the 2 technologies and learn Git faster. Every single commit in the Git history can be checked out. If you ask git to check out Branch X, your HEAD now points to the latest commit on Branch X. If you ask git to check out Commit Y, your HEAD now points to Commit Y and is now considered "detached" (because it is not attached to a specific branch). To avoid "detached HEAD state", all you have to do is specify a branch when you check out. I have a use-case for entering detached HEAD state: Suppose I've made many commits recently and then discover a bug in my code. I want to go back to an earlier snapshot of my code, so I check out a commit that I think is good. Voila, I'm now in detached HEAD state and I can run my old code for debugging. When my HEAD is detached, I think of it as working on an anonymous/unnamed branch (a bit like how I can edit and run an unsaved VI, but if my PC loses power the VI is gone) Don't let the terminology discourage you; your journey will be worth it. Happy coding!
  5. Try GitKraken, it is not free if you want to access private repos on GitHub (which I do) but I really like the interface and does everything I need apart from showing the reflog which I believe Fork does show.
  6. The "detached head" is a good example of the problems with git: confusing terminology for something that has no reason to exist. Why does it even allow commits not on any branch to exist as a possibility, let alone something that is easy to mistakenly do?
  7. The problems I've had have mostly been using SourceTree. I've started to just us TortoiseGit, but it is lacking compared with TortoiseHg that I used to use.
  8. I have recently embarked on this same journey and also found things to be way less intuitive than Hg. Which client are you using? I found GitHub desktop awful and am now using GitKraken which I really like. Just a few days ago I "lost" some work by rolling back to the "wrong" commit. I was able to get back my commit by reverting to the commit using the hash which can be found by running: git reflog I seem to get into a Detached head state quite often. No idea what I am doing wrong but have sort of figured out how to recover from it. Was not able to see the commits from another user for love or money. Turns out somehow the "upstream" on the remote (whatever this is) was not set correctly Anyway, stick with it my friend. The war is over and git has won...
  9. I've switched to Git from Mercurial recently, and my opinion of it gets worse and worse. The number of times I've gotten stuck trying to figure out how Git got screwed up and how to fix things is way too high. Mercurial had similar issues when I first learned it, but it was an order of magnitude less than Git. Git seems to make the simple unnecessarily complicated and non-intuitive, with any step wrong leaving you in a position of not being able to fix things. with horrible gobbledygook error messages and blank stares on my part. So I must be doing something wrong. What should I read up on to make Git less crap?
  10. Does anyone use Cyth SQLite Logger? In particular, does anyone use it with Actor Framework or DQMH or similar frameworks. This logger was written by me years ago and I use it often, but in Messenger-Library based applications. I would like to know if it works properly in those frameworks. It should, I think, as they use similar Async-Called VIs as Messenger Library (Cyth SQLite Logger identifies the Async-running "actor" that makes a log entry and records it).
  11. I've seen that with clients I have been working for on LabVIEW related projects. A new software development manager came in with a clear dislike for LabVIEW as it is only a play toy. The project was canceled and completely rebuild based on a "real" PLC instead of a NI realtime controller. The result was a system that had a lot less possibilities and a rather big delay in shipping the product. Obviously I didn't work on that "new" project and don't quite know if it was ever installed at the customer site. That said, we as company are reevaluating our use of LabVIEW currently. We have no plans to abandon it anytime soon, but other options are certainly not excluded from being used whenever it makes sense and there have been more and more cases that would have been solved in the past in LabVIEW without even thinking twice, but are currently seriously looked at to be done in other development platforms. And I know that this trend has been even stronger at many other companies in the last 5 years or so. My personal feeling is that the amount of questions in general has dropped. The decline is less visible on the NI fora, but all the other alternative fora including LAVA, have seen a rather steep decline in activity. Much of the activity on the NI fora tends to be pretty basic beginner problems or installation pericles and pretty little advanced topics. It could be because all the important questions for more advanced topics already have been tackled but more likely it is because the people who traditionally use LabVIEW for advanced usage are very busy in their work and the others are dabbling their feet in it, come with their beginner problems to the NI fora and then move on to something else rather than developing to the intermediate and advanced level of LabVIEW use. Also with exception of a few notable people, participation of NI employees in the fora seems nowadays almost non-existent and except the aforementioned notable exceptions, many times if an NI empoyee eventually reacts after a thread has stayed unanswered from other fora members for several days, doesn't go very much beyond the standard questions of "What LabVIEW version are you using? Have you made sure the power plug is attached?" and other such pretty unhelpful things. This is especially painful when the post in question clearly states a problem that is not specific to a certain version and pretty well known to anyone who would even bother to start up just about any LabVIEW version and try the thing mentioned! It sometimes makes me want to tell that blue eagle (äah is that a greenie now?) to just shut up.
  12. Slightly related topic: I wonder what the trend looks like for the share of questions in the NI discussion forums marked as resolved. Based on my own posts there, it seems to get harder to find a solution to the issues I run into. I am not sure if that is just because the things I do in LabVIEW are closer to the borders of regular use / getting quirkier though, or if it is a sign of declining quality in the products involved. I suspect it is a mix of both. It would be cool if such statistics were readily available. A trend of the posting rate per forum/tag for example could reveal shifts in the interests of the users (the mentioned shift towards configurable turnkey solutions vs general application development for example) and/or the quality of the product. The latter might partially be possible to separate from the former by looking at the mentioned share of resolved issues; adjusted for the number of years of experience the questionnaires had (which perhaps could be inferred by how long they have been registered at ni.com and/or the number of posts or solutions made by that user...).
  13. Yesterday
  14. The DAQmx objects depend on the VISA version installed on the PC. Somewhere between 2010 and 2015 there was a change and recompilation was required.
  15. I sorted all the extracted LV14 files by size, and one stands out. Size of Block Diagram in XML form: 15MB And the size is not due to some binary blob stored inside - no, the is just a lot of parts in the block diagram heap. Amount of XML tags: # xmllint --xpath "count(//*)" ex_allChanPropsMod_BDHb.xml 234903 File: vi.lib/Platform/express/ex_EditUserDefinedProperties/ex_allChanPropsMod.vi And its content isn't even that impressive: There are just a lot of cases hiding in the "Case Structure", and a lot of copies of the same chunk of diagram within each case. Also the file seem to have syntax errors? Is it normal that some library files from NI doesn't even compile?
  16. Last week
  17. I believe DAQmx and XNET have different timing mechanisms. This thread might contain useful clues: https://forums.ni.com/t5/Automotive-and-Embedded-Networks/XNET-Timestamp-and-Windows-Timestamp-Synchronization/td-p/3367619?profile.language=en
  18. Quick update. I can send data from my cRIO to an Azure IoT hub, from there pass it to an Azure Streaming Analytics job which pumps the data into an Azure SQL DB and also to a Power BI Dashboard. The pieces of the puzzle are starting to fall into place 🙂
  19. I think I may have figured it out. When I looked at the drop-down selector for the "Following" options for this post, I noticed something for the first time. It appears to be a warning message that something is wrong with my notification settings. When I click that Notification Settings link, I get to this page and I notice that Email notifications for comments on my posts, appears to be turned OFF. I'm not sure how that happened. I changed it to TRUE and hopefully, I start getting emails again.
  20. Hi @LogMAN and @Neil Pate. Thanks for letting me know. Actually, the reason I ask is because I want to be as responsive as I can to important threads on LAVA (e.g. that relate to VIPM, etc.), yet I don't seem to be getting an email notifications. This makes it very hard to do that, and might give the appearance that I'm less responsive than I want to be. Hoping we can figure this out...
  21. I've seen this behaviour many times. We use OOP and lvlibs heavily in our projects and unfortunately often run into those builder quirks. The fun fact is that sometimes the same project built on different machines produces different outcomes (on one it always breaks, while on other it always succeed, while on third it's 50-50 chance). I never really bothered to investigate and report this to NI as those problems are very non-reproducible. Going to your specific question aboutt VIs which end up outside exe (in no particular order) : 1. Check the dependencies between libraries. The builder hates circular dependencies between them (i.e. something in lib A depends on something in lib B and vice versa). Avoid them - usually the solution is to move the offending VIs between those libraries. You'll also end up with better code design, so double the profit. 2. Enable builder log generation (I think it's in Advanced settings) and see if you can make any sense of what it puts out regarding those "outside" VIs. 3. Try building on different machine. 4. Set "Enable debugging" for the build (also in Advanced settings I think). 5. Try to recreate the problematic VIs under new names - create the blank VI, copy the contents (block diagram) of the current VI, replace the calls. Do not simply rename the current VI and do not Save as..., both of those might retain some hidden problems inside the VI. Also,try to change reentrancy settings and try to make them inline. 6. Try to recreate callers of those problematic VIs in the same manner as above. 7. Separate compiled code from the VIs. 8. On the contrary, do not separate the compiled code. Try to do both and see if there is any difference. 9. Last resort - put the contents of the VI inside the caller.
  22. I've never seen this kind of behavior. Only support files like documents, shared libraries and the like are supposed to be placed outside the executable, but I presume you mean VIs. This is very strange.
  23. Sure, that's basic (always dangerous to say though, in case I have overlooked something else silly after all, it happens 😉). The lvlib and its content is set to always be included, and the destination is set (on source file settings) to the executable. The same goes for the general dependencies-group. The dynamically called caller of some of the lvlib functions on the other hand is destined to a subdirectory outside the executable, and ends up there as it should. But then so does lots of the lvlib-stuff - seemingly disregarding that is destination is explicitly set to be the executable. Correcting other usual suspects (read: additional exclusions) do not produce a repeatable solution either. Perhaps someone else here have observed similar voodoo though, and figured it out?
  24. I checked my email inbox and I haven't gotten any notification emails since ~October, 2019. I checked my spam folder. Anyone else not getting emails from lavag?
  25. Thanks for the quick response @LogMAN No problem @LogMAN. I enjoy a good rant, as much as anyone 😛 I try not to take it personally when it's about VIPM (even though it's been a labor of love for ~20 years), and honor everyone's good intentions to make their development tools better, contribute to the community, and get their work done as effectively as possible. Those are really good points about how to make the VIPM system tray service more configurable in terms of opt-in/-out. Honestly, we were/are trying to take a lean (MVP) approach and listen to people's feedback. That's also hard for developer tools, where people do want access to the whole Swiss Army knife of settings. So, we did our best to at expose those to users via config file settings. This discussion has been helpful, and I've gone ahead and posted an official KnowledgeBase entry to make sure people can find this easily, in case the high-level features don't provide enough granularity. VIPM KnowledgeBase: Disabling VIPM service (System Tray) startup when LabVIEW starts up Thanks again and keep the feedback coming! I'm glad to hear you're going to give VIPM 2020.1 a try.
  1. Load more activity
×
×
  • Create New...

Important Information

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