Rolf Kalbermatter

The change to "librarize" all OpenG functions is a real change in terms of requiring any and every caller to need to be recompiled. This can't be avoided so I'm afraid you will either have to bite the sour apple and make a massive commit or keep using the last OpenG version that was not moved to libraries (which in the long run is of course not a solution).

And what is the program on your ESP32 doing? Does it even listen on the according serial port? Does it know what it should do when seeing an *IDN?<new line> on that port? What does it send back when seeing that command?

The ESP32 is a capable microcontroller board but it needs a program that can implement the reading of your sensors and react to commands from your LabVIEW program and send something back. And that program needs to be implemented by you in one of the supported programming languages for the ESP32. Most likely you will want to use ESP-IDF as a plugin in either Eclipse or VSCode. 

The only thing I have found to work is to maintain separate projects for 32-bit and 64-bit and have them each build into a seperate location on disk. Anything else is going to mess up your projects almost beyond repair possibilities.

That applies to both the projects to build your PPLs, possibly one project per PPL in the case I worked on, as well as for the applications using those PPLs. Using Symlinks to map the build locations of the PPLs to a common path that is referenced by all the projects making use of PPL dependencies (including PPL build projects), helps with maintenance of the projects as they all only need to reference a general location for dependencies rather than an architecture specific location.

5.0.1 and in the meantime 5.0.2 has been since released. One issue, but that is not really new and existed before: Don't disable mass compile after install, it may take some time but it sure fixes stale shared library paths in the VI and I have so far not found a way that makes those paths automatically fixup at package creation, since the path seems to need to be absolute.

The two possible approaches I'm currently considering:

1) use a so called Symbolic Path (/<user.lib>/_OpenG.lib/lvzip/lvzip.*).

Disadvantage:

- only works if installed into default location

2) use Specify Library Name on diagram for the Call Library Node and calculate its path at runtime.

Disadvantage:

- makes the shared library be not a visible component to the VIs, so that the shared library needs to be added explicitly in every application/shared library/assembly/source distribution build in order to be available in such

- extra execution time for the dynamic calculation of the path

If you use the chroot trick that NI/Digilent did for the Linx/Hobbyist Toolkit it is theoretically doable but far from easy peasy. And you still have to sit down with the NI/Emerson lawyers as I told you before.

However I doubt you want to run your Haibal library in a specially compiled Debian kernel running in a chroot inside your Jetson Linux distro. That is necessary since the entire NI library tree and LabVIEW Runtime is compiled for the arm softeabi that NI uses for their Xilinx XC7000 based realtime targets.

And yes you can NOT run a LabVIEW VI without LabVIEW runtime on the target! Period!

And that NI did put the NI Linux RT source online has nothing to do with that they want to be nice to you or let you build your own LabVIEW realtime hardware but simply because it is the most easy way to comply with the GPL license requirements for the Linux kernel. But those license requirements do not extend to any software they create to run on that Linux kernel, since the kernel license has an explicit exemption for that. Without that exemption there would simply not be any commercial software to run on Linux.

And I understand what you want but that does not make it feasible. I WANT to win the jackpot in the lottery too but so far it never happened and quite certainly never will. 😀

If and how the DLL uses exceptions is completely up to the DLL and there are actually several way this could work but only the DLL writer can tell you (if it is not explained in the documentation). Windows has a low level exception handling mechanisme that can be used from the Win32 API. It is however not very likely that a DLL would make use of that. Then you have the structured exception handling or its namesakes from different C++ compilers. And here things get interesting since each compiler builder was traditionally very protective about their own implementation and were very trigger happy about suing anyone trying to infringe on the related patents. It means that GCC for a very long time could not use the Microsoft SEH mechanism and therefore developed their own method that was avoiding Microsoft patents. So if your DLL uses exceptions, and doesn't handle them before returning from a function call to the caller, you might be actually in a bit of a bind as you really need to know what sort of exception handling was used. And if you use a different compiler than what was used for the DLL, you will most likely be unable to properly catch those exceptions anyhow, causing even more problems.

Basically, a DLL interface is either C++ oriented and then needs to be interfaced by the same compiler that was used for the DLL itself anyhow, or it is a standard C interface and then it should NEVER pass unhandled exceptions to the caller since that caller has potentially no way to properly catch them. One exception are Win32 exceptions that the LabVIEW Call Library Node actually is prepared to catch and turn into the well feared 1097 error everybody likes so much, unless you disable the error handling level completely in the Call Library Node configuration dialog. 😁

