Jump to content

Malleable Buffer (seeing what VIMs can do)


Recommended Posts

On 11/15/2019 at 2:03 AM, ShaunR said:

Never mind. It seems that you cannot have DVRs inside VIMs any more.

Seems VIMs can no longer be used in polymorphic VIs either.

1 hour ago, drjdpowell said:

Maybe we need a "placeholder" type, or "Your Type Here". 

I don't think this is a good idea. The VIMs I've played around with (before the type case structure was introduced) relied on at least one terminal having a type which would dictate the undefined types due to the nature of the internal polymorphic VIs (like a Queue or DVR). This is why I was trying to get a VIM to create a DVR which "should" define the type across all connected VIs which would solve this problem. In a nutshell, I'm expecting this set of VIMs (rightly or wrongly) to behave like the Queue, Notifier et. al. primitives when the Enqueue and Dequeue element terminal is unwired.

Edited by ShaunR
  • Like 1
Link to comment
5 minutes ago, ShaunR said:

In a nutshell, the VIMs "should" behave like the Queue, Notifier et. al. primitives when the Enqueue nad Dequeue terminal is unwired.

Yes, that is the problem.  If I connect a "Buffer" of a certain data type, the "Data" input should adapt to be that datatype.  That's how Queues work, but there isn't a way I can identify to make VIMs work that way.  Outputs adapt to inputs, but not unconnected inputs.  

Link to comment
37 minutes ago, drjdpowell said:

Yes, that is the problem.  If I connect a "Buffer" of a certain data type, the "Data" input should adapt to be that datatype.  That's how Queues work, but there isn't a way I can identify to make VIMs work that way.  Outputs adapt to inputs, but not unconnected inputs.  

I think we've articulated the goal well enough. However, a VIM doesn't necessarily have a reference like Queues et. al. so I'm not sure there would be an "uncomplicated" first order solution for it even though it's a kind of natural progression from singular VIMs to libraries of VIMs. In theory, the second order solution is to use those primitives internally since they have that behaviour which should propegate out but I was unable to see if that worked with DVRs and trying queues didn't illicit the behaviour.

Edited by ShaunR
Link to comment
On 11/16/2019 at 8:15 PM, Aristos Queue said:

I have no idea why that limitation exists. I’ll ask on Monday. 

Those two primitives were explicitly tagged to be blocked... none of the people involved are still at NI. The comment says, essentially, “These boded crash sometimes when inlined,” with no useful detail, no steps to reproduce. I’ll look into it some more, but I have no clue what the issues could be. 

Link to comment
1 hour ago, ShaunR said:

Seems VIMs can no longer be used in polymorphic VIs either.

Malleable VIs never could go in a poly VI. It's been that way since they were introduced in LV 2017. That's by design: they conflict with the rules of polyVIs for deciding which instance to use. Poly VIs need a fixed list of connector panes.

Link to comment
16 minutes ago, Aristos Queue said:

Malleable VIs never could go in a poly VI. It's been that way since they were introduced in LV 2017. That's by design: they conflict with the rules of polyVIs for deciding which instance to use. Poly VIs need a fixed list of connector panes.

Yeah. but it worked n 2009 ;)

Edited by ShaunR
Link to comment
12 hours ago, ShaunR said:

Yes. It's a distinction without a difference GregSands found it, the community investigated it and malleable VIs were the productionisation of it.

Major differences: One was an off-the-cuff prototype that frequently crashed, couldn't nest properly, had no well-defined recompile semantics (so you couldn't trust that if you made a change the callers saw it), and didn't integrate with any of the rest of LabVIEW features except by accident (and, in the case of polyVIs, that  accidental interaction was a bug). The other is an actual feature. I don't think we retained any of the original code. Comparing them, especially in the context of complaining about loss of functionality, spreads disinformation to anyone who doesn't know the background history.

If you meant it as a joke, you forgot your </joke> tags. I did not find your semantic antics amusing.

  • Like 1
