Shared variable RT FIFO (multi element) - Read all at once

Hi all!
I'm trying to collect data from analog inputs on my cRIO with a 1 sec time step. For that purpose I use a Timed loop and a shared variable with RT FIFO enabled (multiple array of doubles). Parallel to the timed loop, I also use a while loop that is significantly slower (lets say 10 sec period) that should read all arrays stored in FIFO and write them down in a .txt file (everything is executed locally on RT target). Is there a way to empty the RT FIFO shared variable at once, and if no how can I get a number of arrays that are currently stored in a shared variable?
What is the difference between RT FIFO created by a shared variable and the one created using Real-Time/RT FIFO palette? I prefer using shared variable instead of Real-Time/RT FIFO since it also allows timestamping.
Best regards,
Marko.
Solved!
Go to Solution.

Marko,
We recommend that the non-deterministic loop run faster than your deterministic loop and pull off samples when they become available. If you don't want to do this, you can simply put your RT FIFO read in a For Loop set to execute 10 iterations and then place that in your while loop. For more information on the differences between the RT FIFO and Shared Variables with RT FIFO enabled, please see pages 32-35 of the CompactRIO Developers Guide linked below.
http://www.ni.com/pdf/products/us/fullcriodevguide.pdf
Hope this helps!
Rob B
FlexRIO Product Manager

Similar Messages

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!

Unable to read shared variable in signal express

Dear all,
I am trying to read a shared variable with data type 'Array of Double Waveform' and the signal express gives a network variable error stating
"The data type of specified shared variable xxxxxx is not supported".
could any one explain why is this not supported or suggest a work around.
Munir.
Attachments:
Untitled-1.jpg ‏66 KB

Hi Munir,
the datatype you want to use is not supported in Signal Express. So if you choose this datatype you always get this error massage. As a work around I can recomment you to take the Double Waveform datatype this is supported, create a shared variable for each array element (waveform) and read this variable in Signal Express. This should help you out.
If you got any questions feel free to ask me.
Regards
TomBaum

How to read shared variables inside event structure ?

Hi,
I have a problem that my shared variables do not update inside event structure. The program(s) I am trying to get working is seen in the attached screenshot. It works as follows:
0. I start the vi that is unsquared.
1. I write a string to a shared variable using vi in red square. I make sure that its updated using write-wait-read.
2. I run the other vi (blue square), this changes the boolean shared variable.
The unsquared vi has been running the whole time, it has event structure bind to boolean shared variable change (the one in blue vi). After I have runned the blue vi, the unsquared vi should change the indicator values to match the ones in red vi. However I have to start the blue vi multiple times to get it to change, sometimes even 6 times.
Also, when I change the value in red vi to a third value and start blue vi multiple times, the unsquared vi shows all the variables. I.e. I put "cat" to red then start red, put "mouse" to red then start red,... and then start clicking blue... Unsqured shows cat, mouse,..., dog (dog is the default).
How can I force the shared variable to update inside event sructure. I want the current value of the variable, not some historical values.
Attachments:
Screenshot-5.png ‏108 KB

Found the buffering... disabling it solved the problem... thanks.
FYI, there is another solution that I just found out... attached. Adding timeout to the event structure and the variable read outside the event structure... This makes the shared variable strings (one that is read outside and the otherone that is read inside) different.
Could someone explain why the variables are in different state even if they are used in the same place and looped with 10ms intervals?
Juha
Attachments:
Screenshot-6.png ‏110 KB

VBAI: how do I read a shared variable?

I am trying to make my inspection to do things that are contingent on the value of Shared Variables. It is obvious how to set the Shared variables from VBAI, but I have not figured out how to read them and then create some kind of a CASE structure using that variable.
Any ideas on how to implement such an architecture?
Solved!
Go to Solution.

I would create two different states and use transitions that are based on the shared variable value. You can read the value of variables or previous measurements in steps that allow this (not all steps do, but most do) or transitions. To create a new state, go to the state diagram (click on the "Toggle Main Window View" so the state diagram is in the main part of the window). Right click in an empty part of the state diagram and select "Create New State".
To create a transition, right click on a state and select "Create New Transition" and drag the transition to the new state.
To edit the transition, double click on it and you will be able to select the shared variable as the measurement, along with comparison operations to make the decision. If this comparison evaluates to False, the Default transition will be taken instead.
Select Help>>Show Context Help while editing the state diagram to get more details on how to use it.
Hope this helps,
Brad