Your example code, while probably condensed and not the whole thing, does however ignore very basic error handling that comes into play long before you even get into potential exceptions. There is no check for the Load_Extern_DLL() to return a valid HANDLE. Neither do you check for the function pointers you get from that DLL to be all valid.

p2_CallbackFunction_t is rather superfluous and a bit misleading. The _t ending indicates it to be a type definition but in fact you simply declare a stack variable and assign the reference to the CallBack function to it. Luckily you then pass the contents of that variable to the function, so the fact that that storage is on the stack and will disappear from memory as soon as your function terminates is of no further consequence. But you could just as well simply pass the CallBack function itself to that function and completely forget about the p2_CallbackFunction_t variable declaration.

Once your function returns, you have indeed no way to detect exceptions from the DLL anymore as there is no stack or call chain on which such an exception could be passed up. The way this should be done is by the DLL handling all exceptions internally and passing an according error indication through the CallBack function in an error variable. It can't use the CallBack function to pass up exceptions either since the CallBack function is called by the DLL, so the exception handling can't go from the callback to LabVIEW but only from the callback to the caller, which is indeed yes ... big drumrolls ... the actual DLL.

If your DLL doesn't catch all exceptions properly and handles them by translating them to an error code of some sort and passing that through the callback or some other means to the calling application, then it is not finished in terms of asynchronous operation through callbacks. Exceptions only can pass up through the call chain, but if there is no call chain such as with a callback function, there is no path to pass up exceptions either.

8 minutes ago, jhoskins said:

That would be a viable option if I was only displaying information, but it also controls the equipment. I know you do not know my system and are only offering help and I greatly appreciate it. Thank you and I always learn new things when I post on here.

Hmm, not trying to criticize you but having 100 (or even 25) little windows that all display data and allow control too, seems to me to be a pretty difficult UX. It's definitely not something I would immediately turn to. Probably would have more like a list box that shows the information for each device, possibly in a tree structure, and letting the user select one and then make the controls for that available in a separate section of the screen where the control will be specific to the selected device. Shaun's example, while nice technically, shows the difficulty of that approach very well even without much of user control. The graph in there is pretty much way to small for any usable feedback.

4 minutes ago, jhoskins said:

How else would you suggest to show the information needed at 1 time on the main front panel? I use the DQMH framework and clone the VI and put that VI in subpanel on the main UI. I have been doing it this way for a long time now and have tested it up to 200 and have seen any issues. Updates coming in are really slow as the cameras send out status updates every minute. Realistically it is around 25 panels but it depends on how many cameras need to be monitored and controlled. But lets not get caught up in that, in general I would just like to learn to use Francois tool to programmatically align controls and indicators in a grid pattern based on screen size.  Similar to what Shaun is showing above. (Nice VI by the way, mind sharing?)

I would likely use a Table or MultiColumn List Control.

4 minutes ago, ShaunR said:

Booh with bells on.  Hello 7 hr build time. 

The whole ADS library overhead in an application adds about 0.0something seconds to the whole build time of any project. As long as you have a linear hierarchy in object class dependencies, there is virtually no overhead at all beyond what you would have for the involved number of VIs anyhow. Once you happen to create circular dependencies the app builder will go into making overtime to resolve everything properly and your build times start to grow into the sky. At some point you can get all kinds of weird build errors that are sometimes almost impossible to understand.

Untangling class hierarchies is in that case a very good (and usually also extremely time intensive) refactoring step to get everything to build nicely again.

3 hours ago, ShaunR said:

Booooh! 

For this type of functionality it is absolutely not Booh. 😀

It is OOP in the sense that it uses LabVIEW classes as an easy means of instantiating different driver implementations at runtime. One interface (or a thin interface class in pre LabVIEW 2020) and then a child implementation to call the DLL, one to call VISA USB Raw and possibly others. On top of that one driver as a class to do MPSSE I2C and another for MPSSE SPI. That way it is very easy to plugin a different low level driver depending what interface you want to use. D2XX DLL interface on Windows, D2XX so interface or D2XX VISA USB Raw on Linux and LabVIEW RT. With a little extra effort in the Base Class implementation for a proper factory pattern implementation, the choice which actual driver to load can be easily done at runtime.

