Jump to content

Mads

Members
  • Content Count

    291
  • Joined

  • Last visited

  • Days Won

    15

Mads last won the day on August 21

Mads had the most liked content!

Community Reputation

45

About Mads

  • Rank
    Extremely Active
  • Birthday 12/01/1975

Profile Information

  • Gender
    Male
  • Location
    Bergen, Norway
  • Interests
    Trail running, skiing, science fiction, food and travel.

LabVIEW Information

  • Version
    LabVIEW 2018
  • Since
    1997

Contact Methods

Recent Profile Visitors

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

  1. Passing data between executables on the same machine that happens to have the TCP stack loaded because it has a network interface anyway does normally not require a loopback adapter (unless any of the requirements I listed are in effect). If this was a serial link, then sure - you would need a physical or virtual null modem installed. The local TCP traffic never passes through any adapter anyway. As described in the first sentence here (where the need for loopback is in place because they want to capture the truly local traffic): https://wiki.wireshark.org/CaptureSetup/Loopback You can fire up the client-server examples in LabVIEW and run those with localhost, as long as the machine happens to have a single NIC installed. Any client-server will be able to do that. That's why I was wondering what's different here.
  2. Tested the 4.2 beta with success on a Linux RT x64 target today (cRIO-9030), where I have never gotten it to work previously. Compressed and decompressed folders with multiple files and subfolders, and used the inflate/deflate functions. The files that were compressed were also transferred to a PC to verify them there, and vice-versa.
  3. What is the role of the loopback adapter in this case? Do you need it to monitor the traffic through Wireshark for example? Or is the machine without a single physical network adapter so you have the loopback installed just to get access to networking? Or is it to handle a routing issue? Otherwise the link could be fully local, with all the shortcuts that allows the network driver to take.
  4. Downloaded it and so far I've tested it on LabVIEW 2019 and Linux RT ARM (cRIO-9063) with success (compression/decompression of files and folders and deflate/enflate on strings). I'll try a different target type later today. Only trouble so far is with the package format - my VIPM does not like opening ogp files from Windows (get an access error), but I can open it and install it manually from VIPM...That might be a local issue though.
  5. There is also a version 4.2 in the works with more 64-bit support - as discussed here: On a side note; I used version 4.1 now from LabVIEW 2019 on a Linux RT for ARM target and got build errors that I do not get in 2018. I have not investigated it much yet though so it might just be a local phenomenon: From the build log: Deploying ZLIB Open Read File__ogtk.viZLIB Open Read File__ogtk.vi loaded with errors on the target and was closed. LabVIEW: (Hex 0x627) The function name for the lvzlib.*:lvzip_unzOpenCurrentFile3:C node cannot be found in the library. To correct this error, right-click the Call Library Function Node and select Configure from the shortcut menu. Then choose the correct function name. LabVIEW: (Hex 0x627) The function name for the lvzlib.*:lvzip_unzOpenCurrentFile2:C node cannot be found in the library. To correct this error, right-click the Call Library Function Node and select Configure from the shortcut menu. Then choose the correct function name.
  6. Great. I would be glad to test it. I mainly work on ARM-based Linux RT targets myself, and the occational old VxWorks cFP-target.
  7. I noticed on sourceforge that there is a version 4.2 of OpenG Zip. Will it be released as a package anytime soon?
  8. Daisy-chained / multi-dropped RS485 with a master-slave protocol? If you need an example of how that can be done in LabVIEW you can look at this one which is based on one of the industry-standard protocols for such communication - Modbus :
  9. The checksum (well, CRC to be correct) will be generated by the same software that generates the archive in this case - and is then run through tests locally to ensure it is OK. So I feel confident in trusting the content from that point onwards if the CRC is OK, and the structure of the content is recognisable. It is the transfer in this case that is highly exposed to corruption... (involves several weak protocols and complex layers which I cannot change, - or at least not all of them at this stage)😲
  10. The project is on an sbRIO running Linux RT, that is partially why I preferred using the OpenG library. (The device delivering the zip-files to the sbRIO gives it an *extremely* short time to reply on whether the data is OK or not, so eliminating slow file operations is a must... With the correct checksum in the added header, I now run the crc32 calculation continuously on the incoming data, which enables me to verify the transfer instantly.🙂. A file size in the header also allows me to preallocate the file space up front - or deny the transfer at startup if there is not enough space for it anyway👍)
  11. Thanks for the feedback. On the project I'm working on I decided to just add a header to the zip files, I am managing the transfer of the files and can just strip off that header anyway. At first I wrote code to parse out the headers of the zip archive and grab the necessary checksums, but dropped that approach when I saw that the file checksums are calculated on the uncompressed data , meaning I would need to decompress them first just to figure out if the data was wrong. A better alternative would be the central directory checksum I guess...but I went for an even easier solution in this case as the added header gave me some extra benefits. It would be nice to have file verification in the OpenG Zip library someday though.
  12. The decompression in OpenG Zip does not seem to verify the checksums of the containing files. Having changed a few bytes in the middle of various zip files I will get an error from other tools (tested on Windows and Linux RT), but OpenG Zip will churn on it as if nothing is wrong. In one case the change even caused the decompression to generate a file that was hundred times bigger than the true content. Is there a quick fix to this, or would the entire library have to be updated (new dll etc) to get such functionality?
  13. Every now and then I hope for a bright future and open the latest NXG - and my head hurts. They've changed too much, and gained so little🤯. I immediately get irritated by how disrespectful the whole thing is of the strengths of LV, but try to push myself to get more used to it. Then I hit a brick wall in a lack of functionality, and my patience runs out. Back to LabVIEW 2018. Home sweet home☺️ (sure, the roof is leaking and the style is a bit 90's, but it beats NXG).
  14. I took my chances and upgraded...No trouble running the thing anymore, but it still does not accept my volume license (which was updated in November)...Probably just another update of that and it's all OK though (hopefully).
  15. There is also already an SP1 f1 installer out....(3rd of December is the release date) Here: http://www.ni.com/download/labview-development-system-2018-sp1/7889/en/ So is that an update to SP1 that needs to be applied after SP1, or is it included in the "new" (hopefully) SP1...or? Anyone who has been brave (or virtual) enough to install these already?😉
×
×
  • Create New...

Important Information

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