Datasocket ActiveX problem

[tjazx9r]

I have an issue with the standard Datasocket VI's that come with Labview 8.2.1. Datasocket has an ActiveX component which should theoretically act the same as the canned VI's. I wanted to test the ActiveX functionality so that a fellow programmer could pass/receive data from my Labview program into his Visual C++ program. I will use the Datasocket Read/Write vi's and he could use the ActiveX components in C++.

I'm using the 'DS 3D Graph Reader.vi' and 'DS 3D Graph Writer.vi' from the examples as the base to test out ActiveX. I spent most of a day trying to get the reader portion to read the standard output of the Writer. I kept ending up with an array of the correct size with all zeros instead of the data. If I switched the reader back to the canned vi, it worked fine. No matter how I configured the ActiveX settings, I could not read the data.

Then I modified the Writer to use ActiveX to write data to the server instead of the Datasocket Write vi. Once I did this, I can read the data using either ActiveX or the standard Datasocket Read vi.

What I can't figure out is why the write portion makes a difference. This is my first time using Datasocket, but not ActiveX, which I've used to communicate with Windows components and devices many times in the past. The documentation included with the Datasocket ActiveX is pretty sketchy and missing several settings which are available (the Sync settings and the Buffered settings).

I've attached the vi's I modified to try out. Make sure to start the Writer first.

Thanks in advance!

Tom

[Captain_Kirby]

Hi,

It looks like were missing a few subVIs in your writer VI (create waveform and Launch DS Server if Local URL.) If you could post those as well, I'll give it a look and see if I can find out where the trouble is.

[chrisger]

Hi there

in case you are handling dynamically created DSTP items the item will be removed from the server as soon as no client has acces to the item. The DS Read/Write functions finish acces to the item after execution when wiring the URL string to the functions. Use the DS Open/Close functions to create a "connection ID" to the DSTP item. When working with connection IDs the connected item will stay on the server as long as the connection is not closed (see attachment)

if you want to use the URL instead of the connection ID you should create static DSTP items. use the DS Server manager to create such items.

[tjazx9r]

Thanks, guys.

No joy, unfortunately.

I tried 'Datasocket Open' outside the loop and then closing it when quitting, but I'm still having the same issue: an ActiveX read cannot see the data, but a DS Read can.

I've attached the new 'DS 3D Graph Writer' vi and the 2 subvi's, though Labview should have been able to find them - they're from the standard example vi.

I don't see how to configure the Datasocket Server. Diagnostics lets me see the 3dgraph folder with the 'data' item in it, but not modify it's characteristics in any way.

Any other suggestions?

[chrisger]

Hi there

see attachment of how to use the ActiveX DS objects. you can find the documentation at National Instruments\DataSocket\Help, the DS Server manager is located at \National Instruments\DataSocket\cwdssmgr.exe

[tjazx9r]

OK, I finally figured it out. Datasocket is working fine, but the output of the 'create waveform' subvi is 'extended', which is giving datasocket fits if I mix the standard DS Write with an ActiveX reader for some reason. If I convert the data to double-precision, everything works as it should. I tested this with both my modified example vi's and Chris' dstp.vi by adding the 'create waveform' subvi to his program as the data to pass instead of just an integer stream.

I imagine DS Write polymorphy (is that a word?) does not handle extended precision properly, though this doesn't explain why DS Read can see the data but the ActiveX can't, unless both of the DS vi's handle extended precision the same odd way.

[chrisger]

Hi there

it seems that EXT is not supported by DSTP. You can transfer the bytes of the EXT data as an U8 array and then do a typecast in the client application (see attachment. Should be possible in other languages than LV as well).