Network Datastreams and FIFO Shared Variables

Does someone know why one would use a Network Datastream as opposed to a network published shared variable with FIFO enabled? Seems like they would be identical except that the Shared variable could potentially have multiple listeners.
Thanks,
Craig

Hey Craige
You are correct that a major difference between Network Steams and Network Published Shared Variables with RT FIFO enabled is that the Shared Variable can publish to many computers at once. There are a few other differences that are outlined in the comparison table in this article
http://zone.ni.com/reference/en-XX/help/370622J-01/lvrtbestpractices/rt_gui_bp/
There's another good comparison with some more information in the last paragraph of this article.
http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/networkstreams/
Regards,
Eric L.
Applications Engineer
National Instruments

Multiple use of a shared variable - buffers?

Hi all,
I have an application on a RT target that measured data (around 60 variables stored in a big cluster) in a TCL, sends it via RT-FIFO
(a modified U8-Array buffer that contains the data converted into string and then flattened to U8-Array) to the NTCL which then
writes the data to a file and sends it via TCP/IP to the user interface on a PC.
This is slow. I know that strings should be avoided on RT and especially extensive formatting of variables into strings. I want to
switch over to shared variables now and write files on the PC only.
Problem: I need the data on the RT target as well for control purposes (PID regulation of a cooling system). Can I read the same shared
variable twice, once in the control sub-vi and once on the PC? How does that affect the buffeing of the shared varaible. Does each
"subscriber" gets its own read buffer?
Or should I use a global variable (this will again be a 60 element cluster) on the RT for communication between the read-data-vi, the
control-vi and the send-shared-variable-to-host PC-vi. As I've read, big global variables should be avoided as well on RT-systems.
Or can I use a queue instead of the global variable for the data-cluster?
Cheers,
Olaf

Hey,
Transfering data from a TCL to a NPL (Normal Priority Loop) via RT FIFOs and then via TCP/IP to a Host System has a better performance then a shared variable.
So using shared variables instead of your actual architecture wont result in a better performance. I would suggest to optimize your code.
According to the shared variables behaviour: yes, you can read it at your Host and the RT System at the same time without loosing data when configured as RT FIFO.
Christian

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 Schor

Hey 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.....
David

Hi 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
~~

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.

Custom data type causing trouble in deploying shared variable to RT target

I seem to be having some difficulty in using a network published shared variable created from a custom data type when deployed as an executable on an RT cRIO target. I'll start by describing why I believe this is where the problem lies. I created my RT VI in the LabVIEW development environment (LV 2012) and everything works fine. This VI is pretty simple because it rapidly devolved in to a debug exercise. The RT VI starts by simply blinking the User LED a couple of times and then starts a simple acquisition loop to read a few values off the hardware using the scan engine (while still blinking the User LED). After reading the hardware, the values are bundled in to a cluster and written to a network-published shared variable defined by a type def custom control. The custom control contains five dbl precision floats. If it matters, the cRIO RT system hosts the shared variable in this case.
So, I deploy this under the development environment and everything works fine. The LED blinks merrily along, telling me that the program is running properly. Running a host VI that reads the network-published shared variable yields the desired result. All is good.
Now I want the cRIO system to run this simple program autonomously at startup. I build it, set it as the startup VI, deploy it and then restart the cRIO target. The LED never starts blinking... the VI does not seem to run. I will spare you most of the debugging work and jump to the end. I basically "Diagram Disabled" various sections of code until the VI started running correctly as an executable. I kept reducing the size of the disabled code until only one thing was disabled: the write to the custom data type shared variable.
So, I guess my question is this: Are custom data types defined by type def'd custom controls allowed in executable RT programs? I've read through the cRIO Developers Guide, my NI Real Time Development course book and the Using Shared Variables white paper and I didn't see anything that forbade it. I know that there are some things not allowed in executables that are allowed in the development environment (front panel property nodes, dialog VIs, OS-specific calls, etc), but no mention of custom data type shared variables. Any ideas as to why my VI runs in the development environment but fails when compiled unless I remove the write to the network published shared variable?
Thanks in advance for your help!!
Solved!
Go to Solution.

