Enable shared variable buffer
Dear all,
I'm writing on a program to create shared variables programmatically. I use the examples available in labview and DSC 8.0 as reference. I'm able to create and set the different properties such as scaling, alarms, inital value etc for the shared variable(s). However, when i wire a boolean "true" to " enable buffering", it doesnt seems to work. I checked the shared variable created in the shared variable engine, the variable is created but the buffering cant be enabled programmatically. Can anyone guide me what's the fault? thanks.
Hi,
The VI worked without any problem though I had to change the shared variable name. One thing to note about changing the properties of shared variables programmatically using the shared variable I/O is that it only affects the deployed shared variables and not the actual library file. In essence, these changes are not saved in the library. So the shared variable properties window will not reflect the current status of the "Network.UseBuffering" option. To verify that the "use buffering" is enabled, place another "Network.UseBuffering" property node on the block diagram and read the current state from it.
Attached is a modified version of the VI with the current status of the "Network.UseBuffering" property for the deployed shared variable.
Tunde
Message Edited by Tunde A on 03-05-2007 12:34 PM
Attachments:
Modified_buffering_error.vi 10 KB
Similar Messages
-
Modbus I/O Server Shared Variable Not Updating Immediately After Flush
Hi everyone,
Weird issue here... If I create a Modbus I/O server in a LabVIEW project, bind a shared variable to a holding register, write to the shared variable, flush, and read back, the value returned in an immediate readback is NOT the value I previously wrote. I've attached an example snippet.
In this example, PLC Command Complete is TRUE coming in. I write a FALSE to it. I flush the shared variable buffer. I read back PLC Command Complete. When I do this, PLC Command Complete will return TRUE (???), and after 100ms or so, return FALSE. How is this possible??
Some notes:
The shared variable is NOT network buffered.
The slave is NOT altering the value of this variable; only this snippet of code is.
Altering the refresh rate of the Modbus server does not affect the outcome.
If anyone has any idea as to what's going on, I would greatly appreciate it!Couple of points.
First, your screenshot shows network shared variables, not single process!
Next, network shared variables take time to update (much longer than NI tell you!) If you knock up a little timing noddy to set a variable and then loop reading that variable until the transition comes through you get results like this (runnng from the programming environment, I've not tried with a compiled exe):
Network shared variable, no flush - approx 20ms (NI say is should be 10)
Network shared variable, flush buffer - very fast (faster than the ms clock resolution) but still took between 14 and 20 iterations of my loop before the change percolated through (certainly not what you would expect)
Single Process variable - instant (even without the flush)
This has caused me so many problems in the past (my own race conditions are bad enough without NI throwing in extra ones with this unexpected behaviour) that I try to avoid network shared variables now.
Change yours to single process and you should be fine (or do they need to be NS?) -
In the shared variable properties box, specifically with regard to a the target being an rt target, when enabling aliasing, what is the difference between binding to a project variable vs. to a psp url?
The difference is in the type of variable you are binding it to. A project variable is a variable that lives within the specific project in which it was created. A PSP URL is an address using the Publish-Subscribe Protocol (PSP). You can learn more about PSP URLs here: http://zone.ni.com/reference/en-XX/help/371361G-01/lvconcepts/using_datasocket_technology/#Specifyin...
PSP URLs will enable it to communicate between different machines and also between projects which may or may not be open. The project variable will exist within the project.
Julian R.
Applications Engineer
National Instruments -
Shared Variable Engine Buffering Enable/Disable
Hello -
I am running into a problem where I am seeing a read of data that seems to be lagging the writing of the data. The reading and writing functions are utilizing the same shared variable - a control to write to it and an indictor to display it somewhere else. The indicator is lagging by one value, ie. scrolling up the value from 1,2,3,4.. will yeild in a display of 0,1,2,3, lagging by one. I am writing/reading to/from a value in a PLC using an OPC server, binding the variables to the control/indicator.
I am assuming it is the buffering which is causing this, but I can not seem to find where the buffering is enabled/disabled.
Has anyone seen this behaviour before? Also, where do you configure the Shared Variable Engine to disable buffering?
Thank you in advance for your help -
John
PS> One other note, Datasocket binding of the control/indicator does not yield any problems.John,
Buffering is configured in the main window of the shared variable (double click on the shared variable in the project). Also, you will see this behavior if you have the RT FIFO enabled and you're using the variable on a Real Time target.
I would also recommend taking a look at this white paper which covers the workings of the shared variable:
http://zone.ni.com/devzone/conceptd.nsf/webmain/5b4c3cc1b2ad10ba862570f2007569ef
--Paul Mandeltort
Automotive and Industrial Communications Product Marketing -
Dynamically enabling/disabling opc-binding to shared variables?
Hi.
I've got some shared variables binded to my OPC server, but sometimes some variables need to "ignore" the OPC updates and and be simulated, and in some cases, all of the variables.
So, I've got an application to dynamically change the shared variables properties: Network.UseBinding and Network.URL to "connect to" or "disconnect from" the OPC server, but is there a way to "unbind" the whole library from the OPC quickly and restore it back when need it?
I tried creating and deleting the IO server programatically but the variables go "bad"...
Is this is a good practice or should I change the method?Hi Keptat, you can bind them directly to the OPC sever but you need to add
psp: at the begining.
For example
psp:\\localhost\IOServer\ModbusSlave1.000001
psp:\\aebenjamin\IOServer\OPC1.Channel_0_User_Defined.Ramp.
psp:\\ host \ library\IOservername.register
An easy way to find the complete address y bind a Variable with psp
binding to the OPC server and you will get the path.
In the example code it gets the psp address from a Library, but won't get
you the directions of the registers inside the IOserver, so you need this list
manually.
Another option is create 2 libraries one with the variables binded to the IO
Server and the other binded to the simulated info, in this case you just have
to point to the library, and get the address of all variables.
Also you have to make sure the OPC server is deploy and you can see it
in the Distributed System Manager
Best Regards
Benjamin C
Senior Systems Engineer // CLA // CLED // CTD -
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 SchorBob,
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! -
Shared Variable communication (network publiched )
Hi all ,
The whole day I have been banging my head with Shared variable communication between RT Host and host computer :
I essentially attempted to pass an array from the RT host to the Host computer .For this purpose I used a Network published shared variable of type Array U64 . I utilized this link to help me understand usign shared variable communication
http://www.ni.com/white-paper/4679/en ..
I also enabled RT FIFO .Now in the mentioned link this the information given about using single element FIFO or Multi element FIFO
'' By enabling the real-time FIFO, you can select between two slightly different types of FIFO-enabled variables: the single-element and the multielement buffer. One distinction between these two types of buffers is that the single-element FIFO does not report warnings on overflow or underflow conditions. A second distinction is the value that LabVIEW returns when multiple readers read an empty buffer. Multiple readers of the single-element FIFO receive the same value, and the single-element FIFO returns the same value until a writer writes to that variable again. Multiple readers of an empty multielement FIFO each get the last value that they read from the buffer or the default value for the data type of the variable if they have not read from the variable before.''
I had read the above content a 100 times but still I am not able to get a clear picture of the difference and when to use which option .So I decided to throw away the text and attempted to try somethign out for myself .
I had a loop in the RT host that writes different 3 element arrays into the ''network published shared variable '' . Now when I use the multi element option with '' number of arrays as - 2 '' I am able to read the arrays seperates one by one in the host computer ( as we can read a general queue).
Now when I used the single element option for the RT FIFO with un editable 1 array option ,only the last written array into the ''network published shared variable '' gets read in the host computer .
This sounds absolutely silly as if this is the case then what is the purpose of setting the ''buffer''.For testing purposes I had set the buffer as 5 arrays .
In fact I have only one writer ( writing in loop in the RT Host ) and one reader ( again reading in loop in the Host computer ).So I am not even sure if I require The RT FIFO option for the network published shared variable .
I apologise for the long message but I have reached the limits of running in circles waiting to bang somewhere
I know I am doing a silly mistake somewher or I am probably missing a simple obvious trick but dont know what it is ..
I request for some clarity .. In fact I had posted a little while earlier today as well .... link - http://forums.ni.com/t5/LabVIEW/RT-Host-to-Host-computer-communication/td-p/2348130 )
any help would be appreciated
Cheers
me
Solved!
Go to Solution.Hi,
I think the difference between both types is clearer in the LabVIEW help :
Enabling the Real-Time FIFO
You can enable the real-time FIFO of a shared variable from the Real-Time FIFO page of the Shared Variable Properties dialog box. Place a checkmark in the Enable Real-Time FIFO checkbox to deterministically share data using single element or multi-element FIFOs.
Single Element FIFO
A single-element FIFO shares the most recent data value. The shared variable overwrites the data value when it receives a new data value. Use this option when you need only the most recent value. Configure the size of the array elements or the size of the waveform for the FIFO buffer if you select an array or waveform data type.
Multi-Element FIFO
A multi-element FIFO buffers the values shared by the shared variable. You can configure the size and the elements of the FIFO buffer to match the settings from the Use Buffering section of the Variable page, or you can configure a custom size for the FIFO and the FIFO elements.
Note For both single-element and multi-element FIFOs, if the variable contains array or waveform data, you must configure the size of the FIFO elements equal to the size of the data you want to share. If both the network buffer and the RT FIFO are enabled, the network buffer must be at least as large as one FIFO element. Sharing data smaller or larger than the length you specify causes a memory allocation that affects determinism.
Note Waveforms contain variable-size variant elements that are not compatible with the Real-Time FIFO. Therefore, if you enable the Real-Time FIFO on a shared variable that contains waveform data, the variant element of the waveform data does not transfer.
http://zone.ni.com/reference/en-XX/help/370622K-01/lvrtconcepts/rt_projectvariable/#Single_Element_F...
'Hope it helps
Aurelie -
Shared variable, missing data, the same timestamp for two consecutively data
hello
I have a problem with missing data when I read from a network published shared variable.
Host VI:
In a host VI on my Laptop (HP with WinXP Prof.) i'm writing data to the shared Variable "data". Between two consecutively write operations is a minimum of Milliseconds waiting time. I use that because I want to be sure that the timestamp for each new data value is different then the preview one (resolution shared variables is 1 ms)
Target VI:
the Target VI on a cRIO-9012 realtime device is reading only new data in the way that it compares the timestamp of a new value with the timestamp from the last value.
Problem:
rarely, I'm missing a datapoint (sometimes everything works fine for several hours, transferring thousands of data correctly before suddenly the failure happens). With some workaround I'm able to catch the missing data. I've discovered that the missing data has the exactly same timestamp then the last readed datapoint, therefore is ignored in my "legal" data.
To sum up, the missed value is written to the shared variable in the host, but the target ignores him because his timestamp is wrong, respectively the same as the last value has, despite the host waits every time for a minimum of 10 milliseconds before writing a new value.
Note:
The shared Variable is hosted on the Laptop and configured using buffering.
The example is simplified only to show the principle function, in real I use also a handshaking and I secure that there is no over- and underflow.
Simplified Example:
Question:
Has someone an idea why two consecutively data can have the same timestamp ?
Where is the (wrong) timestamp finally coming from (system?) ?
What would be a possible solution (at the moment with shared Variables) ?
-> I tried a workaround with clusters where each data gets a unique ID. It works but it is slower than comparing timestamps and I could get performance problems.
Would it change something when I host the shared Variable on the RT-System ?
Thanks for your help
Regards
Reto
Solved!
Go to Solution.Hi Reto,
I had a look on your modified Example.
Because the Shared Variables didn`t work like Queues or Notifiers (No Event or Interrupt when a new value has been written. And for sure the´re not possible over a network) you will see the issue, that the code is reading the values more often with the same timestamp (Polling Problematic) if the reader is faster then the writer. And because the timestamp is written with the value you´re able to program like you do. Filter out whats duplicated when you have the same timestamp.
Everything is described in here:
http://zone.ni.com/devzone/cda/tut/p/id/4679#toc1
Laurent talked about a second depth of buffer. Please have also a look at the link. Somewhere in the middle of the tutorial you see the explanations of Buffer and RT-Buffer.
Regarding your question: Would it change something when I host the shared Variable on the RT-System? --> No
In my experiences, you should consider to place the Shared Variable Engine after asking some questions regarding the application.
You will find the Answers to this 3 Questions also in the link:
Does the application require datalogging and supervisory functionality?
Does the computing device have adequate processor and memory resources?
Which system is always online?
And you`re right the smalles time interval you can see in the timestamp is 1ms.!
What you also can do is working with an enabled "timed out". This might be more performance efficient than reading the timestamp.
What I don`t know and not find up to now, is if LabVIEW or the OS adds the timestamp. It´s taken from the system time, this looks like LabVIEW is taking the value and adds it.
I hope this helps
Alex
NI Switzerland -
Our problem is that we currently use a 2D array to store CAN data on a Real-time Target. The array is 20 elements of 3 byte elements as so:
0 1 2
0 [byte] [byte] [byte]
19 [byte] [byte] [byte]
These values are passed between a Deterministic Timed (DT) loop where they are set and a Non-Deterministic Timed (NDT) loop where they are read and passed into a Network Published Shared Variable (NPSV) for communication across the network to a Host PC. I have insrted an image for illustration, pardon the size.
Currently to pass the data between the DT and NDT loop we are using a Global Variable (GV). To improve the system we have attempted to replace these GVs with Single Process Shared Variables (SPSV) with an RT FIFO enabled.
To create the shared variable I simply right clicked the GV of interest and selected create Shared Variable Node form the drop downs. At this point LabVIEW presented me with a 2D NPSV within a new Library hosted on the RT Target. I then selected this new NPSV from the Project, changed it to a SPSV, and enabled a single element FIFO. This variable was initialized with a default value for the size described above and then used in our code for the DT to NDT communication, and conversion to a corresponding NPSV for sending to the Host.
When I went to run the code I noticed that the variable was in fact 2D, however its size was only 2 elements of three bytes each, in other words only two of the row indices were populated and the other appeared as uninitialized. in addition, this data had no resemblance to the set initilazation value. This was also how the variable was presented on the host side of the network after tranfer into a NPSV.
The peculiar part is that If I change this SPSV to a NPSV and then try to change it back, I receive an error saying the type is not supported for SPSV with an RT FIFO enabled. I have to disable the FIFO (which defeats the entire purpose) in order to successfully compile! I am unclear as to what is the bug in this case. Should I not be allowed to create the original 2D SPSV with a single element RT FIFO enabled without receiving an error? Or if this is okay how do I fix the problems associated with the variable after being allowed to create it?
I have found the following discussion in which a user states “The only limitations for custom controls is the ability to use it with RT FIFO enabled on a network-published shared variable”. Is this also true for SPSV? I have not found any documentation explicitely stating this for SPSV, though it is stated for the NPSVs.Martin,
RT FIFOs don't support Multi-Dimensional Arrays, which would corroborate the issues you're seeing. You can break up the 2D array into 1D arrays by reshaping the array, then you'll be able to use the RT FIFO enabled variable, just set the array size to the total number of elements (20*3 = 60).
You can also pass the 2D array via pre-allocated queue, or using a Functional Global. We have a reference example for a circular buffer using Functional Globals here. -
Error codes for shared variables in Labview 8.5?
I am trying to use Shared Variables in Labview 8.5 to enable real-time loops (similar to some of the examples in "Using the LabVIEW Shared Variable", published Aug 28, 2007). I created it to hold the result of a 16-channel A/D converter (so a 16-element I16 array). To avoid losing samples, I used buffering, with a buffer of 5. To test this, I made a pair of VIs, one a producer that stuffs a 16-element I16 array into the shared variable "every so often" (controlled by a timed loop), and a consumer loop that reads the shared variable and does something with the data.
If I think of the buffered shared variable as a Real Time FIFO (as the article suggests it is), I was curious how I would know (a) when the queue was empty, and (b) if the queue had overflowed. Both are necessary if this is to be a practical means of exchanging data -- you want the producer and consumer to run more-or-less at the same rate, but only the producer is deterministic. The consumer needs to be able to run "faster" if it falls behind (for example, because it is writing data to disk), but you don't want it to read data from the shared variable if there's nothing there. [One can always read a shared variable, after all -- as the article states, it simply "holds" the last value written to it].
Snooping around, I discovered that there are "error codes" associated with the shared variable. In particular, a code of -2220 (FFFFF754) seems to signify an empty queue (or a shared variable that has not yet been written to), while a code of -1950678981 (8BBB003B) appears to be "buffer overflow".
Is this documented anywhere? Are there other "error codes" that would be helpful to know? Is there some rationale to these seemingly-random numbers? [It would help to develop code to utilize shared variables if there was a bit less "magic" and "mystery" involved].
For what it is worth, with a buffer of size 40, I could generate 16 I16 values at 1 KHz (simulating sampling from a 16-channel A/D at 1 KHz) and pass it to a consumer node that (a) read from the shared variable until it was empty, then (b) "went to sleep" for 20 msec (simulating "doing something else non-deterministically"), and not miss any data (because I could then empty the Shared Variable RT-FIFO, which should have been half full, before it overflowed on me). Not bad throughput -- I bet I could push it even higher.
Bob SchorHey Bob,
The errors are documented in the LabVIEW help:
Shared Variable Error Codes
Real-Time Shared Variable Error Codes
There are several error messages for buffer underflow/overflow depending on the settings of the network or RT FIFO buffers. In particular the -2220 and -2221 are useful for the producer/consumer use case. For example (as you probably know) the consumer can flush a variable using the error code (see the attached image).
Gerardo
Attachments:
variable1.png 3 KB -
Shared Variables for Real-TIme Robot Control
I'm really stuck in my efforts to use LV real-time in my hardware control application. I have a 6-axis industrial robot arm that I must control programmatically from my PC. To do this I've developed a dynamic link library of functions for various robot control commands that I can call using Code Interface Nodes in LV (using 8.5). This has worked great, that is, until I tried to port parts of the application to a real-time controller. As it turns out, because the robot control dll is linked with and relies so heavily upon several Windows libraries, it is not compatible with use on a RT target, as verified by the the "DLL Checker" application I downloaded from the NI site. When the robot is not actually executing movements, I am constantly reading/writing analog and digital I/O from various sensors, etc.....
This seemed to suggest that I should simply segregate my robot commands from the I/O activities, using my host PC for the former, and my deterministic RT loop on the target machine for the latter. I set up a Robot Controller Server (RCS) vi running on my host PC that is continuously looking for (in a timed loop) a flag (a boolean) to initiate a robot movement command. Because several parameters are used to specify the robot movement, I created a custom control cluster (which includes the boolean variable) that I then used to make a Network Shared Variable that can be updated by either the RT target or the host PC running the RCS. I chose NOT to use buffering, and FIFO is not available with shared variables based on custom controls.
Here's sequence of events I'd like to accomplish:
1) on my host PC I deploy the RCS, which continuously pools a boolean variable in the control cluster that would indicate the robot should move. The shared variable cluster is initialized in the RBS and the timed loop begins.
2) I deploy the RT vi, which should set the boolean flag in the control cluster, then update the shared variable cluster.
3) an instance of the control cluster node in the RCS should update, thereby initiating a sequence of events in a case structure. (this happens on some occassions, but very few)
4) robot movement commands are executed, after which the boolean in the control cluster is set back to its original value.
5) the RT vi (which is polling in a loop) should see this latest change in the boolean as a loop stop condition and continue with the RT vi execution.
With the robot controller running in a timed loop, it occassionally "sees" and responds to a change of value in members of the shared variable cluster, but most times it does not. Furthermore, when the robot controller vi tries to trigger that the movement has completed by changing a boolean in the control cluster, the RT vi never sees it and does not respond.
1) Bad or inappropriate use of network shared variables?
2) a racing issue?
3) slow network?
4) should I buffer the control cluster?
5) a limitation of a custom control?
6) too many readers/writers?
7) should I change some control cluster nodes to relative, rather than absolute?
8) why can't I "compile" my RT vi into an executable?
Any help would be greatly appreciated. Unfortunately, I'm writing this from home and cannot attach vi files or pictures, but would be happy to do so at work tomorrow. I'm counting on the collective genius in the universe of LV users and veterans to save my bacon.....
DavidHi David,
I'm curious why you decided to build a CIN instead of developing the code in
LabVIEW. Is there some functionality that that LabVIEW couldn't
provide? Can you provide some more information about the LabVIEW
Real-Time target you're using? What type of IO are you using?
It is impossible to get LabVIEW Real-Time performance on a desktop PC running
an OS other than LabVIEW Real-Time. Even running a timed loop in LabVIEW
for Windows won't guarantee a jitter free application. Also, no TCP based
network communication can be deterministic. This means Network Shared
Variables are also not deterministic (they use a TCP for data transport) and I
advise against using them as a means to send time critical control data between
a Windows host and a LabVIEW Real-Time application.
In general, I would architect most LabVIEW-based control applications as
follows:
- Write all control logic and IO operations in LabVIEW Real-Time. The
LabVIEW Real-Time application would accept set points and/or commands from the
'host' (desktop PC). The Real-Time controller should be capable of
running independently or automatically shutting down safely if communication to
the PC is lost.
- Write a front-end user interface in LabVIEW that runs on the desktop
PC. Use Shared Variables with the RT-FIFO option enabled to send new set
points and/or commands to the LabVIEW Real-Time target.
Shared variable buffering and RT-FIFOs can be a little confusing. Granted
not all control applications are the same, but I generally recommend against
using buffering in control applications and in LabVIEW Real-Time applications
recommend using the RT-FIFO option. Here's why: Imagine you have a
Real-Time application with two timed loops. Time-loop 'A' calculates the
time critical control parameters that get written to hardware output in
timed-loop 'B'. Loop 'A' writes the outputs to a RT-FIFO enabled variable
with a RT-FIFO length of 50. Loop 'B' reads the outputs from the shared
variable, but for some reason, if loop 'B' gets behind then the shared variable
RT-FIFO will now contain several extra elements. Unless loop 'b' runs
extra fast to empty the RT-FIFO, loop 'B' will now start outputting values that
it should have output on previous cycles. The actual desired behavior is
that loop 'B' should output the most recent control settings, which means you
should turn off buffering and set the RT-FIFO length to 1.
There is also a clear distinction between buffering and the RT-FIFO
option. The RT-FIFO option is used to add a non-blocking layer between
network communication and time-critical code in LabVIEW Real-Time
applications. It also provides a safe mechanism to share data between two
loops running in a Real-Time application without introducing unnecessary
jitter. Network buffering is a feature that allows a client to receive
data change updates from the server even if the client is reading the variable
slower than the server is writing to it. In the example I presented above
you don't need to enable networking because the shared variable is used
entirely within the Real-Time application. However, it would be
appropriate to send control set points from a Windows PC to the Real-Time
application using network published shared variables with the RT-FIFO option
enabled. If it is critical that the Real-Time application executed all
commands in the sequence they were sent then you could enable an appropriate
buffer. If the control application only needs the latest set point
setting from the Windows host then you can safely disable network buffering
(but you should still enable the RT-FIFO option with a length of 1 element.)
Network buffering is especially good if the writer is 'bursty' and the reading
rate is relatively constant. In the robot application I can imagine buffering
would be useful if you wanted to send a sequence of timed movements to the
Real-Time controller using a cluster of timestamp and set point. In this
case, you may write the sequence values to the variable very quickly, but the
Real-Time controller would read the set points out as it proceeded through the movements.
The following document presents a good overview of shared variable
options: http://zone.ni.com/devzone/cda/tut/p/id/4679
-Nick
LabVIEW R&D
~~ -
Hello,
I have a couple of questions about properties of Shared Variables (SV). They can be configured either by using the dialog box (right-click on SV -> Properties), or programmatically via the "SharedVariableIO" property node. Have a look at the NI-Examples to see how SV can be created programmatically by using the DSC module.
1) The dialog box offers a property "Variable Type" which can be "Network-published", "Single-Process" or "Time-Triggered". The "SharedVariableIO" property node gives no access to this property. Does anybody know why? The same question can be rephrased: How can I create a "Single-Process" SV programmatically?
2) The "SharedVariableIO" property node has two items, "Network.OnScan" and "Network.ConnectionType", which have no direct correspondance to any of the properties available in the dialog box. What is the exact meaning of those properties? The on-line help isn't of much use here...
3) Mutliple SV can be edited by using the Multiple Variable Editor (Tools->Shared Varaible->Multiple Variable Editor). A cool feature is the import/export of CSV-files. I am interested in programmatically creating SVs from the information stored in such a CSV-file. Reading the file is no problem, but connecting the file entries to the properties of the "SharedVariableIO" property node would be quite some job. In principle NI has already solved that within the Multiple Variable Editor. I guess there is a bunch of VIs somewhere below "....Program Files/NI/.../vi.lib that do exactly this thing. Does anybody know, if these (which ones?) are available for public use?
Regards,
Dietrichdietrich wrote:
1) The dialog box offers a property "Variable Type" which can be "Network-published", "Single-Process" or "Time-Triggered". The "SharedVariableIO" property node gives no access to this property. Does anybody know why? The same question can be rephrased: How can I create a "Single-Process" SV programmatically?
You can't. The single-process shared variable is an old style LabVIEW global placed under the shared variable abstraction. There is currently no way to create those on the fly. Time-triggered also cannot be created programmatically. I confess I don't know enough about them to know the reason why.
dietrich wrote:
2) The "SharedVariableIO" property node has two items, "Network.OnScan" and "Network.ConnectionType", which have no direct correspondance to any of the properties available in the dialog box. What is the exact meaning of those properties? The on-line help isn't of much use here...
Network.On Scan = read/write hardware? - this allows you to programmatically control when you are reading from or writing to configured hardware.
Network.ConnectionType = connect to hardware even when no one is viewing me? - this has 2 choices, UpFront & OnDemand, UpFront means that the variable will be connected to hardware even when no one is connected to the variable. This is useful when you want to reserve hardware or when logging is enabled. OnDemand means that you disconnect from hardware whenever no one is reading the variable.
dietrich wrote:
3) Mutliple SV can be edited by using the Multiple Variable Editor (Tools->Shared Varaible->Multiple Variable Editor). A cool feature is the import/export of CSV-files. I am interested in programmatically creating SVs from the information stored in such a CSV-file. Reading the file is no problem, but connecting the file entries to the properties of the "SharedVariableIO" property node would be quite some job. In principle NI has already solved that within the Multiple Variable Editor. I guess there is a bunch of VIs somewhere below "....Program Files/NI/.../vi.lib that do exactly this thing. Does anybody know, if these (which ones?) are available for public use?
I would advise against using any of these. National Instruments can change, or remove, those underlying files at any time as a result of modifications to the MVE. That could cause issues for any code using those sub-VIs.
Regards,
Robert -
DSC Saving Shared Variables to Library
I'm guessing this is a bug (LV/DSC 2009 SP1), but I wanted to see if anyone else had experienced this or had a workaround.
I'd like to make changes to the logging state of some shared variables programmatically and be able to save the changes. When I use the SharedVariablestoLib.vi function on a simple test library it works. However when I use it on my actual library I get the following (testing vi I'm using is Untitled 2):
Error Code 1
Invoke Node in PRC_SVsToLib.vi->PRC_DumpSharedVariables.vi->NI_DSC.lvlibharedVariablesToLib.vi->Untitled 2
Possible reason(s):
LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488: Command requires GPIB Controller to be Controller-In-Charge.
I think the culprit is that my library has variables organized into virtual folders. Any thoughts?
Thanks,
Kyle
CLD using LV, DSC 8.5-2009, RT 8.5
Ghoti!I can pretty well cause the problem with virtual folders. I have attached the vi I'm using to change the logging state and save the changes as well as the two libraries I used for testing purposes.
What I did to test:
-Disabled logging on both variables in both libraries.
-Saved, undeployed, and redeployed both libraries.
-Ran my log enabling vi on each library. It ran on Test 2 (no folders) fine. On Test 3 (includes a folder) it threw the same error as above.
-At this point I tested and both libraries were logging both variables.
-Looking at the variable properties in the project, both Test 2 variables showed Enable Logging checked. Neither Test 3 variable did.
-Exited the project. Test 3 had unsaved changes so I saved it.
-Re-opened the project and examined the variables, both Test 2 variables showed Enable Logging as before. In Test3 the root variable showed Enable Logging but the variable in the folder did not.
-Undeployed and redeployed both libraries.
-Confirmed that both Test 2 variables and only the root Test 3 variable were logging.
CLD using LV, DSC 8.5-2009, RT 8.5
Ghoti!
Attachments:
Programmatic Log Change.vi 17 KB
Test 2 Library.lvlib 5 KB
Test 3 Library.lvlib 4 KB -
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? -
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.comIf 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.
Maybe you are looking for
-
Good morning I am confronting serious problems with my Macbook pro 2013, that is runing to slow, even when I am writing this email is running with some kind of delay. I upgraded the memories to 8gb but still running slow . Please let me know what I
-
Issue with past purchase of Adobe Lightroom
I purchased Adobe Lightroom 4 on 10/31/12 from the Apple Mac App Store. I have been using the software alongside Adobe Photoshop CS6 for the past two years. My MacBook needs to be set back to its original factory settings and I wasn't sure how to g
-
Hi , I have the following scenario : There is a region A which raises a contextual event. There is a page (say Test.jsff) containing region A and region B both of which can be invoked as popups . Region B also contains Region A. Both Test.jsff and Re
-
Dynamically hide/display multiple report regions.
Hi, I need to build a dashboard like homepage for users with multiple report regions. Users should be able to pick the regions they want and the display point for those regions. Is this possible? Thanks in advance
-
Content library not showing in iMovie 10.0
Content Library not showing. No answer found. It is NOT at the top as some say. Where did it go and where is it? What's the best alternative to this stupid iMovie program. So frustrating. It was working a month ago.