Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation


About JodyK

  • Rank

LabVIEW Information

  • Version
    LabVIEW 2020
  • Since

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'll be there. Xtal says I missed out in the past...
  2. Alright, I think I figured things out with regard to the VIs. I wrote two quick VIs to Pad/De-Pad the message input so that it can be divided into 16 byte blocks. I followed the PKCS7 standard (http://en.wikipedia....raphy)#CBC_mode). They're attached to this post. I've also been trying to workout an implementation of PBKDF2 (http://en.wikipedia.org/wiki/PBKDF2) in LV native code, but it's probably overkill for my application - there are much easier attack vectors... Hope these VIs help. Feel free to add them to the rest of the library. -Jody De-Pad Message String.vi Pad Message String.vi
  3. Could you maybe code a quick example of the AES in action? I need some guidance in terms of the key size and text size. From my initial poking it looks like I'm going to need to pad the cipher text and that keys need to be a multiple of 16? I'm not intimately familiar with AES, so a little guidance or some notes would be nice. Thanks, and I'm really happy to find a native implementation of AES in LV. -Jody
  4. I recently spent some time describing a logging tool that we use here at DMC that has significantly reduced our debug times and helped a lot with onsite support and I thought it was worth bringing it up to the LabVIEW community. Essentially, it's a logging utility based off of NLog that allows the user to add the equivalent of print statements to their code - any string that can be built is fair game. It also allows a logging level to be associated with the print statement and this is the concept that makes it extremely powerful. Some statements can be low-level "trace" statements, while othe
  5. QUOTE (Yair @ May 21 2009, 01:08 PM) I've actually been emailing with the MGI guys and it looks as though the "Get Cluster Info.vi" is actually an NI VI (my mistake). However the "Get Type Info.vi" is definitely locked. Luckily, it's really just a re-engineered version of "vi.lib/Utility/VariantDataType/GetTypeInfo.vi". If you replace the MGI version with the NI version, everything works fine, but it does run slower (300 msec vs 100 msec in my app, which beats OpenG's 3300 msec). There are OpenG VIs which basically handle the same functionality, but the enum for types doesn't line up wi
  6. QUOTE (Yair @ May 20 2009, 01:12 PM) The VIs I am referring to are "Get Type Info.vi" and "Get Cluster Info.vi" and both are definitely part of the MGI set. Looking at the VI hierarchy it actually appears that these VIs may just be some kind of wrappers around libraries anyways. The real issue has nothing to do with them being in future versions or any need to redistribute them. I mean, under BSD, they are out there and therefore can't be removed from public domain. The problem is my clients don't want closed source code from from outside the development environment. Can't say I blame the
  7. QUOTE (jpdrolet @ May 20 2009, 08:41 AM) Yeah, I came to the same conclusion regarding the Config File VIs. Luckily, they are not locked so they could be replaced with an OpenG version. I'm not saying it would be easy, but it would definitely be doable. Interesting note about the BSD license. I'm so used to the sourceforge and linux worlds where anything under BSD is always open source (or at least I can't think of any exceptions right now). How does the BSD license handle forks and derived works? In other words, if the locked MGI VIs were replaced how would that affect the project? Could
  8. I just found an application that strongly benefits from the MGI INI tools, but I'm nervous about the fact that the block diagrams are locked on two of the VIs. With a BSD license, doesn't the code have to be open source? Also, any word on inclusion of the MGI INI tools into OpenG? OpenG is approved for use in a lot of my projects, whereas using code from another source is a little more questionable and would require approval. Maybe I'll just have to reverse engineer the locked VIs... or better, improve the performance of the OpenG INI tool. -Jody
  9. QUOTE(chrisdavis @ May 7 2007, 06:48 PM) That seems like a VERY likely culprit in this case. Thanks for the info. I know of NSIS but have never really used it. Is it possible to make it install DAQmx without the user having to select options etc? Also is there anyway to use it with the smaller Runtime DAQmx installs? -Jody
  10. In general I shy away from using the NI installer builder, but I had a client specifically request an installation file for the program we developed. The program is rather simple - it reads analog data from two USB-6009 and graphs it on the screen with scaling and some other functionality - nothing too complex. The only additional installer I included was DAQmx 8.5 runtime 4 At first every build I tried to do kept asking for me to insert or provide source for NI-DAQmx 8.1; I haven't used 8.1 in quite some time. I eventually tracked this down to a handful of registry entries that I removed in
  11. QUOTE(george seifert @ Mar 21 2007, 08:47 AM) I am having the same issue with the installer builder looking for DAQmx 8.1 Using labview 8.2.1 and DAQmx 8.5 What did you end up doing to fix this? -Jody
  12. The issue seems to have been fixed after recompiling my FPGA code. My best guess is some update along the way changed how the FPGA and RTOS VI interact but since a bitstream had already been generated it didn't prompt me for a new fpga compile. Anyways issue fixed. I'll leave these posts up in case anyone else has issues. -Jody
  13. This is a strange issue from a debug sense. I've been developing a cRIO (9012) application and am pretty far along in development. I was at a customer's site developing with the cRIO in the full system loop and everything was fine. Running the system in targetted mode with no issues. Anyways I moved off the actual system and did 2 or 3 hours of developing in a conference room. Mostly code that handles USB and file management. When I went back to the system to test the new code, it wouldn't deploy. I have included the error below. ...Other Deploys... Deploying NI_FileType.lvlib:Get File Type
  14. Installing 8.2.1 on top of 8.20 breaks some libraries and VIs. Stuff that was needed for my source build. It is very easy to fix tho. Here is the NI note: http://digital.ni.com/public.nsf/allkb/C4B...62572B30068BF91 -JodyK
  15. I had an issue with upgrading to daqmx 8.5 and an executable with TDMS stores. It had to do with the 8.2.1 Runtime engine vs the 8.2 runtime engine. Also Daqmx 8.5 installs and old version (1.00??) of the storage VIs. I completely wiped all NI stuff of the machine and reloaded daqmx 8.3 and the 8.2 runtime engine and it worked again. -Jodyk
  • Create New...

Important Information

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