Datasocket Server vs. Shared Variables

Does anyone have any thoughts on what is better - Datasocket Server vs. Shared variables?  I have a table on my application that has text indicating application status, information, warning and debug messages and would like to view it remotley over a network.  The old way was to use the datasocket server and bind it to the other control.  Is the new shared variable engine more efficient?  These machines are at different sites.
John

Hi John,
It definitely seems as if you want to gauge user experience on this issue, but since you've had no response I'll chime in and give the "National Instruments view" on the DataSocket/Shared Variable debate.
Shared Variables were created to expand the functionality of DataSocket and simplify the programming style required to pass information between networked computers. We have extensive literature on this topic and the most pertinent is linked here.
I hope some users will post to this forum to give you a less formed response than you get from me, but I am more than willing to answer more specifically if you have any more questions regarding this issue.
| Michael K | Project Manager | LabVIEW R&D | National Instruments |

Similar Messages

  • Opc server into shared variable

    Hello,
    I am writing a program to read hundreds of OPC signal from a server. The server is a  localserver in the PC but its not a Labview server. My labview program reads the OPC signal thru data socket into a Labview Library.(Variable type=single process)
    This way is working but not optimal. I have read in Help that I can use a Network-published shared variables. Does this Network-published be able to read the signal from my opc server thru a network path without using data socket? Must it be a Labview server? 
    this is an example for my opc address
    opc://localhost/hteControl_OPC_DA_Server/PLC_FI010_ValueLimit_SP
    Thanks
    Solved!
    Go to Solution.

    fmpfmpf wrote:
    Hello,
    I am writing a program to read hundreds of OPC signal from a server. The server is a  localserver in the PC but its not a Labview server. My labview program reads the OPC signal thru data socket into a Labview Library.(Variable type=single process)
    This way is working but not optimal. I have read in Help that I can use a Network-published shared variables. Does this Network-published be able to read the signal from my opc server thru a network path without using data socket? Must it be a Labview server? 
    this is an example for my opc address
    opc://localhost/hteControl_OPC_DA_Server/PLC_FI010_ValueLimit_SP
    Thanks
    LV-DSC (Data Logging and Supervisory Control) aloows you to "bind" the NSV to an OPC server.
    As long as the server os OPC compliant it should work and has ben the case for me.
    Ben
    Ben Rayner
    I am currently active on.. MainStream Preppers
    Rayner's Ridge is under construction

  • Modbus Ethernet read and write to a Eurotherm 6180XIO Modbus server using LV8.2 shared variables

    I am having EXTREME difficulty trying to establish communications with a Modbus device using LV8.2 shared variables.  The device is a Eurotherm 6180XIO Datalogger configured as a Modbus master.  The PC and a cFP-1804 are slaves.  All IP addresses are set correctly.  This approach using shared variables would seem simple, but I can't find any examples or proper guidance on how to get it working.  I am trying to avoid having to mess around with TCP/IP, OPC, or any other old-fashioned method.
    I have read many threads on related topics but none directly apply to this situation.  I have created a library containing a Modbus I/O server and shared variables bound to read and write holding registers.  I have followed all recommended tips for creating such variables but I can neither read or write data.  All data types are U16 due to Modbus protocol limitations.  I have also applied the LV x10 factor in the most significant digit in the register offset (6 digits instead of 5).
    I have a cFP-1804 on the same network which reads into the datalogger OK.  The registers I use are 31000 (for CH0 on module 0, 31002 for CH1, etc) and the data can be read as FLOAT32.  I have updated the firmwate on the 1804 to the latest level.  I cannot even get shared variables to read SGL values.  Using registers 301001 for CH0 and 301002 for CH1 I can only read U16 values, and not a 2-word SGL.
    Third party Modbus simulation software is able to write to and read from registers very easily, but not LabVIEW.
    Some questions are:
    - do I use a Modbus master or slave as an I/O server in the library as a target for binding the shared variables?
    - is there some other wierd translation in register offsets between LabVIEW and traditional Modbus?
    - is this actually possible using shared variables or am I wasting my time?

    Sending the whole 60-character string using a string or array would be the most efficient.  I have tried both methods, and these only cause the datalogger to flag a message log but no text is displayed.
    For a string variable, I have used the following binding "My Computer\Modbus Test.lvlib\ModbusServer6180\442305", where ModbusServer6180 is a Modbus I/O server configured with the logger IP address, and 42304 is the register offset at the start of the text block in the logger.  I need to write to 30 consecutive registers starting with this one.  I am not using buffering and have not enabled single writer.
    Can anyone confirm whether this method should work in 8.2?
    Does the string need a special termination character?

  • Deploying cRIO as Shared Variable Engine

    I am finishing up a project where a crio will be continuously recording data and the computer is running a program that will download the data once daily as well as comunicate with the program running on crio device over shared variables. Since the crio will be using a cellular modem to connect to the internet, connection loss is expected. For this reason we have made the crio serve the shared variables so that if connection is lost to the PC, the crio will continue to record data normally without problems when it writes to or reads from the shared variables.
    The crio will be running headless. I built a real-time application and deployed it as startup successfully on the crio device without warnings or errors. I connected to it via font panel to confirm it started up and is working properly. I will eventually use the application builder to build an installer that will install everything needed to run the program on the PC side. However, when I open the 'Belle Glade System PC' and run it, it attempts to deploy the shared variables on the crio device. It warns me that it will close any applications running on the crio device. This is not what I want. The shared variable engine is already deployed on the crio device and the program is running. All the PC program (Belle Glade System PC) needs to do is run and connect to the shared variable engine already deployed. I am obviously doing something really fundamentally wrong here and I could use some help. 
    [will work for kudos]

    I apologize for not posting the solution to the problem.
    Basically what you end up having to do is create two nearly identical shared variable libraries, one on the pc and one on the crio. The library on the PC has each of its shared variables binded to the corrosponding variable in the cRIO Shared Variable library by PSP URL (ip address and variable location). To do this, open the PC shared variable library and go to the properties of a specific variable. Check "Enable Aliasing" and under the bind to drop down menu select PSP URL. Then hit browse and find the variable on the crio. Do this for each of the variables on the pc.
    This option does not seem to be 100% reliable as it has trouble detecting connection problems between host PC and crio device. This is because shared variables look for a connection to the shared variable engine. However, both the pc and the crio have their own shared variable engine running as a host so there is always a connection as far as it knows, lol. This solution worked ok for me since I could not find a more relable option.
    There is a better explaination on this post: http://forums.ni.com/t5/LabVIEW/cRIO-Shared-Variables-amp-stand-alone-application/m-p/797139?query.i...
    [will work for kudos]

  • Shared variable vs. data binding

    Hi,
    I try to write a program which communicates motor drives through ethernet and I use OPC server and shared variables created using PLC. I created front panel indicators in a while loop with 50 ms cycle to read motor encoder position, status etc. When I try to do this with wiring shared variable to indicator and with changing the data binding property of the indicator browsing the same variable from the project library, data binding seems to respond slower than wiring the shared variable to indicator directly. Can anyone explain why?

    Hi mhn05, 
    I'm not exactly sure why it would be operating slower.  Do you have code that you can upload that benchmarks or tests the speed of these, side by side? 
    Thanks, 
    Dave T.
    National Instruments
    FlexRIO & R-Series Product Support Engineer

  • Do I have to Bind Shared Variables in Executables?

    I want to have shared variables work between two executables that will be installed on seperate machines.  I've managed to get the code working, but am not satisfied with the approach.
    Attached is a .zip file with my project files that contain what I've been able to get to work.
    What I don't like, is how I need to have double the amount of network variables.  Right now I have a program that is a publisher and another is a subscriber (based on an example provided on this forum at some point).  The Publisher has its own shared variables inside a library, and the subscriber has its own shared variables inside a different library.  The Subscriber's shared variables are "bound" to the Publisher's shared variables in the project file and is a concrete physical network path that cannot be changed.
    Once the executable is made and installed, this works.  I've tried getting it to work w/o one of the executables using a shared variable library that contain bound shared variables through a concrete physical network path but I obviously do not know what I am doing.  Ultimatly, I would like to have a single shared variable library that both the publisher and subscriber use.  I want the publisher executable to post the variables to the variable manager running on the publishers machine, and then have the subscriber program running on the subscriber's machine to consume the shared variables from the variable manager on the publisher's machine.
    Please help me!
    -Nic

    Hey Nic,
    I am going to try and answer those questions for you.
    If you use the DataSocket API to connect to a variable that resides on another machine, is your local machine's variable engine involved at all?
    No, it should not be involved at all.
    If the Variable Engine is not used locally, does it need to be included with your application installer?
    Yes, it is going to need to included with the installer.
    If I'm correct, whats better?  To use the variable engine locally, or to connect directly to a remote variable engine?
    Can you please give a little more information here?  I'm not quite sure if I understand your question.
    The default time-out on the DataSocket Read vi is 10 seconds.  If you are doing multiple DataSocket reads in the same polling loop, one variable may update but the other datasocket read is waiting for its timeout before allowing the loop to itterate.  This creates a really laggy scenario (see progmatic subscriber.vi in the attached .zip).  Setting the timeout to something low, say 10msecs, reduce the "lag" but...
    Having the ability to set a decent time-out is a really nice performance feature that isn't availabe to you when you Bind to a shared variable (I don't think).  It may make performance since to not do any loop iterations until the data from the host has changed.... how to manage this w/o seperating each read into its own loop however is my question.... ???
    Can you please explain this a little more as well?  If I understand you correctly, it sounds like you have many datasockets open in one while loop.  Are you using one datasocket per variable?
    Is there any unseen advantages with using the National Instrument's Shared Variable API over the DataSockets API?
    Shared variables are in general more easier to use, and provide a simple way to implement the idea of passing data between machines.  Obviously, using TCP, you can create more control using your own protocol to exchange information, but in general, Shared Variables are normally just easier to use.
    Feel free to post any questions or dicussion issues here.
    Regards,
    Kevin H
    National Instruments
    WSN/Wireless DAQ Product Support Engineer

  • Dsc opc shared variables yields Server Failure

    I've been struggling with the transition from DSC 7.1 to 8+ ever since the release of version 8. I use the Allen Bradley OPC server supplied with the DSC module (Industrial Automation OPC Servers v 5.1) to communicate with a PLC 5/30 via Ethernet, or at least I did when I was using 7.1.
    Prior to today I always failed to get the shared variables that were bound to addresses in the OPC server to deploy, usually getting an error number that started with -19. However today I finally got it to deploy by keeping the I/O server and the shared variables in separate libraries within my project. Now that they deploy I find that I am unable to monitor them. I keep getting a Server Failure. I have browsed the forums here heavily, and the documentation all relates to remote OPC, which is not what I'm doing here (OPC client and server are on the same machine). I tried changing the login account for the Variable Engine service anyway, but that doesn't help, so I put it back.
    I have had some luck simply binding my front panel objects to the OPC server addresses using Datasockets, so it appears that my OPC server is working. However, Datasockets is not a viable option for me because there are times when my project needs to write to a large number of addresses in the PLC sequentially, which never works over datasockets (in my experience).
    We have continued to work in version 7.1 because of the challenges of moving to 8+, but since we can no longer purchase DSC runtime licenses for version 7.1 in order to deploy, it seems that we MUST move forward to 8+ or abandon LabVIEW altogether (which is certainly an option).
    For clarification, I am now working with version 8.2 (but I've been fighting with it since 8.0 without much success). If anybody out there can think of a critical step that I might have missed that might cause this, or if there is a known solution, I could really use (and would greatly appreciate) the help. Thanks!

    Nobody out there seems to have any answers for this, so I kept pounding on it (and pulling my hair out). In the end I finally succeeded in getting one of my old 7.1 DSC projects to run on 8.2. Here's what I did:
    1. I begin with a fresh installation of Windows. I tested it with both 2000 and XP Pro. Vista RC1 will absolutely NOT work!
    2. Install LabVIEW 8.2, DSC 8.2, and just the OPC server that I need from the IA OPC CD (in my case the Allen Bradley server)
    3. Open the IA OPC server editor, and create a new file with an object in it for my PLC (PLC 5/30, Ethernet in my case)
    4. Save, set it as the startup file
    5. Run LabVIEW, create an empty project
    6. Add an IO server
    7. Launch Multi Variable Editor, load project file created in step 6, and bind one variable to PLC address
    8. Save all. Uncheck auto deploy for the library, and deploy all.
    9. Launch variable monitor, browse to new variable, double click to monitor.
    10. This will ALWAYS fail with "server failure". Don't worry, just exit completely out of LabVIEW.
    11. Stop the Variable Engine service.
    12. Run OPC server editor again, and load up the lpd file from your old project. Modify if needed, save, and set as startup
    13. Start the Variable Engine service again.
    14. Launch LabVIEW
    15. Create a new empty project (I created mine in the same directory as my old 7.1 project resided)
    16. Add an IO server, and uncheck auto deploy for its library
    17. Save all
    18. Run Tools->DSC->Migrate->import scf
    19. Convert your old SCF file
    20. Add the new library to your project (it will be named LabVIEW)
    21. Uncheck auto deploy for the "LabVIEW" library you just added
    22. Right click on the "LabVIEW" library and do deploy all
    23. Save, and open the variable monitor
    24. Browse to a tag in the LabVIEW library, and double click
    25. This time it will actually monitor the variable, with a status of "Good"
    26. Now you can add your main front panel VI to your project, open it and run it
    27. Version 8.2 will select the proper legacy tag read/write VI's, whereas 8.0 does not. The writes however do not work. Replace them with shared variable writes. The reads work fine.
    28. The empty project that you created in step 5 is a throw away. It will never work anyway.
    29. So far the only variables that I can get to work at all are the ones that I import from an scf file, which is a pain, but if I must create all my tags in 7.1 and import them into 8.2 I will (for now). I may try exporting to Excel and copying variables that work in order to get functional new variables, since binding them in the editor does not work.
    I hope this helps anybody else out there struggling with moving to 8+ DSC. I saw a few posts with similar issues, but without ANY answers at all. It's a convoluted solution that doesn't make a lot of sense, but for me it is repeatable.

  • I/o server shared variable not working in deployment system ( error no-1950679034 (0x8BBB0006) (Warning))

    Hello ,
             am using shared variable from opc client in labview when am run a exe file at development system its working fine but when am running it in deployment system its not working am using same configuration file in opc server at development and deployment system error -1950679034 (0x8BBB0006) (Warning)

    First Root cause needs to be identified before any actions.
    I would suggest first check if you can access the shared variable hosted in PC from RT using other ways like using SVE API (Logos and PS protocols, Datasocket etc..)
    Check if antivirus or firewall is playing...
    Check the same experiment with some other PC if you can.
    You can also try creating another Shared Variable in RT and binding the same to the PC and try to access it...
    Since you have did all the reinstallations already
    Best Regards,
    Vijay.

  • Problem Connecting Shared Variable to OPC Server

    Hi All,
    I use LBW 8.2.1 and DSC.
    I try to connect to an OPC server :  Emerson DeltaV
    When using Datasocket, I am able to connect to the DeltaV OPC server and browse (DSTP Server) to the variables I want to Read/Write.
    But, since I'll need to connect to hundreds of variables I want to use DSC and so the Shared Variables.
    When I try to bind the variable, Labview cannot detect the DeltaV OPC Server... Browsing results in a "Populating Node" comment... But never completes...
    Does anyone have a clue?
    Thanx to All
    Dai
    Dai
    LV 7.1 - WIN XP - RT - FP

    Hi,
    I do not trust datasocket for this. I already tried with LBW 7.1and after something like 150 datasocket connections to DeltaV OPC, some variables do not respond anymore.
    It's kinda wierd. It happens to groups off variables. Just add one more connection and a all bunch off the other connections freeze. Remove it and it comes back...
    One application Engineer of NI told me at the NiDays that datasocket was not meant for so many variables and that I had to use DSC.
    He said something like : "Now you know why datasocket ships with Labview and that you have to pay for DSC..."
    I'll take some screenshots to explain, but later... In fact, we are going to upgrade our DeltaV to version 8 or 9 soon (currently 7.4).
    Dai
    Dai
    LV 7.1 - WIN XP - RT - FP

  • I am trying to connect Dashboard shared variables to a server on a different subnet. Any ideas?

    My goal is to control a device that is connected to our wired network using an Android tablet via Dashboard.  I have created a vi with shared variables that controls the device as expected when it runs on a computer that is connected to the same wired network.  The problem is that my Android tablet running the Dashboard app cannot connect to the shared variables on the PC running the vi on the wired network.
    Our wireless network is on a separate subnet from our wired network.  I am able to ping my Android tablet from the PC on the wired network but when I try to connect a variable in Dashboard, the PC running the SVE cannot be found.  I tried listing it in the alternative server settings window and it still did not work.  The only way I have been able to get around this is to run the vi which launches the server on a laptop that is connected to the wireless network and the wired network at the same time.  My tablet can then find the server and my VI can connect to the instrument that is connected to the wired network.  The laptop is somehow acting as a bridge between the subnets.  I need to find a way for the Dashboard app to connect directly to the PC on the wired network.  My PC IP address is 192.168.0.105.  My Android IP address is 192.168.10.93.

    Data Dashboard doesn't care about subnets, but it has to be able to access the server using the right ports. There is probably a firewall blocking the shared variable ports. This document explains how to configure a firewall to allow shared variables to be accessed. Your challenge will probably be to figure out where the firewall is and how to configure it.
    It is also possible that the router that your Android device is connected to doesn't know how to route to the other network. Again, that is an issue with your router that you need to resolve.

  • Change Alarm / Quality of Shared Variables for I/O Server

    How does one set the Bad Status of a Shared Variable in 2009?
    IE).  I have a custom device that communicates via TCP/IP.  I wrote my own I/O server that handles this communication and publishes a set of Shared Variables that my Main Application displays on a screen.  These variables are all doubles and hold pressures and temperatures.   If my I/O server in labview loses communication I would like to be able to set the status of the variables to bad so they will set off an alarm.  In our main application we have colour indicators that are able to display this status.  For example the background goes yellow for all indicators that are in "HI" alarm status, red in "HI HI" and orange when "Bad Status" (disconnected). 
    We were able to accomplish this using LabVIEW 7.1 DSC, by creating a VI to register all our "Tags" and a VI to run the server.  The server vi's that came with 7.1 allowed us to set the quality when writing to the server item.  Therefore when the device was disconnected or failed we could set the bad status and use the DSC system to log an alarm and use the alarm features to colour code our indicators. 

    None of the Shared Variable IO Properties can be configured to allow you to set the alarm.  You can only configure the properties such as turning the possibility of the alarm status on/off and the priority, name etc.  You do not have the ability to indicate that this shared variable is in alarm because your custom server has encountered a problem.   I've talked to tech support about it and I've been informed that this was something that was removed when the shared variable engine was introduced.   I've been told informed that the recommended alternative is to create an additional boolean shared variable that will contain the status of the items, or to write some sort of unique garbage value to the actual tag value to indicate there is a problem with it.
    I now have to come up with a new way of providing this information.  I just find it will likely be a poor programming choice because now my entire system will have to handle "tags" differently based on what hardware is being used.  (IE) if its coming from a custom I/O device or from an OPC / Modbus etc capable device. 

  • Is Shared Variable Engine with LV8 an OPC server ?

    Hello
    Is the shared variable engine with LV8 an OPC server ?
    Does any OPC client can acces to Variable Engine OPC server an read shared variable ?
    Can I build an installer and deploy my application with Variable Engine OPC server on other PC without LV8.
    Thank you 

    Hi
    You can communicate between an OPC serveur and LV8 and use shared variable. To deploy an LV8 exe application, you must have the run time engine installed on the PC without installing LV8. You can create a setup with LV 8 in which you can integrate the run time engine.
    Kamal
    NIF

  • Shared Variable Engine OPC Server & Matrikon OPC Explorer

    Hello All
    I have a shared variable Engine OPC server running on my IPC. I am querying NI OPC Server through Matrikon OPC Client. My situation is if shared variable engine process is switched forcefully off (NI DSM) or communication between server and client is lost then client is crashing which is quite obvious. But the problem is if Server is Up again then the client is not connecting to server automatically.
    First of all is it  possible, that if server is up again then it will try to send some signals to the priviously connected clients ? If yes then do i have to make changes in shared variable engine properties ? How i can do this ?
    I hope you all will understand my problem, if not please post you doubts. I will try to clear my points.
    Thanks & Regrad´s
    Varun Garg

    Hi, just now I face a similar problem. When clients restart connection, the variable engine crash, for now the only way founded is restart the program programmatically, but I'm interested in how fix that.

  • Shared Variable VI development on machine other than server

    I'm about to do my first shared variable code, I read the white paper
    http://www.ni.com/white-paper/4679/en
    Something that isn't immediately clear to me is the expected work flow in actually creating ALL the VIs using the shared variables.  I tried creating the project and the variable as per instructions, easy.  But I'm going to have one of those VIs running as the server of the data and one as the client.  Would these be two seperate project files with the same variable name and type?  One project file with seperate builds for server and client executables?
    Actually, SV might not even be the best way to do what I need.
    I have a PXIe machine with a slot 0 controller that has a mux (a pxi-2503) and dmm (pxi-4072) for getting measurements from multiple channels.  Rather than calling via VI server every time I want to grab a measurement I'd rather have an application running waiting on commands.  I was thinking of creating a crude command/acknowledge data avail/acknowledge scheme to synchronize the PXI slot 0 with the client that will be requesting the data, but I can imagine there is probably a more suitable framework that someone else has no doubt tackled?
    I just need to guarantee that the rack takes the measurement when I want it to (ie, after some other action I've triggered the system to perform) and that the data I get back from it is identifiable.
    Ideally, I'd have a MXI controller and this gets really easy but I won't be able to get ahold of one for months if at all so I'm going this route for now.

    Hi Marcus,
    When I drag a shared variable from the project window into the block diagram and then left click it and go to browse, I'm only presented with variables on my local machine to choose from.  If I switch into programmatic access and then go to browse I'm presented with a nice list and am able to browse to the remote shared variables and select it for my constant/control.  This works fine and I'll remember to do this from now on, I just wonder why the two different behaviors.
    I have this working quite well provided I go ahead and start the VI running either with a built exe or through the vi.  As these instruments are going to ultimately be sitting in a headless (no monitor/mouse/keyboard) PXI with slot 0 rack, I am now trying to figure out how to either start these VIs running remotely.  I thought I'd just be able to drop the .exe into a windows scheduled task and have it run on start up.  This works fine but my client VI doesn't communicate.  If I go ahead and log in to the machine I can see the exe running in the Task Manager.  If I kill that exe and start a new one then I'm able to communicate with the VI though with some initially odd behavior, almost as if when I was running it on the client the SVE had changed the states of the variables locally and then when the new process was started it latched those states and causes me to have race-like conditions.  If I then kill that exe and start another one everything is in its expected "default" state and I don't have race like conditions or get into unexpected states.  I can probably add some code on the client side to avoid this weird behavior but I'd rather understand why things aren't working.  My guess is the SVE and other NI processes on the headless box aren't starting properly until I actually log in?

  • Shared Variable: Server Failure

    I'm binding Labview 8.2 Shared Variables to Fieldpoint channels, using OPCFieldPoint Server. The OPC Server works properly, i can connect to it using Server Explorer 2.4.1 and see all the channels (though i had to do a repair installation of Fieldpoint 5.0.1 to obtain this!). But Shared Variables bound to OPC Items don't work, i get "Server Failure" error both in Variable Manager and in project VIs.
    Fieldpoint channels are visible in MAX, and readable using direct Bind to Source. Just OPC and NI Variable Engine don't seem to talk to each other, though everything is on the same machine. I have even set up the SVE as explained in http://digital.ni.com/public.nsf/websearch/8719713F089653C1862570F10074E06B?OpenDocument and set an administrator account (do administrators always have DCOM privileges?).
    Thanks for any help!

    With this kind of "intelligent" FP, you don't need to use OPC!
    You can create your variable and write in it in the field point, and read it from the PC, as you can see in the example picture i attached.
    You do this simply using the variable engine.
    Ciao!
    Attachments:
    example.JPG ‏113 KB

Maybe you are looking for