I did the same with other interfaces such as Beckhoff ADS, one driver using LabVIEW native TCP, another interfacing the Beckhoff ADS DLL, one for Beckhoff ADS .Net and one for Beckhoff ADS ActiveX, although the ActiveX one has a bug in the type library that tells LabVIEW to use a single reference byte as data buffer for the read function and there is no way to overwrite the type lib information except patching the ActiveX DLL itself. The Typelib should declare that as an array datatype but instead simply declares it as a byte passed by reference. The same thing for a C compiler but two very different things for a high level type description.

The base class implements the runtime instantiation of the desired driver and the common higher level functionality to enumerate resources and read and write data IO elements using the low level driver implementation. For platforms that don't support a specific "plugin" you simply don't install that class.

16 hours ago, smarlow said:

The device originally came with an FTDI VID, and a "custom" PID from the range FTDI assigns to its volume customers.  This is to prevent the device from interfering with the setup of other devices that use the same chip.  This unrecognized PID caused the device to show up in RT Linux as a VISA USB RAW device, which is the default for unrecognized VID/PID USB devices on NI RTOS.  I have some experience working with FTDI chips in the past on the Phar Lap RTOS.  I once wrote a set of drivers for the FT232R using the FTDI packet specs and the USB control pipe and VISA read/write functions.  However, those drivers don't work for this particular chip, which is different model.  The mfg. agreed to change the PID to the standard (the VCP load option will still be off), and I am trying to prepare for dealing with the chip without the VCP or the USB RAW drivers.

USB Raw will of course require your LabVIEW code to use the right USB control endpoints, pipes and binary bit patterns and if the new chip is not 100% upwards compatible with the old, that means a different driver (or one with conditional code based on the chip as detected at communication initialization). Without a detailed specification of the low level USB protocol for the new chip that is not gonna work.

Using the FTDI provided D2XX driver should fix that as that driver somehow makes sure to talk to each chip as needed, as long as FTDI supports that chip with this driver. Some of the FTDI chips need a different driver such as D3XX. It's definitely easier than trying to do USB Raw communication but requires a bit of C programming knowledge to be able to figure out the proper Call Library Node configuration for each function. The existing LabVIEW wrapper as provided from FTDI is outdated and only supports 32-bit, possibly even with a bug or two even in 32-bit, but it is a starting point.With a little love it can definitely be made to work for modern LabVIEW in 32-bit and 64-bit and for Windows and Linux.

I may revisit my earlier  attempts of writing a fully LabVIEW OOP based solution for this with pluggable low level driver using USB Raw or FTDI D2XX and a pluggable high level driver for the I2C and SPI MPSSEE modes of the chips that have such an engine build in, but I haven't currently a use case for this and that tends to push this project always towards the end of the "projects that are nice to develop" queue.

On 3/19/2024 at 3:31 PM, jhoskins said:

Hey Francois and team. I know this is an old thread but was not sure where to post the topic. I am having trouble using the UI tools to create a grid of subpanel controls based on screen size. I have several hundred Sub-panels that need to be positioned in a grid pattern. 

I am having a hard time with setting the next control beside the other one and moving to a new row. Could you help me out. LabVIEW just crashed on me so I will post what I have done in a few.

It may be possible, but a few 100 subpanels somehow makes my alarm nerve tingle quite strongly! Sub Panels are not the light weight thing like Windows windows, where they made each control in a classic Win32 application its own sub-window. And they moved away from that idea with more modern UI frameworks too, and likely for some reason. You really may be stressing LabVIEW's window management capabilities beyond reasonable borders with so many subpanels present at the same time.

27 minutes ago, smarlow said:

After reading the AN you posted, it seems that for the Linux OS, the VCP/D2XX are not connected.  Does this mean that if one of my FTDI chips needs the D2XX driver, that none of my VCP devices can be used?

Not just for Linux. In Windows it is the same.

But I'm not sure, I never used the D2XX driver on Linux until now. My understanding is that as long as you do not open a VCP interface for a device, the hardware is not really in use and should be accessible by the D2XX driver. In the worst case you may have to configure udev or whatever is used on your system to manage automatic mounting of USB devices, to not install a particular device as tty device, for instance based on the serial number or similar. By default most Linux systems are nowadays configured to automatically install any device they have a standard driver for as the according device. In the past this was often the opposite where you had to mount the device manually or add an according rule to udev for automatic mounting at boot time.

15 hours ago, smarlow said:

Since FTDI chips are recognized by NI RT Linux out of the box these days, I assume the OS comes packaged with the FTDI chip drivers for Linux.  Are there wrapper VI's available for the RTOS for calling the driver library?  If not, does anyone know off hand where the external driver library is located so I can set up the Call Library function for it?  Thanks in advance.

