Jump to content

hooovahh

Moderators
  • Content Count

    3,015
  • Joined

  • Last visited

  • Days Won

    214

Everything posted by hooovahh

  1. There's lots of examples of this posted on NI's forums. Here's one I've been using for a while: https://forums.ni.com/t5/LabVIEW/crc-8/m-p/580831#M272003 Note that if you are using this for the CRC calculation in an automotive CAN frame you may also want to add in the ability to skip the CRC byte location, as I've seen CAN-FD frames that have the CRC not at the last byte in the payload. In some cases the CRC stops being calculated once it hits the CRC, and in some cases I've seen the calculation skip this byte, and continue with the test. Also if you are doing this calcuation
  2. Currently NI's package manager is less suited to distributing LabVIEW reuse in NXG, when compared to VIPM in LabVIEW 20xx. This is partially because in NIPM the package must be built for a specific version of NXG. So a package made for version 3.0 can't be installed in version 5.0, until the creator of the package updates it and rebuilds it for version 5.0. For reuse to be more adopted in NXG, this limitation needs to be removed.
  3. Thanks for the info-labview quote, the decline of Silverlight and NI's inability to pivot is a shame. Especially when posts by NI on the forums hinted that HTML5 features would replace Silverlight tools. I interpreted that as being transparent to the users of their systems. Like update to the newest version of MAX and all the tools that did use Silverlight have been replaced with their HTML5 equivalent tools. We are 5 years after that post, and it is a shame that remote front panels still use a technology so unsupported. Also you do know those last two links are April fools jokes righ
  4. Unrelated - Nice mouse I have the same one. Well I did until I left it at the office just before a stay-at-home order.
  5. Oh you're drugging up more of my old complaints. WebVIs were to me the most important bullet point to use NXG. Today almost all of my non FPGA code is written to work on Windows/RT/Pharlap/Linux/Mac. I try to do my best to not lock it down to an OS as some arbitrary limitation. So when WebVIs came around I figured I'd just think of it as another target, and the same VI for Windows can be used for WebVIs...nope. New file extension, and various limitations. The reason for this is that the controls on a WebVI aren't the same controls as Windows. The WebVI controls are HTML5 compatible cont
  6. In the past I've brought up issues like "You aren't listening to our feedback on the UI". And someone at NI reminded me that NXG started out very different looking. In fact (I hope I can say this) the UI actually had a ribbon interface for a alpha release or two similar to office products. NI claims they listened to our feedback and started over with the UI that contextually pops in on the right. In my opinion, I think that NI would have moved away from ribbon interfaces on their own, just because it had technical limitations, and didn't scale well. This this is an example of the users co
  7. Using NXG I don't feel like I am starting over, but do feel like I am programming with one metaphorical hand behind my back. I have been part of some of the hackathons NI has hosted at NI Week. There it was important for NI to see developers using NXG for the first time, and seeing what things they could figure out on their own, and get feedback on things. There was definitely more than one moment where I would call someone over and be like "Look I can't do this thing I always do in current LabVIEW" and they would write things down and without giving the answer they would hint that it was p
  8. (Thank Michael). I do see this as a slight issue. For now the new LINX is only in the Community Edition, so this one subforum will support both sets of topics. In the future LINX will be its own updated package on the Tools Network, and won't necessarily be part of the Community Edition. That being said I don't think we will be making another subforum just for LINX stuff. I expect the majority of Community Edition topics will be related to LINX, and splitting LINX into Community and Non Community subforums would only split the conversation up. For now the Community Edition subforum has p
  9. Funny you should mention that. LAVA has created a new subforum dedicated to the LabVIEW Community edition, and this thread (among a couple others) have been moved into it. Feel free to post questions comments, and information regarding the community edition there.
  10. Very good thread, keep up the discussion. I just wanted to chime in on one thing with my opinion. I think I understand what you are trying to say with this. But it seems with every version of LabVIEW, NI focused on at least having a couple important bullet points with every release. They likely have to split resources between current and NXG flavors, but just for my own categorization I made a list of features that seem important to me with each release. Looking over the release notes of each version of LabVIEW it is clear that each year lots of work goes into each release. Its ju
  11. Yeah I remember reading somewhere that the zero CPU is missing some instructions or features that LINX uses. I can't seem to find the thread at the moment.
  12. I'm not sure what goes on in the subVI, but I'm pretty sure that method is slower than 4 primitives. That's the major benefit of that method. Yes there is the draw back of having so many cases, but when they are buried in a subVI never to be seen, and the likelihood of having a cluster with more than 256 top level elements? I'd personally still prefer the VIM, given the trade off to performance benefit. But thanks for the alternative.
  13. Yup, looks like what I expected. I assume you mean avoiding non-NI XNodes in your code, because there are several people use all the time. That's fair and when all things are equal I do prefer a VIM over an under(un)supported technology. I do also agree that the number of files are large even for something simple. Anyway thanks for sharing.
  14. I don't have 2019 at the moment so I can't open yours. But is this related to the array of variant to cluster stuff? I made an XNode here that does this. The reverse is just a single variant to data with the data being a 1D array of variant.
  15. Thanks, great incite, and great suggestions. So far that means I see 4 possible solutions. 1) Use a non-strict VI reference and do the To Variant-To Strict VI reference dance I showed in the first post (this does work BTW) 2) Have the terminals be variants, then use variant to data with my class in the VI, and then in the VI with the Wait On Asynchronous Call. 3) Use a queue or some other reference to get the same data, without using the Wait On Asynchronous. 4) Tim's solution. I've gone with the Variant terminal solution 2. The calling and closing of the asynchronous VI is controll
  16. Okay so I have a normal class. In that class is a private VI that I will open a reference to and run it asynchronously using the Static VI Reference, an Open Reference by name, and a Start Asynchronous Call. All normal and all good. I realized I might want to capture the response from this VI once it finally returns in the Close so I keep the reference to this VI in the class. Now for me to be able to get the response using the Wait On Asynchronous Call I need to have the VI reference be strict, which includes things like the terminals used. Notice I have a coercion dot in the i
  17. Okay so I wrote some code back in the 2011 era for doing some graph stuff and never used it. As a result there are a few places that the code could take advantage of modern functions (limited events, array tunnels, conditional, and concatenating, VIMs, even Set and Maps) but in any case I have it here for others to take a look at and use as they want. I don't intend on updating this further. It all started when I found the built in graph controls to be limiting in terms of signal selection and control. I wanted a way for a user to select the signals they want and then show those on a g
  18. Oh also I found a .Net method of doing this. Using the Systems.Windows.Forms.Screen you can get All Screens, and in a loop get the Working Area of each. Still I prefer the non-OS dependent method posted earlier.
  19. There are two major schemes in SCC. Lock-Commit, and Merge. It seems most text based languages don't bother with Lock-Commit since an intelligent text merge can be done pretty easily. Since LabVIEW's VIs are binary, a merge can't really happen on a file level. The Compare and Diff tool NI has made does help, but I've found it at times to be messy. A more rigid approach is the Lock-Commit. This works best when an application has been broken up into sub modules, most often Libraries, or Classes. Then multiple developers can work on separate files at the same time, but lock them so that th
  20. Very neat. So I wanted to update this to return all monitors, and all Windows, and Panel sizes. I also saw that this was using scripting which means it won't be available in the run-time engine. Attached is an updated version that I believe does this. (2018) I also added a feedback node to return the previously read data if it is called again, with an optional input for a full refresh. I did this since I believe changing monitor position and resolutions after and application has started is rare. Still if you do this often you can just wire a True to this. Another option would be to use
  21. Thanks for your contribution. A couple of things. Using polymorphics for this type of thing can become a pain pretty quickly. I had a similar thing for reading and writing variant attributes and used scripting to generate the 60+ data types I supported. But even then there were times that the data type wasn't supported. This also added 120+ extra VIs (read/write) adding to loading overhead. The more modern way of doing this is with a VIM that adapts to the data type provided. Your VIs were saved in 2015 when VIMs weren't an official thing, but you say you use 2018 where it is. Back the
  22. So I just discovered this, this morning and I think it will help out in making VIMs when dealing with supporting a scalar, or 1D array data type. I have an example which is my Filter 1D Array VIM, posted here, which is heavily inspired by OpenG's implementation. In it the developer can filter out a scalar, or a 1D array of something from a 1D array. I did this by adding a Type Specialized structure at the start which checks to see if after building the array, if the data type matched in the incoming array. If so it is a scalar and should be used. I then have another case where the dat
  23. Far from perfect, but what I have at the moment, is on Mouse Move, Mouse Down, or Mouse Wheel event (with the limit to 1 just like you), read the Top Left Visible Cell. This gives the Tag and Column number. Using a second property node, write the Active Item Tag, and Active Column Number to what was just read. And then read the Active Cell Position Left. I then use a feedback node to see if the Top Left tag, Column, or Cell Position Left has changed from the last time the event was fired. If it hasn't do nothing. If it has, then go do what it takes to either shift the current image up an
  24. Well that or some really complicated stuff is happening. Here is a UI I've been working on lately. It is the view of a sequence that is currently running. On the left is a green arrow that moves to whatever step is currently being executed. Next to this is Goto arrows showing that a step has a condition that might jump to another step. Then there is the tree control that shows the sequence. In it is the step name (I blocked out many) then two columns that show some settings on the step with icons, and a column for a comment on the step. To the right is detailed information abo
  25. You probably already know this, but property nodes have a larger performance hit than a local variable when just the value needs to be updated. But if you want to update it in a subVI I get why you might use property nodes. The alternative there is to use the Set Control Values by Index function. You can read the indexes of the values you want to update in an initialization step, then pass on the indexes, and values you want to update. Of course this exercise, and this topic has diminishing returns. I mean lets say I just update all UI elements, all the time, periodically. The time i
×
×
  • Create New...

Important Information

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