LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Sending a DVR over the network

I'm toying with a bad idea.

 

I create a large object that represents a channel, a large buffer representing the values and timestamps, the config, alarming, etc.  Because it's a large object, I manipulate them via DVR -- and I get some very fast speeds this way.  I then store (essentially) the array of DVRs in an array in private memory, and have a singleton manage them (having two channel managers in memory at one time would be disastrous).  Typically, I query by channel name, and the manager returns a DVR.  The singleton class just serves up DVRs for the queried channel (And it handles channel creation, blaa blaa blaa).  On the native computer, I can just grab the DVR once per VI and use it over and over.  No problems.  

 

However, when I need to send sample data from a remote computer, I send the channel name with the sample and have the manager look up the DVR each time.  This lookup process is fairly slow (~1ms).  Part of it may be fighting locks on the in-places, and part of it is using a notifier to handle the singleton (which accounts for a surprising chunk the execution time).

 

I'm toying with the horrible idea of flattening the DVR to a string, and send it to the remote computer, and have that computer send the sample data, along with the flattened DVR back with it so I don't have to do the lookup.  Other than it feels icky, I can't think of a reason not to try.

 

Kinda hoping someone can convince me that this is a horrible idea before I try it.  Thoughts?

 

-josh

0 Kudos
Message 1 of 8
(349 Views)

I can't think of reason that looking up a DVR by a channel name would be more than microseconds, so i suspect you're better of putting effort into finding what that slowdown is caused by.

 

Though you can use the flattened DVR as an identifier, as it is as much a unique identifier as the channel name is.

0 Kudos
Message 2 of 8
(334 Views)

Regarding the DVR lookup performance, have you tried setting "Allow Parallel Read-Only Access" on the DVR In-Place Element Structures?  That may reduce locks and speed things up.

 

playerm1_0-1733508437699.png

 

Message 3 of 8
(311 Views)

Flattening a DVR is simple, it's just an integer pointing to your memory. It'll however not do you any good as another process can't access your memory.

Flattening the cluster and sending that works, but it's not a DVR.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 4 of 8
(241 Views)

@Yamaeda wrote:

Flattening a DVR is simple, it's just an integer pointing to your memory. It'll however not do you any good as another process can't access your memory.

Flattening the cluster and sending that works, but it's not a DVR

 

 

 


 After I send the flattened DVR over network, the computer that gets it (and unflattens it) will be the top-level application that generated the dvr.

Agree with all the comments that I'm best to spend time speeding up the lookup time.  It was just one of those ideas that popped in my mind and was curious what would the downside be.  It feels dirty, and there's gotta be a downside.

Also, not that it matters, the DVR isn't just a pointer (integer describing a memory address).   It also contains some LabVIEWey goodness meta data.  But agree, conceptually, I tend to think of them as pointers (even tho they aren't quite).

0 Kudos
Message 5 of 8
(226 Views)

@drjdpowell wrote:

I can't think of reason that looking up a DVR by a channel name would be more than microseconds, so i suspect you're better of putting effort into finding what that slowdown is caused by.

 

Though you can use the flattened DVR as an identifier, as it is as much a unique identifier as the channel name is.


Once I have the DVR, accessing and manipulating the data only takes a few microseconds.  The actual search is blazing fast (especially if I sort the array or use a Map).  However, the class I use as a manager is a Singleton.  I didn't want to risk accidently having two copies of the manager exist.


Singleton Pattern - NI Community


I use the DVR and notifier (which seems faster than the que method) method.  However, pulling the manager class DVR (not to be confused with my channel DVR) from the notifier is fairly slow.  When I timed my "get instance" method, it was like 50-100uSec.  I've not looked into why, but  I assume that's probably going to be my floor unless I make the class Global (and implement locks), or something like that.

0 Kudos
Message 6 of 8
(220 Views)

What does your "get Instance" method look like?  50-100 usec seems very high for getting a DVR out of a Notifier.

0 Kudos
Message 7 of 8
(189 Views)

Sorry if this wanders off topic.. .but it might be interesting to someone...  Below is my Get Instance.vi.  I took it from the example given in:

https://forums.ni.com/t5/LabVIEW-Development-Best/Singleton-Pattern/ta-p/3529034 

 

 

 

snipet 001.png

 

 

snippet 002.png

 

It's actually running a LOT faster than I remembered it running.  Only about 20us.  I think the last time I used it, I didn't use the High Resolution Relative Seconds.

 

snippet 003.png

 

snippet 004.jpg

0 Kudos
Message 8 of 8
(140 Views)