Leaderboard

Hi there, I had to use packed libraries (PPL). No problems... But then I also had to deploy my code with PPL's. As already known there are several issues noted http://labviewjournal.com/2011/10/packed-project-libraries-part-2/?relatedposts_exclude=99 out there. I wondered if there is a solution to this with 2013 but as far as I know : nope. If somebody knows a good simple way please let me know. While experimenting I found a way how to do it. I attached some code and am curious if it works for others too.... The setting was like this. I had a LibC and it is used in LibA. In LibB I had to use LibA and LibC. In the Main.vi I use LibA and LibB. It's a usual use case I hope . A library LibC used by two plugin's. Since Labview includes the lvlibp's in each distribution you run into a name conflict when using and deploying the lvlibp's and the exe in the end. The solution would be to exclude them during build. But this wasn't possible. It seemed ! Naive as I am I had a look on the build specs in the project files, and found an node called "Bld_excludedDirectory" but only for source distribution. I copied this entry from there to the spec for the PPL and ..... it worked fine! This came out at last. <Property Name="Bld_excludedDirectory[0]" Type="Path">../Shelf</Property> <Property Name="Bld_excludedDirectory[0].pathType" Type="Str">relativeToCommon</Property> <Property Name="Bld_excludedDirectoryCount" Type="Int">1</Property> So when the project is load into memory the build classes keep this info and proceed with it as with source distribution. (One draw back is, that when resaving the whole project or edit the build spec in the editor it is gone again ! ) It's now in principle also possible to have a custom exclude path for the build. then I had doubts: Am I doing something illegal? I hope no..... I hope I could help someone with this Info. Best Regards Barns LibALL.zip

As I stated before, the "write PNG file.vi" and "LV Image to PNG Data.vi" VI's are not supported in RT. I bit the bullet and wrote a VI using the OpenG library ZLIB Deflate VI and the MECC CRC32 vi. Interestingly, the OpenG external library deploys and runs on the RTOS. The ZLIB CRC32 vi produced a CRC value incompatible with the PNG spec for some reason. I was careful to init the crc input register will all 1's per the PNG spec, but the value produced differed from that produced by the "write PNG file" VI, so I switched to the MECC CRC32, which works. Perhap someone who has the time can figure out why the ZLIB CRC32 vi is not suitable for the PNG spec. The IMG_write_PNG.vi VI only supports 24-bit images. The array reshaping and insertion of a 0 column was used to insert the Filter Type byte at the beginning of each scan line. Here is the code: Here is a slightly updated version with some added U32 converts for the IHDR width and height (per the PNG spec) and a note about the filter type bytes:

You probably read ElijahK's presentation already: https://decibel.ni.com/content/docs/DOC-21441 However, did you know he added a 80 minutes video about it? : http://zone.ni.com/wv/app/doc/p/id/wv-3364 Amazing! What I would like to see now is an example of a Spaghetti code being converted part by part into such a project. You can call it "The evolution of pasta" Besides that, if the presentation didn't include NI measurements but rather a HAL that contains more general tools like DIO/AIO and different implementing cards while including the singleton design pattern and taking into account dependencies between DIO subsystems, for example, it would be perfect. Oh, NI should also speed up this video's internet connection. Thanks ElijahK.