LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How do I programmatically create a waveform shared variable?

I'm trying to use the Create Shared Variable (DSC) VI to programmatically create a waveform array SV, but the only data types available are u32BitField, bool, double, and string.  What gives?

 

0 Kudos
Message 1 of 9
(3,528 Views)

You can flatten the waveform to a string and unflatten when you want to read it back.

 

Amit

0 Kudos
Message 2 of 9
(3,524 Views)

Ewww.  Won't that be pretty inefficient?  I'm sending gobs of waveforms back to the host PC.

 

0 Kudos
Message 3 of 9
(3,523 Views)

Maybe I'm asking the wrong question.  I'm using datasockets on both ends.  The only reason I'm calling create SV is because I was under the impression that a DS can talk to a SV but cannot create one.  So if I only care about the two DS ends talking to each other (efficiently) and don't care so much about the SV, is there another way to get the DS publisher and subscriber connected?  Or should I not be using a DS at all?

 

0 Kudos
Message 4 of 9
(3,522 Views)

Datasockets os a lossy protocol. If you don't care that you read all data points then datasocket is fine. If you are keen to get data from one computer to another without loosing any data, you are afterall sending a waveform, the best protocol to use is TCP. There are some good examples of TCP in the LabVIEW Example finder. Just remember to open the ports in the windows firewall.

 

Also remember that all data get flattened before you send it over a network!Sometimes it gets done without your knowledge sometimes you explicitly do it!

0 Kudos
Message 5 of 9
(3,490 Views)

You mean DS use UDP?  Actually best effort is fine for me.  I'm interested in low latency more than reliability.  I understand that there is always some sort of flattening involved, but some flattening is more efficient than others.  Turning an in-memory representation into an ASCII string representation can be expensive, but simply dumping the raw bytes from memory is the fastest (although could run into byte-swapping issues on the receiver if it's a different architecture).

 

So how can I get a DS publisher and subscriber to talk if there is no SV committed to the SVE?  DS seem to have been developed as an independent tool and happen to have a hook for SVs, so I'd be surprised if there wasn't a way to connect them without a SV ...

 

0 Kudos
Message 6 of 9
(3,486 Views)

I foudn a discussion that states that Datasocket indeed uses TCP, but doesn't support buffering and as a result reads only the current value!

http://forums.ni.com/ni/board/message?board.id=170&message.id=26192&requireLogin=False

 

Datasocket came before shared variables. When uses with shared variables you need to use the psp protocol. You can use the inbuild datasocket server, dstp. You can even use it to communicate directly with OPC servers. I forget the protocol used there. The LV Example finder has a good example of DS writer and DS reader.

 

If you are concerned about efficient data transfer, I would suggest that you manually flatten the string by breaking up the waveform cluster. However, I doubt this will be any more efficient that what LabVIEW does by default. Only experimentation will show the most efficient method.

 

Amit

0 Kudos
Message 7 of 9
(3,483 Views)

Hi all,

 

Writing the waveform directly to the data socket with the data socket server running on the receiver should work fine. I cannot speak to the efficiency of the task.

 

Yes, datasockets use TCP.

Jeff | LabVIEW Software Engineer
0 Kudos
Message 8 of 9
(3,462 Views)
I ran a few tests to attempt to benchmark it using the Ticks before and after in a flat sequence in the DS Write example. Using a 50 point waveform and testing the sending VI yields approximately the same length of time for both methods (direct write to data socket and flattening first).
Jeff | LabVIEW Software Engineer
0 Kudos
Message 9 of 9
(3,420 Views)