Link to comment
2 hours ago, Aristos Queue said:

Major differences: One was an off-the-cuff prototype that frequently crashed, couldn't nest properly, had no well-defined recompile semantics (so you couldn't trust that if you made a change the callers saw it), and didn't integrate with any of the rest of LabVIEW features except by accident (and, in the case of polyVIs, that  accidental interaction was a bug). The other is an actual feature. I don't think we retained any of the original code. Comparing them, especially in the context of complaining about loss of functionality, spreads disinformation to anyone who doesn't know the background history.

If you meant it as a joke, you forgot your </joke> tags. I did not find your semantic antics amusing.

Just because you refactor something doesn't make it a "new feature". And just because something is buggy, doesn't mean the the bug-fixed feature is different. The history is laid out in the thread I linked including discussion about the ""Type Enabled Structure" (which, although buggy;  appeared in LV 2016, IIRC) and some thoughts on addressing our requests for usage by JeffK (including polymorphic VIs). Even the file extension has remained the same (shouldn't it now be MVI?). I would accept it as being a "newly supported feature" from 2017 onwards, though.

It wasn't a joke but now you just seem to be gaslighting us. Malleable VIs are clearly the productionised implementation of VI Macros and I doubt "Malleable VIs" would exist without us discovering VIMs and discussing it here (they'd been around since about 8.2). That's not to be dismissive of all the work that has gone into getting them working properly - which is undoubtably immense - but some of us are just getting round to using the "Malleable VIs" in anger and of course the first thing we will do is go back to the code that we wrote for VIMs to find out any new limitations and what's been fixed.

Edited by ShaunR
Link to comment
On 11/16/2019 at 9:50 AM, drjdpowell said:

Question for AQ: I'm trying to use "Unbundle by name" to access the elements of the cluster (the buffer array and the index integers).   This works, but if the User accidently connects a cluster without the right-named elements, the unbundles can get scrambled, and not properly reset to the right names when a proper Buffer cluster is attached.   The only solution then is to delete that VIM instance and re-drop it from the pallets.  I can't find a solution and may have to switch to an unnamed unbundle, using the positions in the cluster.  That is less than ideal, and won't work in NXG (you know my negative opinions on cluster changes made in NXG).

I think I've come across something similar with named clusters and am not sure what the behaviour should be (but with events). The behaviour is difficult to describe but I'll have a go.

I have this setup. I'm not sure how the name "Data" is chosen for the scaler type name, but it's the name of the event terminal on the VIM so that makes sense if you have to call it something.

1.png.5f2ba7e1be96ded413e59421e48e2eb0.png

Deleting the Uint32 wire and wiring the cluster works sort of as expected with the ""Data" changing to "String" (i.e. one of the cluster elements). Popping up on the event data terminal reveals both cluster elements (String and UInt32). So far so good.

2.png.600f809956a366e781a8a5eb49c5a6c3.png

Deleting the cluster wire and reattaching the Uint32 however doesn't change the event data terminal (remains as "String")and the VI is broken. BUT, popping up on the terminal shows the correct data type in the menu, which can be selected, and the VI is once again not broken. Note also that replacing the VIM yields the correct event data terminal type (called "Data"). OK. Not really a problem, but unexpected.

3.png.4a1c0e1003ffb928a0b960c14ff9b46a.png

So. Reattaching the cluster we get back to the second image (event data terminal is "String") as before. Now I change the cluster element name from "String" to "Value". But the event data terminal doesn't change, it remains as "String". The VI is not broken and popping up on it reveals the previous items "String" and "Uin32". The name change hasn't propagated nor can it be selected from the popup menu. It is recoverable, though  although I'm not sure what would happen if I tried to generate the event with a string named "Value".

4.png.1be2d1925b021b8cdcd46ae8c78c5658.png

Deleting the cluster wire and reattaching causes it to appear in the menu popup (broken VI with "String" as the event data  terminal) so selecting it brings us back to a functioning VI.

5.png.b003d9525263c11cf20ac94cfbd847ad.png

