Nicolas Bats

It seems there is no solution but it exists a workaround. NI Forum

Hello dear LabVIEW community. Does anyone know if there is a way to hook Build Specification Executable Properties window in order to add a custom configuration panel? (cf. screenshot). I don't know if this can be achieved through LabVIEW project providers but I can't find any information about this subject. Thank you in advance to anyone who can provide help or informations.

Hello dear LabVIEW community. Does anyone know if there is a way to hook LabVIEW Options Window (Tools menu bar) in order to add a custom configuration panel? For example when you install FPGA and Mathscript they are new menus you can access (cf. screenshot). I don't know if this can be achieved through LabVIEW project providers but I can't find any information about this subject. Thank you in advance to anyone who can provide help or informations.

Hi all, Has anybody ever tried to customize the web based configuration interface for compactRIO ? My goal would be to « inject » some custom configuration code into the actual interface. For example I would like to add a new icon in the banner on the left edge of the page and display a form of my own in order to configure custom settings (see screenshot enclosed). Benefits of this feature would be great concerning user experience (only need a browser, single interface to configure a device, no need to develop a full custom LabVIEW configuration HMI using NI System Configuration API ...). I'm not sure if this customization is possible, and I wonder how to achive it cleanly. Maybe NI provides an overload mechanism like using hooks or something comparable ? If somebody has informations or experience about this topic, I’m highly interested in. Thanks for your help, Nicolas

After many tests, using LabVIEW 2014 & NI Real Time 14.0.1 seems to "solve" the issue. I don't have informations or explanations about the behavior described above, but I will update this topic if I got somes from NI. Meanwhile, Linux compactRIO users should consider to use NI RT 14.0.1 instead of 13.0.1.

Here is an example if it can help.

Hi smithd, Off course not. I was using simple "Tick Count.vi" or "Wait.vi" but the problem occures even without any timing function. Yes. I'm using the compactRIO in interactive mode yes but it also happen with an rtexe. I make the RT LED blink every 200ms and the LED stop blinking during the freeze, then blink again. No the compactRIO stay connected during the freeze. Only one process changes the timestamp of the compactRIO and several processes are based on this timestamp. But this is not a problem because I detect internal clock modifications and inhibit any malfunction related to this modification.

Hi everyone, I'm using a compactRIO and need to update the internal time of the device to be clock synchronized with my whole system. Everything seemed to work perfectly but when I try to apply an offset between 0 and -30 seconds, my compactRIO freeze. Nothing happen if I apply a positive offset or an offset "higher" (in a negative way) than -30 sec. The duration of the freeze equals the offset I apply on my device and after this delay, everything comes back to normal. The freeze affects all my RT code (other processus as well) and not only the VI where I use the "Set Time.vi". The FPGA seems to be working during the freeze time because I got "DMA is full" error after the freeze and some LEDs keep blinking during the whole time. Has any of you already noted something similar on compactRIO 9068 (Linux) ? Or do you have any idea of what is going on ? Thanks for you help. Nicolas Additionnal informations : - LabVIEW 2013 SP1 - NI RIO 14.0.1 - CompactRIO 9068 - Linux Embedded - LavBIEW Real-Time 13.0.1

Off course smithd I know. My sentence was more a question asking for any explanations from a NI / official person. I'm pretty much young user of Labview. I haven't been lucky to experience the first versions of LV. Based on what I can read, the main reason seems to be that it would be a long and hudge pain to change everything now. Just to let you know guys, I have received an information from the Sound and Vibration toolkit development team. This update is only about embedded subpalette of the toolkit, but maybe we can expect (or hope) that the initiative will go up to update the whole toolkit and all (or most) the signal processing VIs ?! Yeah sure it is usefull and fast code. But I think the problem is this "easy to use" feature is not all the time compatible with complex systems. I'm aware, but Labview doesn't allow any other possibility if I use POO & Dynamic Dispatch. So I consider both incompatibles.

Why do so many NI signal processing VIs use uninit shift register so ? I agree with you ShaunR, more than 100% !!! The use case might be valid or functionnal, it doesn't justify that it is a proper way to do or a good design pattern. I completely disagree with you about this question : reentrancy is made for parallel execution not storage. I have never seen any other programming language which promotes storage in static variables inside functions. Unfortunately in case of LVPOO preallocated reentrancy is not allowed, so not valid for me.

I can guess that the idea behind the question is : Labview can load in memory an instance of the correct child VI at runtime with Shared Reentrancy. Why couldn't it be possible to load, not a PREallocated, but an RUNTIMEallocated VI ? As Zyl has said in his last post : Labview allows you to launch a VI with pre-allocated option based on its only path, which can be edited at runtime. As far as I can imagine, Labview doesn't know anything about the VI until runtime but its connector pane which gives no informations about the memory or anything else. If allocation is done at compilation time I agree with your arguments, but it becomes pointless to use POO, inheritance an polymorphism. Linking resolution should be performed at runtime based on the type of the object, which obviously knows what object it is and which methods to call. This highlight my initial interogation and the reason of this topic : So we don't have any leeway beetween efficiency and feasability ? How is it possible to integrate both (real) POO and NI toolkits together ? Since last week I have a pending ticket with NI technical support. I will keep you in touch as soon as I get an official enlightenment from NI.

Dynamic dispatch VIs won't be correctly linked to static VI callers, as QueueYueue has said : Labview decides of which instance to use at every step of the loop / call of the shared clone. I have chosen to use the parent class indeed. One of my colleagues advised me to try with variants and compare performances / security of the 2 solutions. I plan to do some tests with my full system. Do you have any details about these errors errors odoylerules or was it a traditionnal simple Labview crash ?

Hi hooovahh, Yes I know NI VIs have to be called as preallocated reentrant VIs, that is what I actually do. The "relation" between my shared clone and the NI VI called inside is correctly maintained. My problem comes from the relation between the main VI calling shared clones. My question was more about the architecture of the system. Hi QueueYueue, OK that is what I was afraid of. I started a development from scratch so I used to store all my custom code data in the objects. But for the needs of the project, the client asked then to use some NI VIs in shared clones. As you say, I'm double screwed. I have tried to store a VI reference in the object, but Labview does not allow to open a shared reentrant VI with a call by reference (which stands to reason since Labview manages clones and not my code). Calling NI VIs by reference and storing this references in the object works but I am afraid of the number of references I will need... Thanks for your answers, I'm installing last version of LV to see if there is any difference.

Hi everyone, I'm loosing my mind trying to solve an issue about POO, dynamic dispatch and shared reentrancy. An example of my system's architecture is available in the Labview code enclosed. A "Main.vi" runs several parrallel loops (they can be considered as differents processes), each one calling a shared reentrant VI. The loops need to run independently (so I need clones) and shared reentrancy is required by utilization of POO and dynamic dispatch. This subVI contains an uninitialized shift register to have a memory effect between calls of the loop (in the example the subVI is a simple counter). When I run the Main.vi, the first (top yellow) and second (middle yellow) loops don't work properly (counters mix the data). The 2 instances of the shared reentrant subVI are randomly provided to the first or second loop during the execution. I'm surprised of this behavior. Does that mean I can't use any of the NI signal processing VIs (which largely use uninitialized registers) in shared reentrant VIs as soon as several of them are allocated in the same time ? Many thanks for your help, Nicolas Test Shared Reentrancy.zip