¿perdida datos con shared variable?

Saludos comunidad,
¿ es posible que se genere perdida de datos  cuando se transmiten datos  a traves de una shared variable de forma continua entre dos bucles while que funcionan a distintas velocidades? 
suponer caso en el que  se envian datos de un bucle que  muestrea datos de una tarjeta DAQ a 25 milisegundos, y los recibe otro bucle que funciona a 100 milisegundos, este ultimo  bucle solo se encarga contrastar datos en pantalla.
¡Resuelto!
Ir a solución.

Hola,
          Las Shared Variable pueden manejar un Buffer de tamaño configurable, pero efectivamente si escribes continuamente sin parar y mas rapido de lo que lees, llegará un momento en que ese Buffer se llegará a su máxima capacidad y empezaras a perder datos.
Saludos,
Luis A. Mata C.
Ing. Electrónico
Anaco - Venezuela

Similar Messages

  • Problema di polimorfismo con Read/Write delle Shared variable

    Salve,
    Cercando di modificare l'esempio di progetto "Shared Variable Client/Server" in un progetto dove sono i diversi client a mandare dati al Server ( ovvero l'esatto contrario di quello che fa )
    mi sono inbattuto nel problema illustrato nelle due figure che seguono.
    Ovvero, sostituendo "Writable PSP Variable" ad "Readable" nella scheda "Connect"(FIGURA 1) mi da un errore nella scheda "Read/Write" (FIGURA 2), ovviamente anche qui ho sostituito a "Read Variable" un "Write Variable".
    Mentre utilizzando il Data Socket funziona, ma non mi sono chiari i vantaggi e gli svantaggi nell'utilizzare quest'approccio.
    Qual'è la strada migliore tra Shared Variable e Data Socket per creare un sistema Client/Server così costituito, ovvero con un cospicuo numero di client da servire ( destinato a crescere  )che mandano simultaneamente un discreto quantitativo di dati ( circa quelli di una seriale a 115200bps ) ad un server
    FIGURA 1 
    IMMAGINE 2

    Translation 
    Hi,
    Trying
    to modify the sample project "Shared Variable Client / Server" in a
    project where different clients to send data to the server (ie the
    exact opposite of what it does)
    I untapped in the problem illustrated in the two figures that follow.
    That
    is, replacing "Writable PSP Variable" to "readable" in "Connect"
    (Figure 1) gives me an error in "Read / Write" (FIGURE 2), and of
    course here I replaced "Read Variable" a "Write Variable.
    While using the Data Socket works, but I have clear advantages and disadvantages of using this approach.
    What
    is the best route between Shared Variable and Data Socket to create a
    client / server system so constituted, or with a large number of
    customers to serve (to grow) that simultaneously sends a fair amount of
    data (approximately those of a serial to 115200bps) to a server
    The images points to a gmail location. It is not properly attached.

  • Como incluyo shared variables en instalador

    saludos al foro...
    estoy utilizando shared variables single process para comunicar datos entre dos vis por que no me funcionó con variables globales al hacerlo instalador.
    pero no se como agregar las variables shared single process al instalador, alguien sabe como puedo agregar estas variables al instalador.
    cuando creo las variables se forma un archivo en el proyecto con extencion .lvlib.
    gracias

    Que tal vicbit
    También puedes incluir explicitamente tu librería en tu ejecutable y hacer el deploy de tus variables cuando se corre el ejecutable. De esta manera puedes utilizar tus variables como tu desees en tu programa.
    Te envío un tutorial que es para dispositivos de tiempo real pero que funciona de la misma manera con las single process.
    http://www.ni.com/tutorial/9900/en/
    Saludos

  • View alarm status of shared variable

    Hello:
    I need to know the alarm status (I mean, if the shared variable is currently alarmed) of some shared variables hosted in a Compact Fieldpoint Controller.
    I've seached for options on how to do this (like searching for a property through a property node of the SharedVariableIO class) but haven't found a succesful method to do it.
    Anybody knows how to do that?
    Thanks in advance!
    Robst.
    Robst - CLD
    Using LabVIEW since version 7.0

      Hola Robst, para ver las propiedades de una variable lo que necesitas hacer es habilitar el porperty node para que acepte como entradas las constantes de Variables Compartidas. Para que property node acepte esta referencia como entrada tienes que decirle que en clase es una variable compartida. Para seleccionar la clase da clic derecho sobre el nodo, y ahí aparece en el menu class. Después selecciona Shared Variable. Una vez que tengas la Shared Variable vas a tener todas las propiedades, sin embargo aquí no hay una propiedad que diga si está o no activa la alarma este nodo más bien te permite saber la configuración de la alarma y modificarla.
    Aquí hay tres opciones sencillas para sacar esto. La primera es utiliza solo una variable y conectala al Read Alarms, o Alarm Status a partir de aquí puedes saber si existe o no alarmas.
    Con el de Read Alarms si el arreglo regresa vacio es que no hay alarmas. Con el de alarm Status hay una elemento del Cluster que te indica que si hay alguna alarma.
    Ahora otra opción es utilizar Read Alarms y de ahí extraer cuales son las alarmas.
    Saludos
    Message Edited by BeCeGa on 12-18-2008 05:43 PM
    Benjamin C
    Senior Systems Engineer // CLA // CLED // CTD
    Attachments:
    Alarmas2.PNG ‏21 KB
    Alarms Variables.vi ‏22 KB

  • Diferencia entre RT FIFO shared variable Single element y Multi-element.

    Si en las propiedades de una Shared  Variable, elijo el tipo de dato como Booleano y activo RT-FIFO, Cuál es el tamaño del buffer en la opción Single element? Si elijo Multi-elemet, entiendo que el tamaño lo determino en "Number of Booleans".
    Gracias

    Hola Ainhoa!
    Estuve leyendo un poco respecto a la diferencia entre ambas opciones. Realmente no pude encontrar el tamaño del buffer, por lo que pude entender la diferencia principal es el acceso de más de un lector o escritor a la variable.
    En el caso del single element, solo un elemento permanece en el buffer por lo que si tienes dos lectores, ambos obtendran el mismo valor. Así mismo el tipo single-element FIFO no reporta alertas cuando existe un underflow u overflow en el buffer. En el caso del multi-element, por cada lector o escritor que accese la variable se creará un nuevo buffer independiente y los valores que lean serán así mismo independientes. Finalmente, en LV 8.6 tu puedes definir el tamaño del buffer, dentro de la categoría Networking. Te dejo una liga a un poco más de información que espero te sea de utilidad:
    http://zone.ni.com/devzone/cda/tut/p/id/4679
    Que tengas un excelente día!
    Oswald Branford

  • No me coincide la hora toma de datos con la hora PC

    Hola a todos.
    Tengo una duda y es que no sé porqúe no me coincide la hora con la que la gráfica almacena un dato con la hora en la que el dato es guardado en el PC debería ser cada 0,5s y hay valores que casi son de 0,46s entre dato y dato.
    Adjunto una imagen y el -vi.
    Por cierto ¿porqué no me carga el número de etapa y siempre marca 0?
     Gracias por vuestra ayuda.

    Hola nanoalberto.
    Creo que el problema puede venir por cómo esta el flujo de tu programa.
    LabVIEW sigue el flujo de datos para controlar la ejecución. Es decir, las funciones solo estan restringidas por el órden en el que requieren datos, por lo que la manera en que cableas el VI afecta en que órden se ejecuta. Al agregar variables locales para conectar datos, como esta en tu programa, rompes ese flujo de datos, por lo que puede que la parte derecha de tu código se ejecute antes de la parte izquierda y lea datos un poco anteriores.
    Un buen primer paso es que en todas las variables locales que tienes, las cambies por un cable directo, como pongo a continuación.
    Esta liga te puede ser de interes: http://www.ni.com/white-paper/7517/en/
    Espero esto te sea de utilidad.
    Aldo H
    Ingenieria de Aplicaciones
    Adjuntos:
    1.PNG ‏27 KB
    2.PNG ‏24 KB

  • Shared Variables should support LVOOP as a data type

    Almost all LabVIEW data types can currently be sent through a shared variable without any hassle.  The notable exceptions are native LabVIEW classes, which cannot be selected as the data type for a shared variable.  This causes a problem for anyone who wishes to send objects across a network.  They are forced to rethink their use of LabVIEW classes, use a communication method other than shared variables, or flatten and unflatten the object on either side of the shared variable communication.  The use of classes is growing more common with every version of LabVIEW, so I think it is time for these two prominent LabVIEW features to work together seamlessly.

    There has been some debate (both within NI and with customers) about whether or not the flattening/unflattening solution is actually desirable. After all, if NI made the shared variable support classes, to do the writing to the variable, the object would be flattened to a string and then unflattened when the variable is read. In other words, having the shared variable support classes does not actually remove any work that the program has to do, so having the shared variable do this behind the scenes is just syntactic sugar. The negatives crop up with the issues that Phillip raised -- suddenly the shared varible is reporting a number of errors that it did not support previously, whereas by separating the (un)flattening into a separate node, it is easier to tell where an error is arising -- was it a failure to read a shared variable or was it a failure to unflatten the data therein? By keeping the shared variable ignorant of such complex data types, it is easier to swap out the communication mechanism used -- shared variables might get support for LV classes, but TCP/IP prims might not, or whatever other communication protocol comes along in the future (i.e., the network stream primitives that are brand new in LabVIEW 2010 -- effectively queues that are usable over the network).
    Users may choose to create a custom string format for objects, one that can be unflattened by any system that uses the shared variable -- including CVI and MeasStudio. Having shared variables support classes directly does not get in the way of this, but consideration of exactly what private fields actually need to be exposed in that very global global variable might be encouraged if users are consciously aware of the serialization taking place.
    I'm not pro or con this feature at this point... this post is merely to document debate I've heard about any intermachine communications protocol handling LV classes directly.

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

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

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

  • Performanc​e of Modbus using DSC Shared Variables

       I'm fairly new at using Modbus with LabVIEW.  Out of the roughly dozen tools and API's that can be used, for one project I'm working on I decided to try using Shared Variables aliased to Modbus registers in the project, which is a DSC tool.  It seemed like a clever way to go.  I've used Shared Variables in the past, though, and am aware of some of the issues surrounding them, especially when the number of them begins to increase.  I'll only have about 120 variables, so I don't think it will be too bad, but I'm beginning to be a bit concerned...
       The way I started doing this was to create a new shared variable for every data point.  What I've noticed since then is that there is a mechanism for addressing multiple registers at once using an array of values.  (Unfortunately, even if I wanted to use the array method, I probably couldn't.  The Modbus points I am interfacing to are for a custom device, and the programmer didn't bother using consecutive registers...)  But in any case, I was wondering what the performance issues might be surrounding this API.
        I'm guessing that:
    1) All the caveates of shared variables apply.  These really are shared variables, it's only that DSC taught the SV Engine how to go read them.  Is that right?
       And I'm wondering:
    2) Is there any performance improvement for reading an array of consecutive variables rather than reading each variable individually?
    3) Are there any performance issues above what shared variables normally have, when using Modbus specifically?  (E.g. how often can you read a few hundred Modbus points from the same device?)
    Thanks,
        DaveT
    David Thomson Original Code Consulting
    www.originalcode.com
    National Instruments Alliance Program Member
    Certified LabVIEW Architect
    There are 10 kinds of people: those who understand binary, and those who don't.
    Solved!
    Go to Solution.

    Anna,
        Thanks so much for the reply.  That helps a lot.
        I am still wondering about one thing, though.  According to the documentation, the "A" prefix in a Modbus DSC address means that it will return an array of data, whereas something like the F prefix is for a single precision float.  When I create a channel, I pick the F300001 option, and the address that is returned is a range:  F300001 - F365534.  The range would imply that a series of values will be returned, e.g. an array.  I always just delete the range and enter a single address.  Is that the intention?  Does it return the range just so you know the range of allowed addresses?
       OK, I'm actually wondering two things.  Is there a reason why the DSC addresses start with 1, e.g. F300001, instead of 0, like F300000?  For the old Modbus API from LV7, one of the devices we have that uses that API has a register at 0.  How would that be handled in DSC?
    Thanks,
        Dave
    David Thomson Original Code Consulting
    www.originalcode.com
    National Instruments Alliance Program Member
    Certified LabVIEW Architect
    There are 10 kinds of people: those who understand binary, and those who don't.

  • Issue with use of shared variables in Crystal Reports 2008 Offline Viewer

    Hi,
    I have a report that contains a number of sub-reports which include drill-down functionality. The report returns data relating to an individual team with the user being able to view top level summary information in each area from the parent report and then drill into the sub-reports to view see more detail. The data returned by the sub-reports is filtered, using sub-report links, based on the team code parameter value given by the user. This parameter field resides in the main report.
    One of the values returned by the main report is the team name. This is passed to each sub-report using a shared variable and each sub-report displays this team name as part of a heading.
    This all works fine in Crystal Reports 2008, but when a report, containing data, is opened using Crystal 2008 Offline Viewer there is a problem with the shared variable. The value is displayed correctly when the user initially drills into the sub-report. However, when the user begins to drill into grouped data within the sub-report the value passed to the sub-report using the shared variable disappears. 
    How can I ensure that, when a report is viewed using Crystal Offline Viewer 2008, the value within the shared variable is not lost when users drill into grouped data within sub-reports
    Thanks
    Stuart

    Please re-post if this is still an issue or purchase a case and have a dedicated support engineer work with you directly:
    http://store.businessobjects.com/store/bobjamer/DisplayProductByTypePage&parentCategoryID=&categoryID=11522300?resid=-Z5tUwoHAiwAAA8@NLgAAAAS&rests=1254701640551

  • Why should you explicitly open and close shared variable connections?

    I'm looking into switching over from the old Datasocket API to the new Shared Variable API for programmatic access to shared variables, and I noticed that LV doesn't seem to have any problems executing Shared Variable Reads & Writes without first opening the connection explicitly. That is, I can just drop in a shared varaible Read VI, wire a constant to the refnum input, and it will work. I'm wondering, then, what benefits are offered by explicitly opening the conenction ahead of time...?
    I guess I could see some cases where you want to open all necessary connections in an initialization state of a top-level state machine, particularly if you want to use the "Open & Verify Connection"---so you could jump straight to an error case if any connections fail. But other than that, why else might one want to explicitly open the connections.
    And, along those lines, are there any problems with implicitly opening the connections? One reason why I am hesitant to open them explicitly is because for one of our applications, we need to be able to dynamically switch from one variable to another at runtime. It would be nice to just switch the variable refnum (wired to the input of the Read function), without having to manually close out the old connection and open a new one. A quick prototype of this seems to work. But am I shooting myself in the foot by doing so?
    Thanks in advance.

    I'd expect there's a very small number of people at NI that would know the answer to the detail you're asking for.  But, let's try to extrapolate from this rather old post to see if we can understand what they're forming their impression on.
    The shared variable has to have some sort of reference going on in the background.  It looks like they're calling this a connection.  It's how LabVIEW knows where to find this variable on the network.  We can also see this reference certainly exists if we're opening/closing the reference in the explicit method.  You see the connection as just a string referencing the variable by URL.  This "reference" has to be stored somewhere.  No matter how we're looking at this, we're aware there's a reference of some sort stored. 
    Now, we'd want to look at what would cause this reference to go away.  If you open/close explicitly, it's easy to see it goes away at the close.  If it's implicit, when would it make sense to close it out?  The VI can't be expected to guess where it's done being referenced and close it out.  This puts us into a situation where the soonest it could close is when the VI ends.  From my experience, references tend to be wiped when you close out LabVIEW.  It's this kind of idea that makes the FGV possible.  I wouldn't be surprised by Morgan's claim here.
    If we look at scalability, you're talking about two different topics.  You're talking about adding an extra open, close, read, etc rather than just a few wires.  That certainly would look a mess.  In terms of the dynamic swap that was being discussed, we wouldn't be adding all of those.  The concern would be if enough connections were opened it'd start to behave similar to a memory leak.  This could be something that works with a smaller number of variables.  If you continue to scale, it becomes problematic.  This is why they suggest it's not scalable. 
    To your questions:
    Does LV allocate some kind of session in memory using that string as a lookup?
    It would HAVE to allocate some memory to hold that string.  Otherwise, it'd be pointless to even have the reference. 
    Does it reuse that session if other parts of the application reference the same variable, or does it create a unique session for each referencing call to "Read Variable.vi"?
    I would expect this to be "it depends."  With the implicit method, I would expect it to open a new reference in each point it isn't wired.  This is similar to int x,y = 5;  x and y share the same value but are their own unique memory location.  If you wire the reference to the other points, it should use the same reference.  This would make more sense to me than the program seeking out any other potential usage of the variable in the application to see if there's already a reference open.  I could be wrong, though.
    And what resources does this "connection" actually represent?
    At best, this is just the string.  At worst, it's the string and the TCP socket.  I'd lean towards the first.  Opening and closing sockets should be relatively easy in most applications.  But, it also wouldn't surprise me if it holds the socket.
    I'm sure others have a better understanding than I do.  But, that's what I'd expect for anything you've asked.

  • Is there a way to reset the shared variable engine?

    I would like to be able to reset the SVE in a manner that is equivalent to what occurs during a hardware reset.
    My motivation for doing so is as follows:
    I have an cRIO app with lots of IOV's and NSV's that operate via the SV API and also with plenty of static nodes.  I am finding
    that on first run, from the DE, my CPU%=~55%.  On all subsequent
    runs my CPU%=~65%.  If I do a hardware reset or redeploy one particular
    NSV library then
    my cpu usage will return to ~ 55%.  I have tried isolating the area of code that accounts for this and have found that
    the problem centers around my initialization of one library of NSV's
    where I set its init value via the SV API.  The NSV references
    are all closed after writing without error.  So I am wondering if it
    is possible that the NSV ref's are not actually closing or possibly
    the setting of the inital value has some effect on the SVE so that subsequent runs get bogged down.
    Anybody have any ideas?

    Hello,
    If you redeploy your library, does that bring your CPU usage back down?  perhaps you can use that as a suitable workaround?  How exactly are you setting the initial value of your shared variables?
    Tejinder Gill
    National Instruments
    Applications Engineer
    Visit ni.com/gettingstarted for step-by-step help in setting up your system.

  • Are clusters or individual elements better for shared variables?

    So...  I have some RT code that is being updated, and pulled out of the Stone Ages of LabVIEW.  It was originally written for an old FieldPoint controller operating in "headless" mode, and used the "publish" and datasocket methods for communications and external control.  I had to get clever way back then, and put together a parsing/unparsing system for strings to send sets of data back and forth between the controller and any HMI or other computer attached.
    Now, I'm completely rewriting the code for a cRIO system, and doing my best to leverage all of the strengths of the latest LabVIEW versions.  I have already done an intermediate stage, where I converted from the publish/datasocket method to using network shared variables for my strings, so I could keep some of the original control and calculation logic.  Now, however, I'm going back to the drawing board for most of the program, with only some of the proven logic being held over into the new version.  And, as I'm putting together the data structures I need for both internal control and external communication, I'm in a bit of a quandary...
    I have come upon a data structure dilemma:  should I use individual shared variables for my data, or assemble associated data into clusters?  My original program had a string (essentially a flattened cluster) for each sensor in use (up to 4), one for the system parameters and states, and one for the control parameters and states.  There was a certain advantage to keeping the data compartmentalized like that, it kept things organized and forced me to avoid too many random references of each data point.  And it kept the number of communications channels limited to just a handful.  Mimicking this structure with cluster shared variables would be easy.  But, I'm not sure it's the best or most network-efficient method.
    I know the bundling/unbundling will add some processor time in my code, that is not new to me (it will still be much faster than my old parsing routines).  But, if I have individual data points being thrown around, I can access them easily from things like Data Dashboard (which is great, but far too limited to be able to grab items in clusters and such).  Having all of my data points individually available would make my project messier, but open up easier access.  It would also dramatically increase the number of data points being thrown around on the network at any one moment.  For reference, I would probably have a maximum of 100 data points at one time, made up of a combination of integers, floats, booleans, integer arrays, boolean arrays.  Or I would have a maximum of 8 clusters that would contain those data points.
    Any suggestions on which way I should lean?  Are there any advantages/disadvantages between shared clusters like the ones I need vs. the number of individual shared variables I would need using the alternative methods?  Network traffic and efficiency are always a concern, particularly since this is a "headless" cRIO in a control situation that must maintain a fast scan rate...
    Thanks for any help.  I'm so stuck on this fence, and I can't figure out which side to fall off!
    Solved!
    Go to Solution.

    Thanks Tim, that is a great source that I somehow missed in my hunt for information regarding my dilemna...
    I have to wonder though, does that 25 number also include the I/O points on your cRIO?  Anyone know that particular?  Most of the I/O points are network shared by default during initial configuration, and you could very quickly exceed 25 variables on an 8 slot rack (such as the one I use, a 9074).  Now I'm a bit worried that I'm overusing the variable engine, even before the communications clusters get figured in...

  • Print-time charting with shared variables on a report without groups...

    hello all,
    I have an interesting conundrum; I am working on a report (Crystal XI) with no groups to it, just several subreports. Presently the report is run weekly and sent to the manager of one of our departments.
    The report itself showcases all areas of the department with total tasks, longest outstanding task, average days outstanding, MTD tasks completed, and YTD tasks completed. Due to the variety of tables the data pulls from, I have it set up as subreports that simply display the data.
    All total, there are 20 different shared variables that have been obtained from 10 different subreports. I have the shared variables set as the running totals from the subreports (hence, all are print time). Since the running totals and all the subreports are time based and are not actually linked to ANYTHING on the main report, I am struggling with how to set up the formulas described in the white paper, "Charting on Print Time Formulas".
    The setting up of the two formulas ({@onchngof} and {@showval}) will be different for my situation, as all of the subreports run off of date information relative to when the report is ran. I've got all of the subreports that the shared variables originate in early in the report; but where to from here?
    Would I set up maybe a date grouping or some other non-essential consistent grouping to make it work? The way this report is, it really doesn't need grouping, because the main report is just a display agent for the subreports...
    As always, any help is greatly appreciated!

    Let me ask couple of questions before trying to resolve this.
    1. The chart you are trying to built is placed in which section and is it on Main report or sub-report of its own. This is needed because if you are trying to access shared variables values in Main report, the section should be below the sub-report placed sections.
    2. Try pacing few test formulas in Main report and make sure the correct values are being pulled in on Main report.
    If you are successfully pulling the variable values on the report, try creating a simple chart in report footer with the values you have pulled and see if its taking you somewhere...
    Would need more information on how those variables are being accessed form sub to main or sub to other sub for example are you making an array of those variables and splitting or bringing it in as separate...

  • How do I setup shared variables between executables created in sepparate projects

    Hello,
    I have several sepparate projects with their own respective executable files and I would like to be able for these executable files to all share the same variable (one program controls the value of the variable, while the others read from it).
    I got this setup to work on my personal computer (by being able to access variable manager, etc), but I need to deploy these executables on different computers that don't have the labview development program. What steps do I need to do in order for me to be able to put these executables on any computer (I'm assuming I need to setup a path for the shared variable that is always in the same folder, etc)
    Thanks
    Vlad
    Solved!
    Go to Solution.

    Hi Vlad,
    I think this article may answer some of your questions regarding shared variables in deployed applications.
    http://zone.ni.com/devzone/cda/tut/p/id/9900
    It sounds like you already have your executables built, but this article may answer some questions about deploying them to other machines.
    http://zone.ni.com/devzone/cda/tut/p/id/3303
    Jeff S.
    National Instruments

Maybe you are looking for