That's not how those drivers work. The device drivers for the FTDI chips (the RS-232422/485 at least) installs in Linux as a serial port driver. That means that they get installed as serial ports under /dev, usually as /dev/ttyUSB* with increasing number and can be accessed through NI-VISA just as any other serial port. There is no exported API in these drivers that you can  interface to with a Call Library Node.

If you want to access the MPSSE engine in those chips (to do bit bang, I2C or SPI for instance) instead of the Virtual Comm Port interface the standard Linux driver provides, you'll have to hunt down the D2XX driver for your Linux distribution and install that instead.

https://www.ftdichip.com/old2020/Support/Documents/AppNotes/AN_220_FTDI_Drivers_Installation_Guide_for_Linux.pdf

This document is from 2017. Your Linux distribution may have changed things considerably in the meantime, so your mileage may vary, but the general distinction between standard VCP and FTDI proprietary interfaces to the chip through the D2XX driver remains.

There exists LabVIEW libraries to interface to the D2XX shared library and also to access the two FTDI provided wrapper libraries to do MPSSE SPI and MPSSE I2C but they are heavily Windows minded, meaning that they try to link to the .DLL version instead of the .so and there might be other API specific details that differ between Windows and Linux. Also last time I checked the two MPSSE VI interfaces here on LAVA were not cleanly prepared to handle 64-bit shared libraries as they were developed when 64-bit LabVIEW was still in its early days and nobody bothered to install and use that.

On 3/14/2024 at 8:25 PM, Darren said:

The multiple patterns nugget was broken in LabVIEW 2023 Q1, but it works in LabVIEW 2023 Q3 and later.

I would actually suggest to implement it properly by extending the File Dialog Node. A double NULL terminated string array that is simply passed to a Windows API function is hardly a safe and proper LabVIEW datatype! 😁

And of course you saw it already coming, add support for that on Linux too 😁

27 minutes ago, X___ said:

LabVIEW's motto: Move slowly and break things!

Not really. And this is a very clear case of using an undocumented and unintended side effect of the implementation. It only worked on Windows and not any other platform and only because the person who implemented the file dialog functionality took a shortcut by passing the LabVIEW string directly to the Windows API without trying to sanitize it.

Microsoft discourages the use of the GetOpenFileName and GetSaveName APIs which originate from Windows 3.0 times starting with Windows Vista, and recommends to use the Common Item Dialog instead. My guess is that someone did recently listen to that recommendation and changed the file dialog implementation accordingly. Making sure it works the same way as documented for the old function is already hard enough, trying to also implement undocumented functionality and potential security bugs which this API had, is a bit to much asked.

Welcome back in the community! 🤗

Hi Paul

I'm aware of this problem. It has to do with different default fonts in modern Windows machines, which changes the entire text format. The main reason I haven't yet updated the installer was that I was on vacation and there is also a problem to install the package under Linux, which has to do with write permissions to certain file directories. Once I figured that out I will release a new package 5.0.1.

18 hours ago, Mads said:

The top one, the SAC, will run even if the root loop is busy, AND allows you to set the inputs. This function was not available in LabVIEW until version 2011 or so. It is especially useful if you need your application to spawn VI clones to handle various events (TCP session handlers for example) regardless of what the user is doing in the GUI...

The two bottom ones will be blocked if the root loop is busy, e.g. if the user happens to be viewing the time picker of a time control it will halt until the user closes the time picker.

Before the SAC was introduced in LabVIEW you had to use the run method (bottom one) if you wanted to avoid having to wait for the dynamically launched VI to complete (it has the Wait until done input). The Call by reference node on the other hand had the advantage over the run method of offering control inputs to the call whereas the run method would require you to use set control invoke nodes for that. 

Here is a long thread about the root loop issue from before the SAC was introduced:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Calendar-control-that-does-not-block-the-GUI/idi-p/1417794?search-action-id=359039184054&search-result-uid=1417794

 

One small correction. The Open VI Reference will block on UI Rootloop even in the first (top) one. The Run Asynchronous method will however not incur a rootloop round trip.

Elemental IO is not a public documented feature. The according project provider knows how to do it but it was never intended to have that interface opened as a user accessible feature. And the main reason is not that NI is evil and wants to deprive you of the fun to thinker with this but because they want to prevent customers to create easily crashing projects that require an immense support demand that NI is not able to fulfill.

This is undocumented territory for sure and as such there is a high chance that:

- parts of what you want to do might be obscure and difficult to impossible to find out without the according non-public documentation

