shoneill

Your sub-VI does not have a loop. It will run once and once only per Event. If you leave the FP of the sub-VI open, you can click on the boolean when it is not running and it will be applied whenever it is run.

If you want your sub-VI to keep running, it also needs a while loop around it(either in the sub-VI itself or ourside). Just make sure you have a stop criterium for the loop.

If you go into the properties of the sub-VI you can also set the FP to open when called. This still won't make it keep running, but it will at least make sure the FP is opened.

Works for me.

What do you expect to happen?

A picture is not a VI.

You say you added a while loop. How? There are still a lot of variables which could go wrong. Post your code or we can't really help.

Maybe post your VI?

18 hours ago, X___ said:

Sure. But then you cannot move the elements independently. Unless you ungroup, move, regroup.

A modular object (such as a Graph) should be moveable as a whole, but its components should ideally be moveable individually. I have no idea how NI does that with their native controls, but this is obviously feasible. This is for instance something that was completely destroyed in XControls (an XControlled-Graph is frozen solid if I recall my now forgotten attempts to expand Graphs, unless you rebuild the whole independent component grabing and moving, as I was told by NI).

Something can't be in a peer group and not be in a peer group at the same time. This is how the LV diagram "Group" works.

What NI has is a parent-child grouping which is something different.  Not saying this couldn't be an interesting idea, just that it's not comparing apples with apples.

On the other hand:

What is "too slow".

What should "faster" be?

Turn off debugging will certianly help.

On 4/19/2019 at 6:34 PM, X___ said:

Of course, what's missing for this to be even practical, is more flexible way of grouping objects in LabVIEW (that is, one that allows moving things within a group).

You might want to get in touch with Wiebe for that....

You are setting your offset to 0.001 of a single sample. That's not going to be visible.

The top value in your clsuter is your offset (zero X value). The second top value is the time spacing between adjacent data points (not the entire length of the plot).

If you need 100 data points before the trigger, try

Top: 0.001, Middle 0.00001, Bottom, your data

You SHOULD use proper timing data.  If your data is recorded at 1MHz, the middle value should be 1/millionth in order to have your X-axis in seconds.

Please note this also only changes the DISPLAY of your data, it has nothing to do with the data's ACTUAL position relative to your trigger. You need to set up your acquisition properly in order to guarantee that.

On 4/19/2019 at 11:26 AM, gb119 said:

XControls are a bit of a pig, on that I guess everyone can agree....

But which bit? Some bits are actually quite tasty..... 🥓

Did not know about that function. Nice.

16 hours ago, ShaunR said:

There has to be a meme that can link GoT and NI inter-departmental politics.

👍

1 hour ago, Aristos Queue said:

There's no way my much smaller team will stay ahead of NXG for too long.

Hold the Door!

3 hours ago, Aristos Queue said:

There are no plans to extend LV 20xx capabilities of XControls or anything similar. All work into improving G-based UI components is being done by NXG teams. I and others continue to push requirements to them (such as "let them be included in arrays"). (In case y'all are wondering, my role with NXG is largely "lead user kibitzer". I have worked on various parts of the code base over the years, but at this time, I am 100% tasked with adding features to LabVIEW 20xx, especially language extensions (there are others on my team working on editor improvements). The channel wires and the malleable VIs have been my work; there's a couple new data types in LV 2019 that fill some serious long-standing language holes. And LV 2020 should... well... let's say I'm kind of eager for it.)

So your job is to make it as hard as possible for NXG to ever catch up with with LV 20xx? 😀

3 hours ago, Aristos Queue said:

I don't believe this was ever promised.

It was listed as part of the roadmap, with the added caveat, that such extension would be available only in C#. I certainly remember it being communicated as the way forward with regard to replacing XControls.  It was certainly used as a carrot, even if the word "promise" is not accurate.

Then at the CAB in Austin some years back, we were told that won't be happening, that the existing control classes won't be extendable.

I can't recall exactly who and when, but it was definitely communicated.

10 minutes ago, ShaunR said:

11 xControl bugs currently in the known bugs list will never be fixed.

Is the existence of XControls one of those bugs?

4 minutes ago, hooovahh said:

I too wouldn't be surprised if NI doesn't invest in XControls, or an alternative. 

I'm pretty sure XControls are dead in the water. But I sure hope they are working on an alternative, at least for NXG.

7 minutes ago, ShaunR said:

I don't think it matters. If it's a package that comes with LabVIEW, you can choose to use it or not. 

My usage of it or not is completely irrelevant to the point I was trying to make.

NI should be working on a proper implementation of extendable controls (C# inheritance was touted, then it turned out that will be limited / useless). I fear they are looking for a way out of that corner. But still, if we're realistic, there'll probably be notnhing of that sort coming in the next X years, so this IS a boon. I just hope this doesn't stop NI working on a proper implementation.

I'm not casting any shade ont eh toolkit itself, it looks pretty amazing.  The reason I think it might sway people at NI is because it IS good. If it would be half-arsed, I wouldn't be afraid. So from that point of view, technically speaking, 🧡

1 hour ago, hooovahh said:

You are incorrect they do and it is amazing

I don't think I am incorrect. It mimics the existing VI Server tree, but it does not extend it per se. I agree it's a great toolkit and has a LOT of potential, but it's just not the same.

I've done something very similar, I'm aware of the benefits and the limitations of this type of implementation. Code changing properties of the control in parallel to the LVOOP approach can be very hard to manage.

22 minutes ago, ShaunR said:

I see it has a place, but it doesn't seem to be a replacement for xControls

I agree completely, but will NI spin it differently?

In end effect what we need is the ability to actually inherit from existing controls in order to extend their functionality. Just being able to extend a String control to allow for a dictionary should be possible without it being distinguishable from a "normal" String control on the FP or BD (Perhaps for some identification on the BD of it being an extended control).

XControls never really offered this. Correct me if I'm wrong, but I don't think QControls do either.

We were promised that NXG would get exactly this kind of extensibility, but having heard nothing more on it (and a few rumours to the contrary, I fear the worst).

I have the feeling NI might use this as an excuse to see their promise of extendible FP controls as being fulfilled. For this reason and this reason alone I am skeptical and pessimistic.

TL;DR. Technically yes. Politically and strategically no.

One VI to rule them all, one VI to find them,
One VI to bring them all and in the darkness bind them.

Passwords I'll assume.

To make sure no Events are lost I usually just register the user event at the moment of creation and pass out the event registration refnum for the event.  Then, any events sent before the Event loop is running are not lost, they are stored within the event registration refnum queue.

A different idea is the ability to get the last sent value.  I typically involve the event loop in this as it "owns" the values and other processes may actually update the values (such as internal consistency checks) so that the last "sent" value is not actually up-to-date.  But I canunderstand the idea behind being able to efficiently get this value back.

I had a look at the code, but I guess it's lost on me a little.

So the idea is that the code allows for stateful sending of events, that one can recall immediately the last value sent via Event (stored in a Notifier)?