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,

Are you using timed loops with the time source set to absolute time? Since the loop is tied to absolute time I've seen this cause issues when the system time is modified.

Off course not. I was using simple "Tick Count.vi" or "Wait.vi" but the problem occures even without any timing function.

Do regular while loops freeze too?

Yes.

How are you determining that things have frozen? Are you running in interactive mode? If so, does it disconnect when you trigger this change?

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.

Are there any other sections of your code where you are changing behavior based on a timestamp?

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

Because they were written when it was the only way to do this kind of thing. Remember. It is only a problem with Shared re-entrant just don't set your methods to shared re-entrant and it will work as expected.

Because I am not all of NI...I'm not even in R&D.

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 ?!

 

In SVMS 2015 this feature was added in response to requests from Systems Engineering. For a subset of functionality found in the Embedded Monitoring subpalette, the SV Dev team addressed advanced usage in OOP applications by adding instances of analysis VIs that pass state (including initial and final conditions) through the VI. These (* With IC) instances are safe to call in Shared Clone Reentrant VIs (such as those required by Dynamic Dispatch VIs in LabVIEW

There are many many cases of where state is useful in a reentrant VI.

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.

If you do this, you do need to be aware of how preallocated clones are actually allocated, because otherwise, you can get shared instances where you expected to have separate ones, as I mentioned before.

I'm aware, but Labview doesn't allow any other possibility if I use POO & Dynamic Dispatch. So I consider both incompatibles.

Only if you store state inside of your VIs, which I personally think is a bad idea with a few exceptions (FPGA, action engine operating on a singleton resource, etc). Pure math functions are certainly not on the list.

 

I actually do mean going to the extreme of never storing state in a VI except in these special cases -- with DVRs I don't think an uninitialized shift register is really appropriate anymore. For the analysis functions I don't think there was ever a need to store state inside--they're math functions!

Why do so many NI signal processing VIs use uninit shift register so ?

 That's why  this is such a problem for people. Re-entrancy is meant for non-blocking parallel execution. Using it as a memory storage method is just an abuse of its apparent behaviour.

I agree with you ShaunR, more than 100% !!!

In my code I relatively rarely need parallel execution and more commonly want copies which will maintain state (some dynamic and some static). Classic preallocate reentrancy does that (with some exceptions). Both use cases are valid.

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.

 

 Quote

If LV can do it once in 'shared' mode, why it cannot do it every time you would call a 'pre-allocated' child VI ?

 

I don't understand what you mean by this.

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 ?

So why can't you pre-allocate a dynamic dispatch VI? Because to pre-allocate you need to link to a specific instance of the VI right? To know the specific instance you need to know the runtime data type of the class coming in, which we don't know.

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.

To make pre-allocated work you'd need to allocate (at compile time) memory for every possible VI that could be called. This means that if you had a 2 child classes you'd need to allocate memory for 3 VIs (one for the parent and one for each child). Now what do you do if one of the child VIs calls the parent's implementation? maybe that should be allocated up front? Now what happens if you dynamically load a class in a plug in architecture? You're code would need to be recompiled to add the memory for that new class? See how we're running into all of these weird situations, all of which would required allocating a bunch more memory?

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.

Maybe it's possible, but it's not efficient, and it'd possibly introduce a whole slew of other complicated design decisions. So that's why you're not allowed to do it.

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.

Could you not just create a static dispatch VI in your parent class that gets used in the ACBR node, and that VI then simply contains a single dynamic dispatch VI - the VI you originally wanted to call from the ACBR node?

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.

The VI who's ref you create is going to have a common connector pane across all classes. This means that if you have a child class, the input terminal will have to be of the parent's type. so you'll have to do a cast if you want to access any of the child's data. Either that or you'll have to use "Set control by name" invoke nodes, which I avoid at all costs.

 

Attached is a 2012 version of my example.

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.

This sounds like an interesting approach, but lately, LV2013 SP1, i keep getting burned by hacking around the call-by-reference nodes to try and fix issues like this.  There seem to be some weird deep labview crashing bugs that i keep stumbling upon when i do things like this.  

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 ?

It sounds like you are using the wrong kind of reentrant VI.  The NI signal processing VIs uses the Preallocate method of reentrancy which is less efficient than shared clones because a new copy must be created for each copy, instead of reusing already made copies.  The benefit is of course things like uninitialized shift registers work as expected because each copy is reserved for that call.

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.

You're right. You can't use un-initialized shift registers like you want inside a shared clone VI. This does mean that if you put any of NI's VIs which use pre-allocated re-entrancy inside your shared clone VI you will be screwed. And since you're forced to use shared clones with Dynamic Dispatch VIs, you're double screwed.

 

All and all, this means that data that needs to be stored between calls needs to be placed in the object's private data. It will now live on the shift register and the clone will just use the data, instead of storing the data. If you were writing the code from scratch, this would be no big deal, but since you're using NI's code, it becomes a pain. What I ended up doing is writing my own version of NI's VIs (typically started by coping and pasting) that strips out all of the shift registers. I think (I've not tested this way) you could also open a VI reference to the VI, then use a call by reference, and store the reference in the objects private data. I'd have to play around  with this way though.

 

It's annoying, and honestly, I think that NI should go back and give us a version of their VI's that don't have shift registers in them. Obviously this is a lot of work without much return, so I don't blame NI for not doing it.

 

And that kids, is why you don't use globals unless you're 100% sure you need them and there's no other way.

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