- it might be present but not implemented, either returning an error or simply doing nothing

- it might be simply not possible as the LabVIEW developers haven't found a need for this particular operation yet, and why would they spend time on implementing something that is neither a public function nor required for internal use?

8 minutes ago, Jerzy Tarasiuk said:

Hello. I need access serial ports of NI-9871. From https://www.ni.com/pl-pl/shop/model/ni-9871.html they are directly accessible from FPGA:

So what is your problem or question? I never said that you can't access the 987x modules from FPGA. But you never specified in your OP that you meant those. As far as scripting these things, it's undocumented territory. And complicated enough that reverse engineering would be a pretty tedious job.

Supposedly the C module development Toolkit has some documentation about how so called Elemental IO can be created, but I highly doubt that it documents how that is done through scripting, but it simply provides some tools that do all these things behind the surface. That Toolkit was however not free (~1600 for non-commercial version, 6k for commercial version). The non-commercial version does let you develop your own C modules, but you are not allowed to sell them to others. However it is not anymore findable in the NI store as an order-able product.

15 hours ago, Jerzy Tarasiuk said:

Are you sure? I initially supposed NI-9871 serial ports are accessed via the RT OS, but I was pointed that I was wrong - they are connected to FPGA and the RT OS accessed them via FPGA. Seems to be sure I need a test: write a LabVIEW FPGA program that will send data via a serial port, start the FPGA program and reboot the RT OS (it is configured to allow the FPGA program to continue), monitoring the serial port data on a PC host: if the serial port is accessed via the RT OS, the data will be disturbed. I hope these serial ports are connected directly to FPGA - it is important for safety of the system.

In LabVIEW FPGA NI-9871 serial ports are accessed using Property and Method nodes (there are several properties and 3 methods - Read Byte, Write Byte, Clear Rx FIFO); I/O Node cannot be used for them.

Seems that two serial ports on cRIO itself (not on a C-Module) can be accessed from RT OS only, as well as serial ports connected via USB ports.

Well I'm for sure sure about the built in serial ports on cRIOs and sbRIOs. The987x serial C modules are a different story. And serial ports through USB ports definitely never ever could be just accessed from FPGA mode. You need at least a USB-CDC driver and while that might be possible in FPGA, it is not something that the Xilinx chips that are used on the RIO hardwares would even support, even if you might find some IP design somewhere implementing that. The communication channels such as Ethernet, Uart, USB and similar are NOT directly routable to the FPGA fabric but only accessible through their register interface, which requires a software driver to control them (and an OS on which that driver can be loaded).

On 2/27/2024 at 1:54 PM, Muhd Hannes Daniel said:

Hi I currently having problem using NI-DAQmx and DasyLab at the same time.When I run in NI-DAQmx but when i run it at the same time in dasylab there an error occur which is the specified resource is reserved.May I know how i can avoid this problem.I cannot Labview to edit the DAQ-mx system and its pretty annoying. Thanks

A particular device can ONLY be used by one application at any time. Either you can use it on Dasylab or in NI-MAX but not in both at the same time. That is standard procedure. A hardware device is a global resource and two applications trying to do anything on them at the same time will at best produces spaghetti but potentially also crashes.

On 2/24/2024 at 8:05 PM, Jerzy Tarasiuk said:

Hello. Likely the problem could be solved if there were a way to create an "I/O Constant" (like this from FPGA I/O Palette) specifying a serial port - I can create an FPGA I/O terminal for a Method or Property Node., so connecting such an I/O Constant would configure these nodes. Unfortunately, seems I/O Constant cannot specify a serial port - at least I cannot select it in LabVIEW editor. Maybe some future LabVIEW version...

The I/O Constant allows selection of project items that can be found using "Get All Descendents" method with Type="Elemental I/O" on an FPGA Target reference, or "eio_Utilities_GetAliasNames.vi" on an FPGA Application reference. Serial ports can be found using "eio_Utilities_GetNonAliasNames.vi" on an FPGA Application reference.

I think you are confusing an IO signal with a logical interface. The serial port is typically a logical device that contains a TxD and RxD pin and possibly others. On the FPGA you deal exclusively with IO signals. But there is no way to access the serial port as an IO signal. Either you would have to access the individual IO pins that make up the serial port individually and implement the serial port bit protocol yourself in FPGA or you need to access the serial port through the RT OS on the controller as serial port and let the OS driver handle the actual IO control (usually it doesn't really control the IO pins directly but uses a device driver to communicate with the serial port registers).