However. If instead of just deleting the wire, the VIM is replaced completely, then everything changes as I would expect (the "String" event data terminal changes to "Value" and the VI is unbroken with the correct popup menu entries).

Arguably just a another example of "left handed scissors" but the cluster name selection and propagation strikes me as another manifestation of what  drjdpowell is describing.

srevent.vim

 

Edited by ShaunR
Link to comment
  • 2 months later...
  • 3 weeks later...
  • 2 months later...
  • 6 months later...
  • 5 months later...
  • 1 month later...

Malleable Buffer.zip

James: I did a lot of polish on your library -- cleaning diagrams, finishing out a couple of API points, documentation. I deleted the experiment stuff. You're free to take the attached files and add them to your published VIP if you want.

There was only one real functionality change that I made: a performance improvement to "Add to Buffer (By Value).vi".

Thank you -- this code is quite helpful in my current project.

  • Like 1
Link to comment
  • 8 months later...

@AQ,  I've incorporated most of your improvements, and made some changes myself.   Question, though.  These VIMs seem plagued by (in LabVIEW 2020) strange recompile bugs: broken wires that are usually fixed by doing a manual force recompile on the VI.  Though often this still leaves some broken wires in a runable VI?!?  See image.

1579043869_Brokenwireyetrunnable.png.c7f4ede40ed758cb65fcc478d4aca4da.png

What do you think causes this and is there a way I can avoid it?  

Link to comment
21 hours ago, drjdpowell said:

@AQ,  I've incorporated most of your improvements, and made some changes myself.   Question, though.  These VIMs seem plagued by (in LabVIEW 2020) strange recompile bugs: broken wires that are usually fixed by doing a manual force recompile on the VI.  Though often this still leaves some broken wires in a runable VI?!?  See image.

1579043869_Brokenwireyetrunnable.png.c7f4ede40ed758cb65fcc478d4aca4da.png

What do you think causes this and is there a way I can avoid it?  

I can't speak for the buffer library, but I've observed this behavior many times with malleable VIs in my own code. One thing (bug?) I've noticed (and reported on the dark side) is that nested type specialization structures within a vim can lead to broken wires. This is generally as a result of an assert vim inside a type specialization structure inside a vim. The callers wires are either visibly broken but otherwise runnable, or just broken even though the input types are supported.

The LabVIEW 2021 SP1 bug fixes mention a fix (bug ID: 1596011) for vims and erroneously broken wires, but I've not tried it out yet. I really hope that's the end of the broken wire quirks with malleable VIs, as they're a really great feature.

Link to comment
Quote

The LabVIEW 2021 SP1 bug fixes mention a fix (bug ID: 1596011) for vims and erroneously broken wires, but I've not tried it out yet. I really hope that's the end of the broken wire quirks with malleable VIs, as they're a really great feature.

For me it has improved but is not quite fixed. I still get broken wires on the calling VI when changing anything in some vims. In fact, I have a VI which I copied from the Debug Log.lvlib:Debug Write.vim in vi.lib and made some changes to. My version breaks when I change anything in it, but the VI.lib-one does not. I have force-recompiled and am now trying to make my VI work like the one in vi.lib, but mine still breaks. I just might recreate it and see where/if it breaks then. I don't know if I am unlucky or if that might happen for others too. When the wires do break, it seems like they auto-heal better than before, when I had to rewire at every broken place, but now its enough to just do something that triggers a compile (I think).

  • Like 1
Link to comment
On 3/19/2022 at 2:08 PM, Dataflow_G said:

The LabVIEW 2021 SP1 bug fixes mention a fix (bug ID: 1596011) for vims and erroneously broken wires, but I've not tried it out yet. I really hope that's the end of the broken wire quirks with malleable VIs, as they're a really great feature.

Thanks. I see there is also this one that may be the problem I'm having:

1513139        Malleable VIs Are Sometimes Erroneously Broken When Operating on Cluster Data Value References

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.