Leaderboard

I have created a new package with an updated version of the OpenG ZIP library. The VI interface should have remained the same with the previous versions. The bigger changes are under the hood. I updated the C code for the shared library to use the latest zlib sources version 1.2.8 and made a few other changes to the way the refnums are handled in order to support 64 bit targets. Another significant change is the added support for NI Realtime Targets. This was already sort of present for Pharlap and VxWorks targets but in this version all current NI Realtime targets should be supported. When the OpenG package is installed to a LabVIEW 32 bit for Windows installation, an additional setup program is started during the installation to copy the shared libraries for the different targets to the realtime image folder. This setup will normally cause a password prompt for an administrative account even if the current account already has local administrator rights, although in that case it may be just a prompt if you really want to allow the program to make changes to the system, without requiring a password. This setup program is only started when the target is a 32 bit LabVIEW installation since so far only 32 bit LabVIEW supports realtime development. After the installation has finished it should be possible to go in MAX to the actual target and select to install new software. Select the option "Custom software installation" and in the resulting utility find "OpenG ZIP Tools 4.1.0" and let it install the necessary shared library to your target. This is a prelimenary package and I have not been able to test everything. What should work: Development System: LabVIEW for Windows 32 bit and 64 Bit, LabVIEW for Linux 32 Bit and 64 Bit Realtime Target: NI Pharlap ETS, NI VxWorks and NI Linux Realtime targets From these I haven't been able to test the Linux 64 Bit at all, as well as the NI Pharlap and NI Linux RT for x86 (cRIO 903x) targets If you happen to install it on any of these systems I would be glad if you could report any success. If there are any problems I would like to hear them too. Todo: In a following version I want to try to add support for character translation of filenames and comments inside the archive if they contain other characters than the ASCII 7 bit characters. Currently characters outside that range are all getting messed up. Edit (4/10/2015): Replaced package with B2 revision which fixes a bug in the installation files for the cRIO-903x targets. oglib_lvzip-4.1.0-b2.ogp

Is that like home-sickness for birds?

Well bugger me!!!! Welcome back stranger .

lol. 8.2.1 is/was one of my fav LabVIEWs

If you send me a nice modern Mac I might be able to work on that. My experiments with a MacOSX installation under Virtual Box were pretty abdominal.

You can't dismiss the device itself. Some device may have an internal timout to free up resources which means they will actively and willfully drop any connection that has not seen any data transmission for a certain amount of time. While your desktop computer has a sea of memory and CPU power to process many parallel TCP/IP streams at the same time, your embedded device is typically much more resource constrained. They may not even be able to serve more than one endpoint at the same time, so any host trying to connect to them and leaving a connection hanging could block the device for anyone else entirely. That may be a security feature, by locking out other network access while you do some sort of transaction on the device that needs to be uninterrupted by anyone else, but if the device would allow infinite time for a connection to stay open, any misbehaving application could block the device totally for anyone else. So check your documentation! Most likely there is some info as to how long a data connection can stay open inactive before the device will close it from its own side, which is in fact the most common reason for error 66. Another possible reason for this error could be that the device detects some errors while serving the connection, either misformed data packets or some network protocol error due to for instance your bad network card or noisy connection and simply drops a connection on any such error. It is the safest thing to do in network communication: If there is any error during processing of the network connection, close it immediately and let the client reconnect. Your client software should be able to cope with that by using the information returned in the error cluster. Generally a robust network client would treat error 56 as an indication to retry the last operation one or more times (but not indefinitely) and if the error 56 persists or any other error occures, close the connection and attempt to reopen it.

Hey Guys, I just want to mention that JKI is committed to making sure that VI Tester works well in LabVIEW. We can't live without it at JKI and it's going to continue to be improved. We've been really busy lately, so that's why there hasn't been a new version pushed out. We see the LV UTF as addressing a totally different market need than VI Tester. As I see it: UTF is great for people who want to show 100% test coverage through its static analysis tools -- NI created it to address the needs of people developing for regulated industries. VI Tester is great for people who want to do better and faster software engineering in LabVIEW -- JKI created it to help test object-oriented (and other) LabVIEW applications using the industry-standard xunit architecture. I can't comment on time-frames, but please stay tuned and don't give up on us. BTW, VIPM 2013 SP1 (one of the areas where we've been busy) was just released (do a check for updates)! We couldn't have done that without VI Tester.

I really think given NI's support, it would make a lot of sense to stick with what they have available. Rolling your own sounds like a big undertaking and while I really enjoy owning my own tools, the time and effort needed in building, deploying and supporting them just doesn't seem like a good idea. Especially on a thing that involves testing code components. Sorry to hear the NI solution is slow but because you have a license you should be able to get some support from NI to investigate this, or at least get some feedback from them. JKI's timing for their VI Tester was unfortunate. I felt bad for them when I heard the Unit Test Framework was coming out in what felt like a few months after the JKI one. As a result I get the feeling JKI is focusing their attention on other tools that they have a competitive advantage with.