Jump to content

hooovahh

Moderators
  • Posts

    3,309
  • Joined

  • Last visited

  • Days Won

    253

Everything posted by hooovahh

  1. More information is needed. Is this a response to an ISO 15765 request? UDS, KWP2000, etc. Or is this periodically broadcasted frames? If it is UDS or something similar you'll need a CDD file to define how it should interpret the response. If it is a periodic message then a DBC file will define the structure of the data being sent, and what IDs belong to what data. I cover the Signal API and how bits can be interpreted in Part 5 of my CAN blog, and I talk about multi frame messaging in Part 8. If you are trying to reverse the CAN bus without this information, then I suspect you will have a very difficult time. There is an IEEE Float Data Type in the XNet Database editor which uses 4 bytes so it is possible this will do what you want. I'd make a database using the XNet Database editor specifying where in the frame the bits are and try using the conversion API with it. EDIT: Also I think Shaun is incorrect. 2 8 D5 0 0 0 0 B 5 70 I'm unsure what the 2 means but 8 means there are 8 bytes to read and the 8 bytes are D5 00 00 00 00 0B 05 70. 8 bytes is a common payload length for CAN. Double Edit: What are your expected values? I ran them through the IEEE conversion and tried Big/Little Endian but ended up with really large numbers both negative and positive.
  2. Write code that detects if the error is thrown, and if it is then close and reconnect. Honestly that shouldn't happen under normal use so I'm wondering if a reference is closed or lost somehow.
  3. I know right? I was looking for a 2D barcode generator not that long ago which is why I mentioned Darin's post that I found, which I presumed you had seen. I searched the forums a bunch and the only other code I found would send it to a website to get generated. I also saw a semi-hacky method using a Zebra printer API, but I never found that NI post either.
  4. Yeah sorry I haven't heard anything about a BBQ, and won't be attending.
  5. I've been using a few AIs in help for writing things. Professional sounding emails of sensitive subjects, work references, and a few other things to help get past a writing block. Image and animation stuff I see cool new things all the time, but haven't done much myself lately.
  6. Oh I get that you're welcome to post it here, I just wanted to link there so anyone here can see the conversation on the subject that has already taken place.
  7. Very cool stuff. I don't know much about 2D barcode encoding, but how does this differ from the code posted by Darin here? Yours looks more polished, but I didn't know if one encoding is better or if both are the same. My users generally don't care at all and just want something that if they scan types what is in the barcode and it seems my QR Code scanning app works with either.
  8. Thanks I figured the information I had was dated, or incomplete.
  9. If the data is accessible by the VI, I tend to stick with an unbundle. I heard that using a property node forces a switch to the UI thread, and it wasn't clear to me if that wasn't the case for class data or not, so I just avoid them if I can. That is one place that NXG did improve on the design of classes and clusters. A cluster was accessed with a property node like it was a class. This made the conversion from a cluster to a class easier, since the methods to access the data were the same.
  10. I posted my Image Manipulation code over on VIPM.IO https://www.vipm.io/package/hooovahh_image_manipulation/ Here is a video demonstrating some of its functionality, including loading an image into a picture box and manipulating it.
  11. Love it, thanks for the shoutout. There is plenty of room for improvement if you ever want to make this into a more polished API. I could see it reading the column width information, and working with the resizing of them. Thanks for sharing, I know I've seen a few requests for things like this in the past.
  12. I just moved it to Code In Development. I haven't tested this but native TIFF is pretty neat. When you feel development is in a good place you should post your package on VIPM.IO. Then it will show up in VIPM. The process for uploading packages is pretty straight forward, and you can link back to the Git for the source. In my Image Manipulation package there is a Load Image function which accepts TIFF. It also allows you to select which image from within the file if there are multiple in there. This all uses .Net image library and is less native, being restricted to Windows.
  13. Crap, it sure looks like it. I did lots of unit testing, but it didn't test for that apparently. Also note that if Indicies Ascending is true then it has the correct result. Version 3.0.1.15 has this fix on VIPM.IO. Thanks a lot for finding issues like this.
  14. I participated in the 2022 Q3 beta. And I see Christina mentioned preparing for the 2023 Public Beta on March 9th of 2023. Which is a bit odd since the mentioned release date of 2023 Q1 was January 2023, with the last update on the document being March 16th of 2023. I never saw a 2023 beta before it was released.
  15. This idea was implemented. https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Same-Height-of-Unbundle-by-Name-Terminal-Local-Variable/idi-p/1298608 Opening existing code will create bends in wires where there weren't any before.
  16. I just went to 2022Q3 64-bit about a month ago with a fairly basic program. USB cDAQ chassis with DAQmx and XNet on Windows 10. It had several classes, reentrant-ness, subpanels and data logging. I haven't seen any weirdness yet. My next step is to dive in upgrading our Linux RT remote controllers and our sequence editor, and report generation. This is a much larger project and one more likely to find issues.
  17. Thanks, that's it. I couldn't find it because I was searching for Completed ideas, but apparently it was declined. The Type Specialized Structure was in LabVIEW 2016, and was part of my NI Week demo that year. I frantically downloaded the Mac 2016 version, extracted the installer to get the VIM that contained the structure, so I could update my presentation and demo. When it was a Macro it was an XNode behind the scenes, and even the 2017 beta used XNodes. But in the official 2017 release it was its own technology. XNodes and Classes don't work well together, and locking libraries made editing them challenging so it was necessary to be their own thing.
  18. I do love how VIMs came to be. I'm having a real hard time finding it. But there was an idea on the Idea Exchange that there should be a function that can delay any data type, similar to the OpenG Wait which takes an error in and passes it out. Jeff K. posted on the thread saying something like "Oh yeah that is a thing, you just need to use a VIM, here is an example which uses XNodes." It blew my mind. Then in the next release of LabVIEW for the Mac, Jeff K. sneaked in a new VIM on the palette which some high up in R&D didn't know, which had the type specialized structure in it, which was also unreleased. I downloaded that version just to get the VIM and structure. I get the feeling the reason VIMs seemingly came out of nowhere, is that Jeff was pushing for it for years, and then when it was mostly stable he just put it out there to get the public's response. When everyone saw the potential that he also saw in it, R&D put efforts into getting it out there. This is just my speculation from the outside.
  19. I made a separate thread over here for array performance testing.
  20. OpenG made an amazing set of Array tools, many years ago. They weren't perfect but had many uses and I've recommended many times. Improvements to LabVIEW meant some of the array functions weren't well optimized. Years later I tried making a more modern Array set of tools using VIMs, giving up on Polymorphics. I posted this as a package over on VIPM.IO here. Since then I've thought about a few places where performance of my stuff could be better. Mads and I have had some discussions back and forth in this thread. But I wanted to make a separate post where others could chime in with their performance suggestions too. At the moment my Array VIMs are in LabVIEW 2018. However I think due to the potential Maps and Sets benefit, that I want to go to at least 2019. In 2020 LabVIEW added the Sorted Array subpalette with a pretty decent binary search. So for now I think LabVIEW 2020 will be what I target for the next Array VIMs package release. Any thoughts on this? I know there is a decent amount of bias in this, but Jim posted the versions of LabVIEW used on VIPM.IO and 2020 and newer covered over 75% of users. So attached is zip with a set of array testing VIs. For instance open the Remove Dups Speed VI and run it. It will run through the 6 different methods of removing duplicates from a 1D array of strings. It will then graph the different methods and do a check that they all return the same data. If you want to add your own method edit the (non-typed) enum, then duplicate a case and replace the function with your won code. It randomizes the order of the array methods used. You can also mess with the data being used. At the moment it generates 1000 unique elements, then duplicates them 5 times. If you want to enter data with none to remove, or all of a single type, or whatever then you can change the data to be used in the test. At the moment there are 8 different array speed tests to compare. Things like Delete 1D, Delete 2D, Filter 1D, Filter 1D with a Scalar, Reverse 2D, Search 1D, and the Remove Duplicates already mentioned. There might not be a single best method for a specific function. There are times one method will work better for some set of data, and then a decision needs to be made on what should go in the VIM. My main reason for making this thread is that I hope some people will know of a better way to do something. Come up with a more optimized way to do any of the OpenG array functions. After some discussion, and contribution I plan on updating the Array VIMs package and attribute those that helped. (crosspost) Edit: I just realized someone is probably yelling "Use Git" to me. I hadn't thought of that sorry, it just felt organic to continue the conversation here because it is where the topic started. 872707096_HooovahhArrayPerformanceTest.zip
  21. SubVIs that are called as a function, and don't have the terminals change value after entering the VI, should have the terminals on the root of the diagram, not in sub diagram structures. This is because the compiler can't know if these terminals changed value from the last time they were used, and so it will read them again. If it is on the root of the diagram it reads it when it enters the VI and never needs to read it again. Same with indicators. These should be on the root of the diagram and I think the CLD takes off points if it isn't. https://forums.ni.com/t5/LabVIEW/Community-Nugget-Wired-Terminals-in-Subdiagrams-Clearing-up-the/td-p/2093252 But it is a very minor thing, I just mentioned it as something I'd change, but not something I would expect to affect memory. I worked at Magna Electronics, Magna E-Car, and I think Magna Powertrain was in there somewhere as divisions changed and were absorbed. Making validation and verification test systems for various automotive components like running boards, inverters, chargers, power control modules, and cameras. Good times until it wasn't. I knew this was related because it gave a loading warning that VIs were loaded from a new path, and the old path had Magna in it.
  22. Those VIs are quite simple. If there is a memory leak in that simple of a VI then you need to open a support ticket with NI so it can be fixed in a patch. I see things I would change about the VIs, but nothing that should affect memory. Like the terminals should be on the root of the diagram for subVIs. (Also are you doing work for Magna? I used to work at a couple of their divisions)
  23. Oh I totally agree here and wouldn't suggest otherwise. All I'm saying is that specifically for the Filter 1D there is two main approaches. To perform the filter in a for loop running for all elements in the Filter Array, or running a for loop running for all elements in the Array In. If one is small and the other is large one approach will easily outperform the other, even if it isn't optimized. So maybe deciding which technique could be used based on the size of the Filter Array. Additionally I like the No Duplicates input, because there are often times when I'm filtering an array of numeric indexes, and removing 0 or 1 elements from each Filter Array element can make for lots of shortcuts. I tried optimizing your sort and binary search with this, but the benefit where much since I think the majority of the time is spent sorting the array for large arrays, and then the actual binary search is very quick. Similarly I've added the Array Is Sorted input to my Remove Duplicates VIMs. If you are removing duplicates from an array that has already been sorted there are shortcuts that can be taken that save lots of time. I think the Remove Duplicates I have is very slight improvement to the OpenG method, and I'll stick with what I have at the moment. However your sort, then work does give me an idea I'll test when I get time.
  24. That is pretty fast. I have noticed that on smaller arrays some of the other methods work better. Somewhere between 100 and 1000 elements the first Revision works better, then Revision 2. And the Hooovahh method with No Duplicates is faster then Revision 2 at at least 500 elements. I've also seen that with a smaller number of items to filter, other methods work better then Revision 2. Even OpenG beats it when there are many items, but only a few to filter. In most cases when I'm filtering an array, I have a relatively large set of data, and a small-ish array of things to remove. I'm finding it difficult to know what method is best for the most common use cases. Is it worth wasting some processing time reading the array sizes, and then picking the algorithm that works best for that size? The problem I see with this is various compiler optimizations may take place, making some methods faster or slower, with later releases of LabVIEW. Since my method basically is for all Items to Filter, and your method is for all Array In, I could say if the Items to Filter is 10 or less run the Hooovahh method. If it is greater then 10 use your Revision 2. If the No Duplicates is used, and the items to filter is 500 or less, use the Hooovahh method, otherwise use Revision 2. I'll think about it, but a hybrid approach might not be a bad idea, even if it complicates things a bit. I'd say of the array VIMs on my palette, Filter, and Remove Duplicates are the ones I most commonly use, so getting the most performance out of these would be good.
×
×
  • Create New...

Important Information

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