Rolf Kalbermatter

5 minutes ago, Antoine Chalons said:

I see... Setting up VMs for Windows, Linux and Mac testing will be a challenge

2014 sounds reasonnable

Yes that is the main problem to support something like this. And no I don't have a 2014 installation either for Linux. I could of course download 2017 SP1, which is the oldest that can be downloaded from the NI site, but I would actually prefer to have a version that was also supporting 32-bit (which 2016 was the latest).

8 hours ago, smarlow said:

Thanks for the links and info.  I will keep plugging away.  BTW, I am logging at 1 Hz to an SD card.  I do not leave the file open.

I would be very hesitant to use SD cards for anything but occasional backups (and not to keep the backups on there, but just to transfer them to a different more safe location). SD card reliability is a big issue and "the" major reason for Rasperry Pi applications in 24/7 unattended operation mode to eventually just die (well not the Raspberry Pi is of course dying but it won't boot up from the SD card anymore eventually). The S of SD is definitely a misnaming. 

6 minutes ago, Antoine Chalons said:

Is it a must to keep this in LabVIEW 8.6?

I mean... OpenG has now moved to 2009, which is still pretty old.

Well, do you have a LabVIEW 2009 installer for Linux (and Mac) for me to use for testing? I would be even willing to settle for 2014 but it should be an older version than 2020. I used to have 2014 on an old iMac both for 32-bit and 64-bit but that hard disk has irrecoverably died and there was no backup of it.

1 hour ago, Antoine Chalons said:

is there a publicly hosted repo for this package?

I'd be more than happy to help or at least test on Linux Desktop.

For us Linux Desktop is the most important and RT Linux is not critical as we are happy with 4.2b

Sure: https://github.com/RolfKal/openg-lvzip

Thanks guys for actually checking out the OpenG ZIP library.

Yes there is no Realtime support yet in 5.0. I was already struggling with normal Linux support quite enough, so did not want to add yet another challenge. There will almost certainly be no support for Pharlap and VxWorks in 5.0, unless someone is really begging very nicely for it. 😁

As to the Linux installation problems, I'm sorry about that. I did move to LabVIEW 8.6 for testing and building, since that is the Linux installation that I have available, but apparently forgot that I had patched the LabVIEW 7.0 OpenG Builder to not bork the shared library names when building a distribution for a package.  So I have to investigate that. Also there is still an issue with support for Unicode ZIP archives, but since that is not happening to often it should not be a serious issue for the moment. But I'm investigating the proper fixes for that. I just hope that the NI Linux RT installations offer a similar support for dealing with Unicode as do normal Linux distributions, otherwise things will get nasty.

On 2/8/2024 at 9:46 AM, Mattia Fontana said:

I am currently working with LabVIEW 2020, Linux RT image 21.0, NI-MAX 21.0f0, and I have to stick to LabVIEW 2020. 

That's definitely a potential problem. If the RT image does not match the LabVIEW version, you usually can't even connect the project to it. What CompactRIO version have you installed?

42 minutes ago, Neil Pate said:

Not sure I buy your logic, are you saying by keeping the refnum the old config API and the new one would be able to work together? ? Surely that would not have worked either. I cannot recall how the old API was implemented but I am guessing it was not the queue based one we have now (which I don't love either to be honest).

Anyway, let's not lose too much energy arguing over something this old 🙂

The old version was basically using the same config File refnum trick as the current one, only was the refnum a mask for something else than a queue, which did not exist back then. It was worse in the respect that it did read the ini file each time when writing anything to the configuration, so performance wise it was pretty sucky, and with a great possibility of concurrent access race conditions. As such the current implementation is definitely a huge improvement, but yes it caches all the configuration information in a queue which uses some extra memory.

14 hours ago, Neil Pate said:

Hmm, I think being able to wire that INI refnum into any file API and not having LabVIEW moan at you is definitely a bug.

It would have been a much more painful, and for most affected users even less trivial point to fix, if they replaced the original INI file fake refnum with a proper private user refnum. Any code that used a copy of that refnum in their own code somewhere would have simply broken. It was a judgment call: risk breaking a lot of existing code that improperly made a copy of that refnum or live with the limitations of the fake refnum. Not breaking existing code was always one of the top priorities in the LabVIEW development team, even if that existing code was born out of bad practice.

And it's not ANY file API. Only file functions that legitimately can operate on datalog file refnums. And they properly generate an error 1, since the refnum in question is indeed NOT a valid file refnum. There are other situations where you can logically connect data types to nodes but that node can't operate on that specific flavor of data type. LabVIEW is strongly typed but sometimes there is simply no easy way to make sure at compile time. As long as it produces proper error codes at runtime and doesn't crash, I consider it a valid trade off.

42 minutes ago, Neil Pate said:

oops, sounds like a 30 year old bug! I think I remember the Config API was re-written sometime around LV 8.0? (or is my memory faulty) 

About 30 years indeed. And bug is a strong word, it was a smart find back then to create your own refnums. While there would have been a better alternative around LabVIEW 7.1 (User refnums) there were several reasons not to use them. It was a new and not extremely well tested facility, it was really meant to incorporate binary shared library drivers with very little LabVIEW VIs and it would have broken the many Config File wrappers and application users that were creating a private copy of that “refnum” instead of using the Config File typedef.

On 2/2/2024 at 7:53 PM, Neil Pate said:

I am a litle surprised LabVIEW lets you wire this together, as the reference coming out of the Open Config Data is not actually a file reference it is a queue reference.

So when you try and Flush you are passing in a Queue reference not a normal File reference, so this will not work.

 

Neil, that queue reference is type casted to a LabVIEW datalog refnum. This is done to create a custom refnum "light". It works to prevent users from connecting this refnum to anything that is not an INI refnum ....... except file IO functions that also can deal with datalog refnums. The file IO function then tries to extract the underlaying file handle and that of course fails since the queue refnum does not have a file handle. Therefore you get the error 1.

If the OP really wants to hack a Flush into the library it would have to be added to the Config Close. But since this is the only time the whole file is even accessed with write access and there seems to be a little window of opportunity during the Write File function and the Close File function in there in which, when the power is yanked just in time, in the right way, the transfer to the disk is corrupted. The File Close should do a Flush too, although it may be somewhat delayed. How a Flush right before the Close would really help is more than doubtful.

I think Shaun's recommendation to check the S.M.A.R.T data for the drive in question may have some real merits here!

15 hours ago, Darren said:

The App Builder API is not supported within a built EXE. It can only run in the LabVIEW editor.

More generally, there is no way to build a LabVIEW EXE that can build LabVIEW EXEs.

That's technically not exactly correct since there exists something like lvrtff. However trying to use that in order to be able to build LabVIEW applications from within a LabVIEW application is definitely not worth the hassles.

You can NOT install LabVIEW RT on non-NI hardware without a license from NI! And they have so far hesitated or stalled to say if they ever plan to sell such a license.

What you can do is install NI Linux RT on whatever hardware you care since the Linux kernel is GPL software. And that is also what the NI Github repository is about. To provide a means to fulfill the GPL requirement to have the source code to the GPL covered software accessible to any user. What the NI Linux RT Github repository does NOT contain are the LabVIEW RT runtime kernel , NI-VISA, NI-DAQmx, NI-this and NI-that since they are closed source software and the Linux kernel comes with a special GPL clause that allows people to build and distribute closed source software that runs on it. Quite some kernel folks would love to get rid of that clause and force everybody to open source everything everywhere, but that didn't even fully work for kernel drivers, where they did a lot of effort to prevent closed source drivers from being able to do high performance operations.

The big point here is that NI Linux RT is NOT LabVIEW RT. The whole LabVIEW RT runtime and NI driver stack are closed source and you can not install it on random hardware without an according agreement from NI.

If you install NI Linux RT on your Jetson hardware, what you basically get is a somewhat expensive Raspberry Pi or Beaglebone Black board with additional soft RT capabilities but no LabVIEW target support at all! And no, the LabVIEW Hobbyist Toolkit can't be easily repurposed to run with such a hardware either. It's support is limited to ARM Cortex A hardware platforms and you may be able to get the according schroot image installed and running on the Jetson, but that is an entirely different thing than getting NI Linux RT installed on the Jetson. It is legally questionable but maybe you could get away with it, but it is technically quite a suboptimal solution as the schroot environment in which the LabVIEW RT kernel is running is a limited non-RT capable virtual machine running on the normal Linux host on your Jetson.

On 1/25/2024 at 2:12 PM, Phillip Brooks said:

So a Google search shows this phrase on numerous pages at the top and bottom of the body text.

Is this maybe some sort of tag or something to indicate that a third party is creating the new content (outsourcing of site maintenance?)

Maybe some sort of a disclaimer that the data may not be accurate or complete; or maybe based on AI generated pages using pull request comments or requirements docs?

I'm thinking AI because there is so much talk in general about identifying anything created by it.

It happens in a lot of locations. When you go to the download page of NI software (their specific canonical download entry for each product where you can choose the version and bitness and such) you usually have a link that goes to another page that shows available readme's, and similar documents and there it often states this sentence.

However it happens both for very old releases of software (I assume the person creating that entry felt to lazy or to frustrated to search the NI document management system for the according document) as well as very new releases (here the document may indeed not yet officially exist and has not been added to the document management system).

1 hour ago, Naoyuki Matsumura said:

Is this LabVIEW library compatible with FT4222H?

Doesn't seem to have an MPSSEngine. Which is not so surprising. The MPSSEngine is a Multi Protocol Synchronous Serial Engine. There is nothing truly multiprotocol about the FT4222H chip, it's simply an I2C/SPI interface chip without support for other GPIO, RS232, and similar interfaces. https://www.ftdichip.com/old2020/Products/ICs/FT4222H.html

You can use it through the FTD2xx driver though. there is also a LibFT4222 DLL which sits atop the FTD2xx driver and implements the FT4222 specific stuff. You would have to create LabVIEW Call Library Node wrappers for this DLL if you want to use this driver.

Your suspicions are partly right! lvanlys.dll is for the most part the conversion layer from the LabVIEW AAL functions to the MKL. In old days lvanlys.dll was the NI implementation of the Advanced Analysis library. But when they changed to use the MKL they could (or did not want to) change the entire LabVIEW Call Library Nodes to adapt to the MKL entry points. Basically the MKL is NOT written with LabVIEW in mind but fully designed to be called by C(++) code. An intermediate translation layer written in C(++) that provides a LabVIEW friendly interface is the most easy thing to do in that case (no it's not easy at all but the alternatives are much worse in terms of effort and maintainability).

Also there were some specific assumptions in the LabVIEW AAL that are slightly different how the MKL library expects things, so the lvanlys.dll also takes care of such differences. Alternative would have been to change some of the conditions for callers of the LabVIEW functions, which would have been a very serious backwards compatibility problem.

The Intel Math Kernel Library. NI occasionally updates the Intel MKL used but doesn't painstakingly follow the latest and greatest from Intel. And there might have been some licensing perils in recent years. NI got a license to distribute the MKL when it was still its own product and Intel was very keen to have as many people as possible adopt it. Nowadays it is part of the One API initiative and Intel is a lot more pushy about monetizing that, so they may have altered the license deal that NI had, and NI might or might not have accepted that.

5 minutes ago, Thang Nguyen said:

I worked in company building EOL test systems for different manufactures which use TestStand and LabVIEW so I understand what need to communicate with different devices and instruments. Now my current company builds bio instrument and there is a requirement from our customers to integrate our instrument to their automation systems. That is why I would like to understand what is the standard of bio automation systems since I don't know much about the automation in bio industry. Now, I guess there is not much different with other industries.

Thank you everyone.

In my experience there is indeed not. The standard is more or less whatever Koolaid your client has been buying into. 😀

Same as other mentioned. If your device comes with a proprietary serial protocol over RS-232, you can consider yourself lucky as at least the electrical layer of that interface is standardized. Alternatives are USB, which sometimes come with Virtual Serial Ports, making them on a similar level than good ol RS-232, but quite often require their own proprietary driver and only are compatible with the vendors software or an expensive SDK from them.

Some vendors claim to have developed the super duper vendor independent communication standard, only to let you find out that they are really only compatible to themselves and sometimes not even across different series of instruments from the same manufacturer. They try to sell you their latest and greatest lab automation software that works perfectly with their devices and only sometimes in rather mediocre ways with other devices through complicated gateways and specially sold and expensive interface solutions.

Generally it is a lot of marketing hype and sunshine, until you try to combine two or more systems from different vendors together. 

13 hours ago, Chris LIU said:

@plf

Hi, did you fix your issue? I just bought Dell laptop, have the same issue.

It's caused by new PCI transfer modes in recent chipsets for high end CPUs from Intel and AMD. The problem is not LabVIEW itself, which does not use any device drivers of its own, but one of the NI drivers you are using. Typically DAQmx and/or NI VISA are the main contender for this. The DAQmx release 2023Q3 or later supposedly has updated device drivers that will be able to deal with these new chipsets too. 

NI-VISA 2023Q3 or later should also be able to deal with these chipsets.

The problem does not occur under Windows 10 since its PCI Plug & Play subsystem does not know about these new chipsets and doesn't try to initialize them to use these new modes.

More importantly the path to the DAQNavi.dll definitely is wrong! Yes it tries to find the DLL, which might or might not be there.

No, it should NOT try to copy it into your application build.

Any DLL located in the System folder got installed there by its respective installer. And should be placed there by that installer on any system you want to run an application that uses that DLL.

LabVIEW has a particular treatment of the DLL library name in the Call Library Node. If the path specified there is only the shared library name without any path, it will let the OS search the DLL and Windows will automatically find it in the correct System directory. And the Application Builder will treat such a library name as indication to NOT include the DLL in the build. This CAN be important for custom DLLs that get installed in the System folder. It is ABSOLUTELY paramount and important to do for Windows standard DLL. If the path is not the library name alone, the Application Builder will try to copy the DLL to the built folder too and for Windows DLLs that means that the application will try to load that "private" copy of the DLL, and that goes catastrophically wrong for most Windows DLLs, as they rely on being located in the canonical System directory or all hell breaks loose.

Try to edit all Call Library Nodes that use that DLL to only specify the DLL name alone without any path. The path usually looks like reverting back to full path, but that is a sort of quirk in the Call Library Node dialog. LabVIEW generally will attempt to update the path to where it actually got the DLL loaded from, yet it still stores the former user entered path in the VI itself.

And are you using 64-bit LabVIEW 2018? Or a 32-bit Windows system? Otherwise that path is anyhow wrong. On a 64-bit Windows system, C:\Windows\System32 is for 64-bit DLLs. Unless your LabVIEW system is 64-bit too, that DLL in that folder definitely should not be the right one for your LabVIEW system. If the according installer put a 32-bit DLL in there, which would be pretty hard thanks to Windows path virtualization, this same Windows path virtualization will make it impossible for LabVIEW to reference that DLL there.

On 12/15/2023 at 5:28 PM, Jack Parmer said:

This is exactly the kind of feedback we're looking for - thank you!

In terms of a test sequencer / test orchestrator, the UI that we've been contemplating would allow you to import full Flojoy test apps (or Python scripts) as blocks on the canvas, then wire these "super blocks" together in parallel or series. The last block might generate a report and upload it to a data store. Do you think that this would be sufficient for batch test orchestration, or should we consider a different UI?

You may want to reconsider trying to advertise this as a test sequencer competitor. Wiring together blocks is NOT a test sequencer by a long stretch. If that was the case there would be no Test Stand, since LabVIEW can do that already since 35 years. Users of applications like Test Stand expect a lot more than that. Maintenance of test limits, possibly with database backend, easy logging of results to databases, simple log and report file generation, ease of adaption of test conditions and test flow during production. Generally Test Stand and similar applications still require a lot of work to get a full test application together, but they do not require any programming for at least these sort of things anymore. I'm not a fan of the often hidden configuration for these things, but this is the added value proposal for Test Stand and friends that its users expect. Yet another flow chart application is not going to cut it for any of them.

In terms of LabVIEW, there is obviously still a long way to go for Flojoy to get near to being a real contender in data flow programming. But I do definitely applaud you guys for the effort so far, and for the short time you are working on this thing, it looks already quite useful. The comparison with NodeRed looks pretty apt. I always found that rather limited in many ways compared to LabVIEW. A little like a Visio Flow Chart with some added execution logic behind it. Potentially useful but not quite able to implement more complex program logic that has many parameters flowing from a lot of nodes to even more other nodes. Some would probably say that that is an advantage as the complexity of a typical LabVIEW program can get overwhelming for a beginner. But I would rather have a bit to much complexity at the tips of my fingers than to run into all kinds of limitations after moving from simple node flow charts to real programs.

AFAIK, documentation about this part of LabVIEW is only available as part of the cRIO C module development toolkit. And you had to sign a special agreement to get that. The part number is 779020-03 and it costs currently € 6200 and has a delivery time of 85 days according to the NI order system, but it has no product page anymore and it is questionable that you can find anyone at NI who even knows what an MDK agreement is. AFAIK it included also an NDA section.

The whole Elemental IO was developed for cRIO module drivers but its functionality was never really finished.

17 minutes ago, Neon_Light said:

Hello RolfK,

Thank you again for the great help. The terminology is not completely clear to me. Although the 9074 does not run Linux but VxWorks, I try to make a quick compare  between Linux to make it easier to understand for me.

 

• In this screen from MAX I did click next and did install the recommended software. Is this what you mean with "the base system"? This is the same in linux as apt-get upgrade? 
• I did not update the BIOS with the button on the left. Updating the bios would be going from Ubuntu 20 to Ubuntu 22? 

Do I need to do a BIOS update to install and test the new version of RT Main ?

For non-Linux systems and Linux systems before 2018 or 2019 you simply go into NI-Max and install the NICompactRIO Base image for the LabVIEW version you are using to target the controller.

Here I installed CompactRIO 18.5 which is the version needed for the LabVIEW 2018 SP1 development system. there is a lot more installed on this controller but most is not really needed and will get removed in the final system setup.

There is no "apt-get upgrade" on any NI cRIO system at all. For non NI Linux systems everything needs to be done from within NI Max.

And  in fact the base setup for the correct runtime system needs to be done even for NI Linux targets from your host machine.

Once the base system is installed on NI Linux systems, you can then use opkg (not apt-get) on the command line through an SSH link to update the base package to possible bugfixes from the NI servers.

On 12/1/2023 at 10:50 AM, Neon_Light said:

Hello all,

At work there is an Old 9074 which is running test software. There is also a 9148 connected to the 9074.  I did change the old software tested it in simulation in simulation it works fine. 

 

What I already did do:

1. I got RAD working, so I can restore the old software
2. I did install the packages needed for Labview 2018 
3. I did find I can use MAX to install new software clicking the cRIO --> software --> add remove software gives me the option to install Labview 2018 recommended packages I did this it removed some files and added a lot of new files

Now I do need to deploy the new RT main to the cRIO there are a lot of actions I do need to perform. Can someone please tell me the basic steps I need to take to deploy the new software and test it on the real hardware? Is it as simple as hitting the run button or do I need to stop the old RT main first? Is action 3 above enough or did I had to remove old software.

If you upgraded the cRIO base system to LabVIEW 2018 I do not see how the old rtexe still could be running. It means the chassis got restarted several times, much of it got probably wiped for good and even if the old rtexe would still be there, it could not load into the new 2018 runtime that is now on the system.

So yes for first tests it should be as simple as opening the main VI and pressing the Run button. Even if you had an old version of the application deployed to the target and set to run automatically (which would have to be done in LabVIEW 2018) LabVIEW will tell you that there is already a deployed application running on the target and that it needs to terminate that in order to upload the new VI code and then run it.

On 12/1/2023 at 2:07 PM, Neon_Light said:

 Can I remove the LOCK file without serious consequences ?

That's the Unix way of creating interapplication mutexes. There are functions in Unix that allow for atomic check for this file and creating it if it doesn't exist and return a status that indicates if the file already existed (another process has gotten the lock first) or if it was created (we are allowed to use the locked resource). If that process then doesn't remove the lock file when it shutdown, for instance because it crashed unexpectedly, then the file remains on disk and prevents other instances of the process from starting.

If you are sure that no other process is currently running, that could have created this lock, you can indeed delete it yourself.