Modbus and shared variable performance in large application

Hi all,
I am preparing to work on an application which is going to reading from up to 500 Modbus input registers on a CompactRIO over Modbus Ethernet using the LVRT Modbus IO Server implementation. I've put together some minor test VIs on the local network to test the Modbus connectivity and understand in the shared variable minding mechanism.
To save potential headaches in the future, do you all have any best programming/proejct management practices for using high channel count Modbus applications? Has anyone done high channel count testing (similar to the link below) but for shared variables bound to a Modbus I/O Server? Any caveats I should keep in mind?
Performance Benchmarks for Network Published Shared Variables
http://www.ni.com/tutorial/14675/en/
Thanks,
Chris
d2itechnologies.com

If your application can deal with it I would recommend staying clear of the 'Networked Published' option.
When I started my Modbus development on cRIO....I left it enabled, and with ~100 shared variables on a 9074, the CPU was railing, and I saw a buffering behavior on the shared variables (which was not desirable in my application).
In my application I am using the old modbus library (as apposed to the new API) for cRIO to slave comms, the cRIO being the master.
I am also using the IOserver making the cRIO a slave to an external SCADA - and it passes essentially the same data arrays as I use on the modbus library for my local HMI [Not an NI product].....Which is two full Modbus frame writes (@ 120 words each, and about 60 words more for ~300 words outbound from the cRIO).
The IOserver slave was a recent addition and did not add much to the CPU load - although only 16 bytes is high speed, the balance of the total word package is at either 1 second or 3 seconds.
So, in my experince, the 'Networked Published' option adds significant CPU loading (on entery level cRIOs) YMMV.
I am huge fan of the shared variable engine (some at NI were pusing the CVT, and TCE etc...). However most of my shared variables are not the Networked Published variety (excepting local module channels) those have remained networked published for DSM (Distributed System Manager) use.

Similar Messages

Datasocket and Shared Variables

I am curious if there is any advantage to using Datasocket to read/write shared variables (as opposed to a direct read/write). I'm specifically talking networked shared variables here.
Is there any speed advantage to accessing shared variables thru the Datasocket functions? Since both a direct read/write and a Datasocket PSP read/write talk to the same variable engine I assume they are equally efficient but I'm looking for confirmation here. I've seen benchmarks for shared variable performance but none of them use DS/PSP to access the variables.
Normally I would not even think of using Datasocket to access shared var's but where I currently work we have a large app that does this and it works great. I suspect that this functionality only exists in LV8.x for backward compatibility and non-Windows OS compatibility and is not really meant to be used for new, Windows-based apps? Am I off base on this?
I am working in LV 8.5, BTW.....

Hello Jared,
Thank you for the reply with clarification.
Based on your comment, I changed the buffer parameters and also tried the programs with two different data types, previously StringArray and now String.
In the attached LV8.6 project, you have all the programs, and shared variable library to review my tests.
There are two sets of two files - each set has a Write Shared Variable and Read Shared Variable file. One set is for StringArray type Shared Variable (named StrArr in the library), and the other set is for String type Shared Variable (named Str in the library).
String Array example:
MultipleDS-Write-SharedV-StrArr.vi / MultipleDS-Read-SharedV-StrArr.vi
In my String Array shared variable, I use only 4 element array, each having 4 character strings - meaning 16 bytes per String Array data. I have two loops in the write file, writing to the same variable, an array of 4 strings, each loop continues until the loop index is >0. This means, sometimes, depending on the processor speed, the variable will be written 3 times or 4 times (the variable could have a new value before the loop condition is checked).
So this means, if I have buffer of 100 bytes (16*4=64<100), it's enough for 4 such arrays (of 4 elements, each element with 4 characters) could be buffered to have sufficient time at the client (Read) program to read them.
I am putting 2048 bytes in buffer, which is much more than sufficient in my case.
The writer loops run with 200 ms to wait for each iteration. The reader loop runs with 100 ms in DS timeout and 100 ms in wait timer. This gives results without any loss. However, if I run the reader loop with 1000 ms to wait for each iteration, the data is lost. The buffer is not maintained for 2048 bytes.
In the read program, just to make sure if all data is read or not, I am showing data in two different string indicators, showing data of each loop.
String example:
MultipleDS-Write-SharedV-Str.vi / MultipleDS-Read-SharedV-Str.vi
The String Array shared variable didn't show values in the Distributed System Manager. Hence, I created another simple variable with String datatype.
The writer program writes strings of 4 characters, one-by-one, in two loops. Meaning, total 8 strings of 4 characters each are written in the "Str" Shared variable.
The reader program, however, doesn't always display all the 8 strings. Although the wait timer is not high (slow) it still misses some data usually. Data is overwritten even before the buffer is filled (in buffer, I have defined 50 strings with 4 elements in each).
In both of the Read programs, I read using datasocket. I think thought datasocket has more ability to buffer. Earlier I had "BufferedRead" in DataSocket, which I have changed to just Read, because BufferedRead didn't give any special buffer advantage in the Shared Variable reading.
---- This is an update on the issue.
Ok, just while typing the last paragraph above, regarding datasocket, something clicked in my mind, and I changed the DataSocket functions to simple Shared variables (completely eliminating datasocket functions) in the read programs as well. And bingo, the buffer works as expected, even if I have reading loops very very slow, there is no data loss in any of the program sets.
The two changed Read programs are also included in the attached project - MultipleSV-Read-SharedV-Str.vi and MultipleSV-Read-SharedV-StrArr.vi
So this means, I can completely eliminate DataSockets (not even using PSP URLs in DataSocket Open/Read functions) from my programs.
One question here, what will be an advantage of this (or any side effects that I should be keeping in mind)?
Vaibhav
Attachments:
DataSocket.zip ‏71 KB

