Jump to content

Notifier with buffer


Recommended Posts

True. If, on the other hand, it is an option it is a good one. For the record, I think for a number of reasons that the functionality in the DSC Module ought to be part of the LabVIEW core. In particular, the functionality in the DSC Module is an extension of existing functionality in such a way that it can take a while to figure out where the boundary lies. Moreover, the publish-subscribe option (Observer pattern) is extremely useful--and pretty much a common programming standard--and NI ought to promote its use in most applications. I think doing so would make LabVIEW development more effective and presumably enhance its marketability in turn.

I didn't try this, but I'm guessing from your question that it will be big. Then the developer must choose whether the larger memory footprint justifies the ease of development for the particular application. (I also presume that the footprint does not scale linearly with the number of shared variables.) I think for many (most?) applications the larger footprint is not a serious issue.

I don't have a problem with large installations per say, but when you have to deploy an installation of a couple of hundred megs to run a 300k executable, it makes Microsoft look positively anorexic.:nono:

I could understand it in the old days when LV run as a virtual machine giving you 32 bit applications in a 16 bit world. But now its just a huge api with loads of dependent apis that have nothing to do with your program (like PXI for instance).

---rant over :P

Link to comment

In practice we haven't needed to create SVs from scratch at run-time yet.

I thought you might have, as this method of generation lends itself very well to an OOP architecture.

Having said that, I haven't had the chance to design any apps like this, but I have been lucky enough to do maintenance on ones that have.

And I can see the benefits are really cool.

Link to comment

And I can see the benefits are really cool.

No doubt!

I think this is a great idea. We just haven't done this (except for some test cases) ourselves yet for the following reasons:

1) Most of our subsystems use RT SVs where (prior to LabVIEW 2009) LabVIEW objects didn't exist. (This isn't a dealbreaker, though.)

2) Our data SVs have been clear at design time and it has just been easier (and still successful) to create them using the project interface. That doesn't mean the better way wouldn't be to create them programmatically. Ideally that is what we would do.

3) On Windows we do support dynamic object data messages but to do this we create string variables ahead of time and send flattened LabVIEW objects of various types on a shared variable (topic) or two. We have implemented the Command Pattern effectively using this methodology. Again, we probably should create the string SVs programmatically but we haven't bothered to do that yet. The more SVs we create, though, the more important it would be to do this programmatically.

Paul

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.