smarlow

I believe it is related to having the Embedded UI enabled. I turned off the embedded UI and ran the system for a few days without the problem. I did not see this issue with LabVIEW 2020 with the app I am running, so I believe to be a new issue introduced since then (I updated the system to LV 2023 Q3)

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.

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?

It is my understanding that the VCP interface sits on top of the D2XX driver. The EEPROM for any FTDI chip can be programmed to optionally load the VCP driver or not. The device I am dealing with is programmed to not load the VCP.

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.

Rolf: Thanks for the info. I did suspect it might be related to the SD card. However, I did see the issue before adding the logging module . I will still try a run without to see if it helps, since the non-logging version that froze was before the updates.

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.

*SIGH* Lock-up issue has returned even after firmware upgrade.

Thanks for the info. I believe I got it fixed. I ran the latest update for 2023Q3 (f2). I also did not realize there is a new cRIO firmware image for the cRIO-9047 (23.5). I was running 8.8. I am surprised that MAX did not flag the 8.8 firmware as being too old when I installed the 2023 base image. Anyway, after updating everything, the system has been running for 16 hour with no problem. I'll let it run over the weekend. Hopefully, the problem is resolved. EDIT: I did completely reformat the cRIO drive after updating the firmware.

Having trouble with a cRIO locking up: cRIO-9047 with the Embedded UI enabled. LabVIEW 2023Q3 on host and cRIO Using 30 sec. restart Watchdog and whacking it ~1 Hz Not a really complicated diagram. FPGA programming mode (not scan interface mode) I am monitoring the memory usage and it does not appear to be increasing. Usually locks up 2-20 hours after start. Program and display completely frozen. Cannot connect from LV Project or MAX. Watchdog controller does not reboot the controller. Hard reset required to get the controller running again. NI tech support says no internal known issues reported Has anybody else seen this? Thanks for any help.

Using a class might help.

This implementation would mean the data for the "callback" has the same type as the dynamic event. But if you use a cluster or class, it would be easy enough to separate the calling data from the return using sub-clusters. Copies of the calling data would be in the return, but that would be relatively harmless.

I have a design that uses a Notifier to return data from a dynamic event back to the thread that generated it. I used the data type associated with the event as the type for the notifier. It's kind of clunky, but it works. By typecasting the event refnum to a string, and using it as the name of the notifier, I believe it guarantees a unique notifier name. If they were to build this "notification" into the event, it would act as a return. The node could be on the right as you describe, and would have the same type as the dynamic event data. A "Wait on Return" or "Callback" function would be added to the Events palette that functions like a "Wait on Notification" function. I think they could wrap up this implementation into a tidy solution for returning data from a dynamic event:

It's killing LabVIEW. They need to stop trying to use LabVIEW to only sell the top-end $$$ hardware. It's going to end up like HP-VEE.

Do you mean like a return from a dynamic event?