Modbus ip shared variable network failure

I am using lab view 8.6 DSC module to communicate to a watlow system which contains five watlow 96 controllers and an EM gateway. I have created shared variables for the process temperatures and setpoints for each of the five controllers using watlow modbus register Numbers with a 400001 offset. I have also created shared variables for Updating,CommFail,UpdateNow,and UpdateRate which where predefined. I have error when starting the VI if the SV has been dragged and dropped into the block diagram. The message is Error -1967353902 (The Modbus I/O server failed to receive any response from the Modbus slave device.) occurred at SV in vi. If I bind a variable in the VI to this same SV the error does not occur but the variable cycles between Good, Network Failure, No known value, and device failure as stated in the variable manager watched variables. The Updating, CommFail and UpdateRate all have a consistent Good in the quality column of the variable manager. UpdateNow has X in value, type, timestamp, and quality columns. CommFail and Updating does cycle between true and false randomly. I have tried a third party software called SpecView 32 demo to see if the commincation with the modbus system is not working and I can create five watlow controlers on my screen and direct them to the ip address along with a unit address and the system works without faults. This leads me to believe the commincation bewteen the SV Engine and the IP address is not correct. HELP Please.
Robert Jensen
UND EERC

If your application can deal with it I would recommend staying clear of the 'Networked Published' option.
When I started my Modbus development on cRIO....I left it enabled, and with ~100 shared variables on a 9074, the CPU was railing, and I saw a buffering behavior on the shared variables (which was not desirable in my application).
In my application I am using the old modbus library (as apposed to the new API) for cRIO to slave comms, the cRIO being the master.
I am also using the IOserver making the cRIO a slave to an external SCADA - and it passes essentially the same data arrays as I use on the modbus library for my local HMI [Not an NI product].....Which is two full Modbus frame writes (@ 120 words each, and about 60 words more for ~300 words outbound from the cRIO).
The IOserver slave was a recent addition and did not add much to the CPU load - although only 16 bytes is high speed, the balance of the total word package is at either 1 second or 3 seconds.
So, in my experince, the 'Networked Published' option adds significant CPU loading (on entery level cRIOs) YMMV.
I am huge fan of the shared variable engine (some at NI were pusing the CVT, and TCE etc...). However most of my shared variables are not the Networked Published variety (excepting local module channels) those have remained networked published for DSM (Distributed System Manager) use.

Strange behaviour with Vision 8.2 and Shared Variable 1D Image Array

I've just upgraded to LabVIEW 8.2 and Vision 8.2. When loading a particular VI, it is searching numerous times for ...\LabVIEW 8.2\resource\objmgr\IMAQ Image.ctl - which of course doesn't exist. As best as I can track it down, this seems to be cause by a Shared Variable I have in the project which is a custom control of a 1D array of Image.
So I've created a new project from scratch to illustrate (attached). The VI runs OK, but any editing means that this non-existant control is searched for again. Of interest is also that there is a coercion dot where the Image is used, but the data type on the wire seems OK. Creating a control (rather than a Shared Variable) works fine.
Anyone know what's going on here?
Message Edited by GregS on 02-26-2007 03:43 PM
Attachments:
1DImage.png ‏4 KB
1DImageShared.zip ‏15 KB

