JodyK

I'll be there. Xtal says I missed out in the past...

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

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

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 others are "warnings" or "errors". During run-time (even in an executable) the level of the logger can be changed and you can easily do trace-level debugging for a glitch, and then set it back to an informational level afterwards. Multiple targets are supported, including RT console, log files, TCP/UDP streams, and email. All the calls are made asynchronously, so the debug statements have a minimal impact on the code execution. At this point we are finishing and polishing the implementation, but more information and details can be found in a blog post I recently wrote: NLog for LabVIEW: Logging done properly -Jody Koplo

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 with the NI one. The MGI guys also said that the OpenG VIs didn't work quite right with waveforms and maybe one other data type. It looks like you ran into a lot of these issues in your other thread and went through the same process of replacing with OpenG VIs to get everything to work in LV 7. I'm also talking to the MGI guys about modifying this to use the OpenG VIs and then integrating it with the rest of the OpenG framework. Not sure they'll go for it, but I do think it would be useful. Who knows, maybe LV 2k9 will fix all the INI performance issues and make this a moot point... -Jody

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 them. If I sent you a piece of code I wrote with a locked block diagram would you want to stick it in your projects without being able to ever change it or know what it's actually doing? Besides, I'm not sure I would trust vi.lib code to be available in its current incarnation for the forseeable future... NI has challenged that assumption before (think reporting toolkit, etc) I agree that refactoring the NI VIs is probably not a good use of time. Though in essence this is kind of what the MGI guys did - reproduce an existing functionality with better performance. -Jody

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 it then be integrated into the OpenG toolkits or would MGI still have creative ownership over it? -Jody

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

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

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 regedit. Next the install asked me for a handful of other disks which I dutifully supplied: Feb2007 Drivers, NI-RIO 2.1.1, Feb2006 Drivers. This is from memory, but I think there are one or two others it asked for. My client ran the installer and everything worked fine. Until he needed to remove a USB-6009 device from MAX. For some reason even though he has the same version number of max, the devices were connected differently. I am including a screenshot of his system and one of mine to demonstrate. In his the USB devices showed up somehow related to VISA in mine they are USB devices. Next I attempted to build an installer with the full version of DAQmx 8.5 included, no other additional installers. As before it kept asking for disks - Feb2007 Drivers, NI-RIO 2.1.1, Feb2006 Drivers, NI-RIO 2.0.0, Labview 8.2.1, Realtime 8.2.1, ... I eventually just cancelled the build because it seemed like it was trying to include everything that I had installed on my system. I sent my client an installer with just the latest application built, and a link to download and install DAQmx 8.5 on his own. I really like the idea of the NI installer builder, but I have never gotten it to work effectively. Does anyone out there have any good experiences with it? Any tips to make it work more effectively? -Jody

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

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

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.vi (15.73 K) Deploying Check if File or Folder Exists.vi (7.26 K) Deploying nirviCommon.vi (38.10 K) Deploying nirviCommon.vi (already deployed) Deploying Instance 2 23EscapeDataLogging(Host) .vi Deploying Instance 1 23EscapeDataLogging(Host) .vi Deploying EscapeDataLogging(Host).vi Failed to download EscapeDataLogging(Host).vi LabVIEW: The VI is not in memory. LabVIEW: The VI is not in memory. EscapeDataLogging(Host) is the top level VI. I think that "instance" thing might be a little weird, but honestly I didn't pay that much attention to successful deploys. Other info: I recently upgraded to LV 8.2.1 I seem to still be able to deploy VIs that do not include FPGA code Deploying a known-good VI (one that I used early on to capture raw data but have not modified since) failed I upgraded all the appropriate modules from the latest development CDs - Real-time, FPGA, niRIO, Device Drivers I reloaded the latest modules onto the cRIO itself Anyone got some thoughts on this? Jody

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

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