Paolo,
So I thought that you meant to disconnect them in the build specification. Under the Additional Exclusions in the build specification, there is a check box for Disconnect Type Defs. I checked that box, recompiled, redeployed and it did not work. At this point I had to give and move forward, so I was going to convert the data typed from a cluster to an array. When I went in to change the data type in the shared variable pop-up from the project explorer, there was a big button under the variable definition that "Disconnect from Type Def". Clicked that button, recompiled, redeployed, restarted and everything worked great. Thank You!!
I suspect that I'll have to be careful if I change the definition of that data type (add an element, etc) since it is no longer connected to the data type. We'll cross that bridge when we need to.
Thanks again

Shared Variable programatic access error -1967362038

I am trying to read/write about 300 tags from a AB ControlLogix 5561 processor from Labview 2011 on windows XP SP2 through RSLinx Classic OEM OPC Server.
At first, I tried to do everything through front panel data binding through Datasocket, but I've seen that it becomes slow/unreliable when the bound control count reaches beyond 100 tags or so. Wrong values are read/written, some controls just won't bind intially or lose thier binding...it's really odd. So, I've put all of my faith in Labview's DSC module to solve all of my problems.
I installed it on a development system, played around with the programmatic access VI's using the NI's test OPC server and everything worked great. It really looked like the answer to all of my problems but upon installing it on the target system I can't get it to work the same way!
I've created a library of simply 3 bound variables to the PLC through an IO server pointing at the local instance of RSLinx. I am able to browse the PLC tag structure, so at least the link through RSLinx is working to some extent.
Fairly often, when running the seach variable container vi on that library, I get error -1967362038 with explaination "IAK_SHARED". When this error occurs, the same error shows up in the distributed system manager and the shared variables can no longer be read. I can't seem to pin down a pattern but happens every few minutes or roughly ever 3rd or 4th time I start the vi. When it happens, the only way I've found to get things working again is to undeploy and redeploy the library, while watching it in the distributed system manager, then continually loop the search variable container VI for a few seconds and eventually, the variable comes back to life.
Does this sound like an issue with RSLinx? One of the previous posts related to this error mentioned that it may be due to some corrupt files in MAX?
Other network published shared variables (non-OPC) seem to be OK so I think this is a problem related to the DSC module.
I rebooted twice immediately after the DSC installation.
I have uninstalled SQL Server 2005 and the DSC module and reinstalled both. Twice.
What could be causing this error?
Would it be worth while to port over to the NI OPC Server?

Hi pjrose,
First, I notice that this post is pretty similar to a service request that one of my colleagues has been working on. Are you working with another NI Applications Engineer on this issue?
That said, the issue could very well be related to the DSC module. I doubt that the error is a MAX corruption error, at least at present. One thing that would be worth checking would be the connections on your network. Additionally, what are the types of variables that you are accessing, and how specifically are you coding the access to them? If you could post an example of how you're accessing them, that would be helpful.
Best,
Dan N
Applications Engineer
National Instruments

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

Shared variable / DSC problen

hello out there,
i've got a big problem with labview dsc. i've created library within
an project with several network-bind shared vars (connected to a
symbolic siemens opc server). the problem is that sometimes, when i
use these variables (just drag and drop from the projectexplorer), the
values seemes to be currupted (especially 0). siemens' opc scout say's
there is a value and also NI's shared variable monitor do so.
open to all criticism.
r.p.

Shared variables must be initialized with a known value, and the node must be ran at least once, before predictable behavior can be expected. They don't behave like plain old global variables. The shared variable manager proves this out, as you've seen.
The easiest way to accomplish this is to have each shared variable you'll use in your application's initialize routine, and "read it out" and write to it once before ever using it in the main application.
Message Edited by Broken Arrow on 12-16-2008 09:47 AM
Message Edited by Broken Arrow on 12-16-2008 09:48 AM
Richard

Using shared variables in windows 7 64 bit

Hi !
I am trying to use network published shared variables (with Labview 8.6.1) in windows 7 64 bit. I have three PCs on the network. All PC's are visible to each other. I am able to remotely log on to other PCs.
But when i run my program, the shared variables are not able to read the value over the network. The same program was working with windows XP.
I am not sure whether it is windows issue or labview issue.
Please help ASAP.
Mandar Joshi

I am having the same problem with Shared Variables with LV8.6.1 and Win7 64 in a program that uses a shared variables to share in seperate loops. I was able to use a local variable instead, but would love to know if it possible to use shared variables with 8.6.1 and win7.

Shared variable RT FIFO (multi element) - Read all at once

Similar Messages

Maybe you are looking for