Hello Greg,
I downloaded your project and opened it up on my
system. I received the same results as you
did – I tried to open the project it searched for \LabVIEW 8.2\resource\objmgr\IMAQ Image.ctl. I also used the 1d Image.ctl file as a constant on my block diagram and it did not
show the coercion dot as you mentioned.
There does seem to be some strange behavior going on here
with the coercion dot and the shared variable.
I will have to look further into it and report this to R&D.
But for now, we need to address your application. What is the goal of your application? How does using a shared variable with IMAQ
Images help you get there? You may be
aware of this already, but when an Image wire is passed around LabVIEW, it is
not actually passing a copy of the data in a dataflow manner. The large size of IMAQ Images necessitates
that LabVIEW pass around a pointer to the IMAQ Image. Therefore, when an array of Image controls is
made and used as a shared variable, the controls do not contain the actual
image data. Instead, they contain
pointers to the IMAQ Images. When they
are passed into a shared variable, unexpected results may occur. If the shared variable is network published,
for example, another computer on the network would receive a pointer to an
image that it would not be able to find or access.
There may be a much better way than shared variables to
achieve the same functionality you are currently looking for. If you do in fact require shared variables,
you could use IMAQ ImageToArray.vi
to create an array that can be used in the shared variable like any other data
type, and then use IMAQ ArrayToImage.vi
on the other end to be able to view the array as an image.
Please post back with more information about your
application and we should be able to find the best solution for you.
Regards,
Luke H

Problems with builded app and shared variables

I got connection error message (Invalid server: cannot connect to server) when selecting a shared variable using dashboard. The app is running on a Win7 PC.
I have no problem connecting the PC's IP at my dashboard indicator, even, I can select the shared vars library of my app.
I opened the ports on Windows and Router TCP: 2343, 59000-60000 UDP: 2343, 6000-6010, and created new inbound rules for the kads.exe, lktsrv.exe and tagsrv.exe programs and installed the Run-Time 2013 engine on that PC. By the way, the application also has HTML files created with the web publishing tools that is working OK.
When I test the application on my develop PC (with LabVIEW 2013) everything works fine.
Did I miss something?

Hello jesushidalgo,
Make sure that there is not a personal firewall enabled on either computer that could be blocking the NI-PSP packets.
Acess http://digital.ni.com/public.nsf/allkb/6E37AC5435E44F9F862570D2005FEF25?OpenDocument and see the solution.
Acess: http://www.ni.com/white-paper/12402/en/ to see how configure software and hardware Firewalls to support National Instruments Products.
Tell me if worked, ok?
Best Regards
Rita Souza
Engenharia de Aplicações
National Instruments Brazil

Use buffering and psp with datasocket-VIs and without any binding and shared variable node

Hello,
I'm using LV 8.5.
I'm trying to develop a multiplatform (windows and mac os x) and multi-computer application. II want to get executables running on each device, communicating through the network. Communication process includes datas (such as images) and events messages (something like "Hello, I got an error" or "youyou, my work is done" or "I'm hereeeee!!!!...."). I do need a communication without any loss of data.
I worked a lot and wanted to test a psp-based design, without any binding nor shared variable node (mac os...) using data socket VIs and SVE buffering.
I managed to :
- deploy shared variable library dynamically (even in an executable)
- communicate between two PCs with datasocket VIs
However, I never managed to enjoy buffering (even locally with one VI doing the deployment and writing datas and another one for reading).
I worked hard (dynamic buffering setting, dynamic buffering watching like in http://zone.ni.com/reference/en-XX/help/371361D-01/lvconcepts/buffering_data/ and in the example "DS send image" and "DS receive image" in the labview examples, trying to use "?sync=true" in the URL, etc...) but no way to get things work.
I attached a jpeg of an example of receiver and sender. I use wait commands in both receiver and sender to test buffering
Receiver do receive datas (the last written) but buffering doesn't work.
Did somebody did that before ? (better than me...)
Thanks
Bo
Attachments:
Sender.JPG ‏87 KB
Receiver.JPG ‏96 KB

Hello,
Indeed my problem has been solved. My error : in the While loop of the receiver VI, I always reactualize the PacketsMaxBuffer and OctetsMawBuffer parameters, what resets the buffer and make it appears ineffective.
I now set the PacketsMaxBuffer and OctetsMawBuffer values only once at the begining of the VI and the psp buffering works perfectly.
Sorry for the desagreement...
Bo

Compact FieldPoint and Shared Variables

Hi Real-Time community,
let me first to describe my problem: I have a project running perfectly on Windows XP machine. The Real-Time Target (compact FieldPoint) is acquiring a data from different sensors and sends them via Shared Variables to the host machine (WinXP). Now this host application has to migrate to Windows 7 machine, which second Ethernet port is also connected to the compact FieldPoint's network. I have created an installer, it run on Win 7 computer but I I see no data there. Shared Variables are standart network-published. What else I need to configure to get Shared Variables visible over there? Thank you in advance for any helpful hint.
Armen

Hi,
we do have the full edition of Signal Express, this is not the problem. We are already logging the information comming from our cFP-1808 : TC-120 and AI-111 module. The problem is that the AI-111 module is a 4 to 20mA module, and we have thermocouple connect to it. We want to read temperature in Signal Express instead of mA.
There's a option in MAX where you can add scaling to a cFP module. This scaling work in MAX, in the OPC server of the cFP, but not in Signal Express. In Signal Express, you still read the mA value.
I know we can add a formula in Signal Express, but we don't want to do that, when there is an other option in MAX.
Thanks

Windows XP vs Windows 7 and shared variables

I have a stand-alone app I install onto 2 different PCs. One PC runs Win XP and the other Win 7. The application must deploy 3 shared variable libraries before the executable can run. On the Win XP PC, I can be a user and accomplish this. On the Win 7 PCI must be sys admin. If I login as a user in the Win 7 PC, I must have the app set to run as sys admin otherwise the user cannot run the app. What has changed?

Faustina,
I do not know of a good way around this. However I did find several links that I think should help. First here is information about what is going on http://digital.ni.com/public.nsf/allkb/E06C1800F5AFCCBF86257236006C9F2A?OpenDocument. Next as a workaround I would suggest setting the exe to run as admin you can find instructions for that here https://technet.microsoft.com/en-us/magazine/ff431742.aspx.

Help with Primary/Subreport and Shared Variables

I've been trying in vain to get this to work.
Main Rpt:
In GH1 I've got shipping address information.
In GH2 I've got a linked subreport where I have shipping addendum information.
Goal...I want to get two fields from subreport to show up in shiping information showing in GH1 on main report.
Sub Rpt:
Addendum information is in GH1
Here is my formula field from the subreport GH1 section:
Whileprintingrecords;
Shared StringVar OpCoSD;
OpCoSD := {tmp_confirm_delivery_vw.operating_company_sd};
Main report:
Here is my formula from the Main rpt GH1 section:
Whileprintingrecords;
Shared StringVar OpCoSD;
OpCoSD;
Nothing shows up in the main report....data showing fine in Subreport.
I've read other posts that seem to say for this to work I have to duplicate my subreport and place it "above" the main report GH1, white it out and shrink it so it won't display, because it must process first before the main report GH1 section.
Many thanks.

Carl,
Yep...after reading more about it on various sources...that's what I tried and it work just as you described.
Thanks so much for your excellent support on this forum.
Regards,
Paul

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?

Creating and loading 4000 shared variables

I need some help laying out the design of this system. The data is coming over reflective memory. I've written a dll and a simple server to do the interface between the reflective memory and shared variable engine. Everything seems to be working. The problem I am having is with scaling the application up to handle approximately 4000 variables. I have a spreadsheet to manage the reflective memory allocation and can use it to import the shared variable definitions with the names from the system that is writing the data.
I am having trouble deciding on the best way to proceed. I would like to read a buffer from reflective memory instead of reading 4000 times. I also would like the server to read in a file that defines the association between the shared variable and reflective memory address. The problem I am having is getting the data out of an array into each of the shared variables. I don't see a way to load the value of a shared variable using the property node (so that I can do this inside a loop). I also can't setup an alias that would access an array element. I don't want to manually create 4000 variables.
Any ideas would be appreciated. Thanks.

I have never had to resort to creating Shared variables programatically so I will leave that for others.
I would cheat.
In LV 7.1 DSC i could import my tag config from a csv file. After importing and saving in LV 7.1 I could let LV create the SV's when the code is updated.
THat all assumes I will only have to do that one.
I have used the interupts fired when SCRAMNet locations update to "steer" the value to appropriate code which could then in turn update the SV using a datasocket write since I can compose the URL for the SV dynamically.
Just sharing ideas,
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Unused shared variables and vi's

I'm cleaning up a 9-month old project. I'm the 3rd developer to work on it and it's become a little disorganized. I want to clean up the file structure and project directory before the next developer steps in to support this project. What is the best way to organize an already existing project and file structure to eliminate any unused vi's and shared variables?
PaulG.
"I enjoy talking to you. Your mind appeals to me. It resembles my own mind except that you happen to be insane." -- George Orwell
Solved!
Go to Solution.

I've gotten the VI's pretty well organized using the save for distribution function. I have some templates and seperate main functions and just wanted to know if I missed anything. I'm really concerned about unused shared variables. They seem to be taking up an awful amount of space in my project and directories.
PaulG.
"I enjoy talking to you. Your mind appeals to me. It resembles my own mind except that you happen to be insane." -- George Orwell

Using TCP or shared variable for data transfer

I am trying to send a large amount of numbers from a real-time module to a host computer. These numbers have been arranged into a large array, such as an array with 10s of thousands of points. The time critical portion of getting the information has already been done, so the data transfer back to the host VI is not time critical. I know I will need to break the large array down into smaller arrays and then reform the large array after all the information has been sent. I know how to use both TCP and shared variables with FIFO. What I am unsure of is which one is better to use for this application. I do not know what the maximum size arrays I can send through either.
Also, from what I have gathered from using LabView is that the sender has to be listening for a connection before the client opens a connection, or else it will throw an error. When I tried breaking it down into 50 points, if i did not wait long enough in the host VI or if I did not put a long enough wait function in the RT loop, and error would throw, so it would take a long time to transfer the data when it worked properly.
Any help or suggestions is appreciated, thanks.

Regarding the array size question, there is no real limit (other then the amount of memory in your system) to the size of data that you can transfer in a single block using either TCP or the Shared Variable. In your case you can easily transfer an array with 10's of thousands of data points in a single write operation. Both TCP and the Shared Variable will automatically handle breaking up the data for the maximum packet size on Ethernet and then reconstitute the array on the receiving end. In LabVIEW you will simply get back the array as a whole without needing to worrying about how the data is broken into smaller packets on the Ethernet.
I tested the attached example which transfers 400kB per block (50000 Doubles) without any problems. You do need to have the Server (in this case RT) running first before the client (Windows) can connect.
Message Edited by Christian L on 02-09-2007 11:34 AM
Christian Loew, CLA
Principal Systems Engineer, National Instruments
Please tip your answer providers with kudos.
Any attached Code is provided As Is. It has not been tested or validated as a product, for use in a deployed application or system,
or for use in hazardous environments. You assume all risks for use of the Code and use of the Code is subject
to the Sample Code License Terms which can be found at: http://ni.com/samplecodelicense
Attachments:
TCP.JPG ‏44 KB

Peculiar behavior of Shared Variable RT FIFO

I'm trying to "leverage" the enhanced TCP/IP and Shared Variable properties of LabView 8.5. My application involves (among other things) doing continuous sampling (16 channels, 1KHz/channel) using 6-year-old PXIs (Pentium III) and streaming data to the host. I developed a small test routine that was more than capable of handling this data rate, even when I had the host put a 20msec wait between attending to the PXI (to simulate other processing on the host). To do this, I enabled the "RT FIFO" property of the Shared Variable (which was an array of 16 I16 integers) and specified a buffer size of 50 (that's 50 arrays). Key to making this work was figuring out the "error codes" associated with the SV RT FIFO, particularly the one that says the FIFO is empty (so don't save the "non-data" that is present).
Flush with success, I started developing a more realistic routine that involves rather more traffic between Host and Remote, including the passing back and forth of "event" data. These include, among other things, "state variables" to enable both host and remote to run state machines that stay "in sync"; in addition, the PXI also acquires digital data (button pushes, etc.) which are other "events" to be sent to the Host and streamed to disk. I developed the dual state-machine model without including the "analog data" machine, just to get the design of the Host/Remote system down and deal with exchanging digital data through other Shared Variables. Along the way, I decided to make these also use an RT FIFO, as I didn't want to "miss" any data. One problem I had noticed when using Shared Variables is the difficulty of telling "is this new?", i.e. is the variable present one that has been already read (and processed) or something that needs processing. I ended up adopting something of a kludge for the events by including an incrementing "event ID" that could be tested to see if it was "new".
Today, I put the two routines together by adding the "generate 16-channels of integer data at 1 KHz and send it to the Host via the Shared Variable" code to my existing Host/Remote state machine. I used exactly the same logic I'd previously employed to monitor the RT FIFO associated with this Shared Variable (basically, the Host reads the SV, then looks at the error code -- a value of -2220 means "Shared Variable FIFO Read Buffer Empty", so the value you just read is an "old" value, so throw it away). Very sad -- my code threw EVERYTHING away! No matter how slowly the Host ran, the indicator always said that the Shared Variable FIFO Read Buffer was empty! This wasn't true -- if I ignored the flag, and saved anyway, I saw reasonable-looking data (I was generating a sinusoid, and I saw numbers going up and down). The trouble was that I read many more points than were actually generated, since I read the same values multiple times!
Looking at the code, the error line coming into the Shared Variable (before it was read) was -2220, and it remained so after it was read. How could this be? One possibility is that my other Shared Variables were mucking up the error line, but I would have thought that the SV Engine handling reading my "analog data" SV would have set the error line appropriately for my variable. On a hunch, I turned of the RT FIFO on the two Event shared variables, and wouldn't you know, this more-or-less fixed it!
But why? What is the point of having a shared variable "attached" to an error line and having it return "Shared Variable FIFO Read Buffer Empty" if it doesn't apply to its own Read Buffer? This seems to me to be a very serious bug that renders this extremely useful feature almost worthless (certainly mega-frustrating). The beauty of the new Shared Variable structure and the new code in Version 8.5 is that it does seem to allow better and faster communication in real-time using TCP/IP, so we can devote the PXI to "real-time" chores (data acquisition, perhaps stimulus generation) and let the PC handle data streaming, displays, controls, etc.
Has anyone been successful in developing a data-streaming application using shared variables between a PXI and and PC, particularly one with multiple real-time streams (such as mine, where I have an analog stream from the PXI at 16 * 1KHz, a digital stream from the PXI at irregular intervalus, but possibly up to 300 Hz, and "control" information going between PC and PXI to keep them in step)? Note that I'm attempting to "modernize" some Version 7 code that (in the absence of a good communication mechanism) is something of a nightmare, with data being kept in PXI memory, written on occasion to the PXI hard drive (!), and then eventually being written up to the PC; in addition, because the data "stayed" on the PXI, we split the signal and ran a second A/D board in the PC just so we could "see" the signal and create a display. How much better to get the PXI to send the data to the PC, which can sock it away and take samples from the data stream to display as they fly by on their way to the hard drive!
But I need to get Shared Variables (or something similar) working more "understandably" first ...
Bob Schor

Bob,
The error lines passed into and out of functions are just just clusters with a status boolean, an error code, and an error string, and are not "attached" to a particular function as you describe in your post. Most functions have an error in input and an error out output, and most functions will simply do nothing except pass through the error cluster if the error in status is True (to verify this for yourself, double click on a function such as a DAQmx Read or Write and look at the block diagram. If there is an error passed in, no read/write occurs). This helps prevent unwanted code from executing when an error does arise in your program. By wiring the error cluster from your other shared variables to your analog data variable, you're essentially telling LabVIEW that these functions are related and that your analog data variable depends requires that the other shared variables are functioning properly. The error wire is a great way to enforce the flow of your program, but you must always consider how it will affect other functions if an error does arise.
Anyways, it's great that you have things more or less working at the moment. Keep us all updated!

Front Panel binding of shared variables very slow initialization / start

Hello @ all,
I am using a server running Windows2000 and LV 8 DSC RTS for datalogging. All shared variables are deployed on that server.
I am now facing the problem, that all front panels running on the clients using the network shared variables on the server take very long to sync on startup. First the flags on the controls bind to the shared variables turn red, after up to ten minutes they start to turn green. The panels use up to 40 controls bind to the shared variables.
All firewalls are turned off. I tried to connect the client to the same switch the server is connected to. Same problem. Does anybody have a clue?
Thx for your quick answers.
Carsten

While I can't offer any solution to your problem, I am having a similar issue running LV8.0 and shared variables on my block diagram (no DSC installed).
When using network published shared variables, it takes anywhere from 30 sec to 4 min from the vi start for any updates to be seen. Given enough time, they will all update normally, however this 4 minute time lag is somewhat troublesome.
I have confirmed the issue to be present when running the shared variable engine on windows and RT platforms, with exactly the same results.
In my case, the worst offenders are a couple of double precision arrays (4 elements each). They will normally exhibit similar "spurty" behavior on startup, and eventually work their way up to continuous and normal update rates. Interestingly enough there are no errors generated by the shared variables on the block diagram.

Modbus and shared variable performanc​e in large applicatio​n

Similar Messages

Maybe you are looking for

Modbus and shared variable performance in large application