Shared Variable Timestamp fixed on TPC-2012

My code running on a TPC-2012 reads from a shared variable that is hosted on a CRio.  Reading the timestamp of the shared variable gives me the same 5AM time in 1903.
If I read that same shared variable using software running on a PC vs the TPC, I get a timestamp that corresponds to the correct time on the CRio. Therefore, the CRio is publishing and updating the variable as required.
What is up with the TPC?  I am guessing that reading the timestamp is not supported on the TPC?  Yes/No?
Solved!
Go to Solution.

Hi dbtestcon,
This was reported to R&D (#162395) for further investigation.  Thank you for posting your workaround. 
Jennifer R.
National Instruments
Applications Engineer

Similar Messages

  • CFP-1808 shared variables timestamp

    Hi,
    I need to control and acquire data from a cFP Ethernet module (cFP-1808) to a PXI RT system. I have tested two ways of doing it:
    1. Bind shared variables to the Fieldpoint channels. Works great except for the fact that I have to record the timestamp of every single channel in all Fieldpoint modules. I have to avoid this. The reason I have to record all timestamps is that sometimes two consecutive reads are the same in value and in timestamp; so even if I make sure I get a value every 100ms in my real time application I cannot trust  that  the shared variable engine will give a real new value every 100ms, because sometimes one read is the same as the previous one. My
    understanding of the technology is that the cFP network interface checks for an
    updated value of the channels of each module at the Advise Rate. If there’s a
    new value the cFP transmits it to the Shared Variable Engine running in the PXI
    controller, but if the value has not changed it doesn’t transmit anything, so
    more efficiency is achieved in the network communication. This would explain the
    timestamp behavior of the shared variables bound directly to Fieldpoint
    channels; since there is no new value the shared variable is not updated so the
    timestamp of two consecutive reads is the same.
    2.  Create a Modbus server and then create shared variables bound to the Modbus server channels. With this method any time my RT application asks for a new value the shared variable engine provides a real new value with an updated timestamp, and all timestamps in the same module are equivalent (in 1usec range).  Therefore, it looks like using the Modbus solution I  only have to record one timestamp per module.
    So option 2 probably fixes my problem, but I'd like to understand why. Both methods use the shared variable engine, shouldn't they behave the same way? There's one downside in option 2, which is having to deal with Modbus addresses and not having the ease of use of option 1 that just browses to find the Fieldpoint channel.
    Any comments?
    A final note, it'd be great to be able to use the Fieldpoint VIs in LV Real-Time! Can this be achieved?
    Raimon

    Hi Raimon,
    How are you binding to your shared variables?  This KB reviews three methods:
    http://digital.ni.com/public.nsf/allkb/FA610367EC62574186257118005089F2?OpenDocument
    I don't believe using FieldPoint VIs on a PXI RT target is possible because FieldPoint is not a driver that you are able to install on the PXI RT target.  We do have the cFP-2xxx line of RT controllers for FieldPoint, which can communicate directly to the FieldPoint modules, ensuring determinism.
    Trey B
    Applications Engineering
    National Instruments

  • Support for Shared Variables in Third Party XP embedded based TPC's?

    I have deployed an application in an XP embedded based Touch Panel (Third party). The application is working fine, but the shared variables hosted on an RT (sbRIO Board) are not getting updated in the application on TPC
    1. The TPC is part of the project as Windows XP Embedded Touch Panel
    2. NI TPC Service has been installed on the TPC and the application can be deployed remotely from the development PC through ethernet. (Hence network connections and communications are OK)
    3. By using Distributed Systems Manager in the development computer, I can see that the shared variables are getting updated on the network
    I believe that the problem can be solved if the following programs are installed on the TPC
    A. Support for shared variables for XPembedded
    B. Shared Variable engine
    I have tried installing support for shared variables from Program Files > National Instruments > Labview 8.6 > PDA > Utilities > Variables > x86 - but am getting an installation error "Unable to find application manager for Pocket PC applications".
    Shared variable engine has been installed from ve220 folder. The program is getting installed. But the Variable Engine is not started Control Panel > Administrative tools > Services in Xpe, the service is stopped and cannot be started. When I try to start the service, I am getting the following error on TPC
    "Could not start the National Instruments Variable Engine Service on the local computer.
    Error 1053. The service did not respond to the start or control request in a timely fashion."
    Please suggest solutions for the above or alternate locations for the following:
    1. Support for shared variables for XP embedded TPC's
    2. Shared Variable engine installer program.
    Thanks
    Krish
    Solved!
    Go to Solution.

    Problem solved!
    Update for interested folks working on XP Embedded TPC's
    Just to make sure that Shared Variables were indeed accessible to the TPC, I wanted to install Distributed Systems Manager 8.6 on the TPC. However since the TPC was having only 1 GB of DOM (Disk on Memory) and with all the software I had tried, there were only a few Megabytes left on the system. I had to add another DOM of 2 GB.
    All the products of the Installation went fine, with the exception of NI Logos (Version 5.0). NI Logos installation failed repeatedly.  I tried installing NI Logos separately, with the same results. Then I had this gut feeling that NI Logos had something to do with the issue.
    I then downloaded the new version of NI DSM 2009 SP1. Although this was supposed to get installed on any fresh system without Labview, the installation would not proceed beyond the setup stage. I tried installing NI Logos from the products folder on the new download separately and it worked like magic!
    Once the new Logos (Ver 5.5) got installed, the Shared Variable Engine started automatically and the Shared Variables were finally unleashed - free to rise and shine! Thank God Almighty!!
    On the lighter side, come to think of it - for running an application of around 400KB, we need XP embedded, NI Run Time, Logos, DSM ..........  (all around 900MB). Can we make it any simpler?!!  Inviting your comments .......
    Thanks
    Krish

  • Is it necessary to use semaphores with shared variables

    is it ok to use semaphores with shared variables to prevent race conditions or is that built into the shared variable?
    - James
    Using LV 2012 on Windows 7 64 bit

    Semaphores are more of a method to protect a section of code from executing, and as tst as said they won't really help you.  There is nothing inherently harmful about having 2 sections of code trying to write to a shared variable at the same time.  Nothing like a crashed program, scrambled value, or an error message.  What will happen is that whatever happens 2nd is the value that sticks.  So a shared variable can still have the possiblility of race conditions just like local and global variables if you are dealing with multiple writers.  That is really an architecture problem.

  • TPC 2012 - Problems with shared variable

    Hi,
    I tried to program simmilar thing to this one http://zone.ni.com/devzone/cda/tut/p/id/5548 on TPC 2012. But it doesn't work.I can see that both programs on my laptop and TPC are working(I've added an additional counter with display), but I cannot see any effect on TPC when I change the value of shared variable on my laptop. I use LabView 8.6 with Touch Panel Module. My question is what are the exact steps to run such application on TPC2012? Are they the same as for TPC 2006?
    I've noticed following issues:
    1.I cannot deploy the program from Project Manager(there is an information that maybe TPC Service is not started. - I've found such information about TPC Service http://digital.ni.com/public.nsf/allkb/DE177828D27A14A48625734E00768B66 but in fact I cannot find Start » All Programs»National Instruments » NI TPC Service » NI TPC Service Manager 1.0 Does it mean, that the TPC Service is not installed and the programm with shared varibles won't be working or can I start it somehow in another way? Do I need to have TPC service installed on TPC2012?
    Until now, I've built the project and sent it through FTP to TPC(the folder was /TEMP) and then started it.
    2.Ping works OK
    Thank you in advance for any hints how to solve this problem.
    Martin

    Well no problem, but I'm frustrated with this issue... I've tested many things and nothing. Just to help someone else as I in the future, these are my sources:
    http://forums.ni.com/t5/LabVIEW/TPC-2012-Problems-with-shared-variable/m-p/1009631/highlight/false#M...
    http://digital.ni.com/public.nsf/allkb/28536DE7E2D9E98B8625770B00738920?OpenDocument
    http://zone.ni.com/reference/en-XX/help/372507B-01/lvtpcgsm/tpc_install_sharvar/
    http://zone.ni.com/reference/en-XX/help/372507C-01/lvtpcgsm/tpc_install_sharvar/
    http://digital.ni.com/public.nsf/allkb/23532363F4905EC28625727A00730B80?OpenDocument
    http://forums.ni.com/t5/FieldPoint-Family/TPC-2006-Not-Listed-in-Targets-and-Devices/td-p/566325
    http://forums.ni.com/t5/LabVIEW/MAX-can-t-detect-TPC-2106T/td-p/831524
    http://zone.ni.com/devzone/cda/tut/p/id/5868
    http://digital.ni.com/public.nsf/websearch/28B748B9697B79E18625725A00009066?OpenDocument
    http://digital.ni.com/public.nsf/websearch/D1726990DCEB82E4862570F20069C57D?OpenDocument
    http://digital.ni.com/public.nsf/allkb/3B469103BBDD4CE48625726000665B36
    I hope find some hint..
    Fabian León
    Certified LabVIEW Associate Developer

  • LABVIEW 2012 - shared variable error during programming of NI CRIO 9023 and TPC 2212

    HELLO,
    i am using CRIO 9023 with TPC 2212 and LV 2012. I want to develop a stand alone app which has a front panel on TPC. at first i am building a simple app with two controls variables, one is a sliding bar on TPC Vi and the other one is the while loop  variable "i" on CRIO VI. i used  shared variables.
    first i creat shared variable on CRIO side and access this on TPC Vi. I COMPILE both Vi,s and they are working fine. But when i created the slide bar control in TPC VI, compiled and deploy the TPC Vi, it get deployed in TPC. But when i  start compiling the CRIO VI an error mesage occured as follows;
    I have tried every option to best of my understanding like formating crio then installing all softwares including Network variable engine etc. i also go in properties of the executable file of TPC Vi and go in properties-shared variable- then check the "deploy variable in application" option . below is image displayed.
    I am in despirate need for solving this problem as i have to develop the final app for testing soon. can some one help me regrarding this.
    REGARDS

    I would not recommend using shared variable engine.  It is supposed to make things easier, but in fact, you will spend more time troubleshooting why it is not working than you will actually coding an alternative solution.
    Try the Simple TCP Messaging instead.
    http://zone.ni.com/devzone/cda/epd/p/id/2739
    Machine Vision, Robotics, Embedded Systems, Surveillance
    www.movimed.com - Custom Imaging Solutions

  • Shared variable, missing data, the same timestamp for two consecutiv​ely 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

  • Why can't I show timestamp on a shared variable?

    I have two shared variables in a block diagram. They are in two different lvlibs, but both hosted on the same RT target.
    One of them allows me to show the Timestamp.
    The other does not.
    Why? Is this just a bug in LV 8.2?

    OK, I figured out the answer...
    Because on the second variable, I selected "Shared Variable" from the palette, then did "Select Variable..." to get the variable I wanted.
    If I had dragged and dropped the variable from the project window, then it woud have allowed me to show the timestamp.
    8.2 Bug.

  • Shared Variable Engine clock is consistently inconsistent

    From the annals of the weird:
    I noticed a while back that the DSM displays a different time than my system clock when I manually change a NSV value. I didn't think much of this, but then I noticed that it is not just wrong but inconsistently wrong. Here's the time difference, in seconds, between the system clock and the SVE timestamp for a dozen NSV value changes [the SVE clock always lags behind]:
    35, 14, 1, 18, 29, 2, 21, 24, 14, 17, 29, 20
    I checked these numbers in two different ways: (1) with the "Time stamp" event property node with NSV events using the DSC module and (2) manually changing values with the DSM and comparing to the displayed Windows time.
    What's the deal? The timestamp is completely useless to me with a seemingly random offset from the system time; it's by far the best way to deal with this little bit of unfortunate SV event handling behavior. Filtering event timestamps against system time is fairly standard procedure and I can't see it being useful with this going on.
    This should be trivial to reproduce--does anybody else see this? If so, is there an explaination--or better, a fix?
    [I should note that I have seen this but I'm running Intel core 2 duo, not an AMD multicore. I'm using LV and DSC 2010 SP1]

    You may have to set up the Time Synchronization Services on the computer with the DSM running. 
    In LabVIEW Help, look for Shared Variable Engine Page (Options Dialog Box)
    In DSM Help, look for Shared Variable Engine Time Server Configuration Box
    I don't know if both are necessary but I made all the computers on my system point at the same time server. The time server is configured as an Authoritative Time Server under Windows. It is in turn slaved to our DSN server which follows a Public NTP server. 
    JohnCS 

  • Shared Variable Crashing LabVIEW

    This is just one of those projects that has a brick wall at every turn so far. Two computers running LV2009. Computer A hosts Data Write Shared Variable. Computer B hosts Data Read Shared Variable. Data Read is bound to Data Write. Everything was working fine, and then late yesterday afternoon, I don't think I had changed anything on the shared variable, I start up my VI on Computer B, and LV crashes. The VI starts to run until the first execution of Data Read, and then poof, everything open in LV dissapears. The problem is one hundred percent repeatable since then.
    Here is what I know:
    1. An error indicator hooked to Data Read shows -1950679034 (Shared Variable has no value) for about a second before the crash. Everything stops executing as soon as the warning appears.
    2. The Data Write is single writer, but it is also occasionally read in the VI that it is written in. It is not being read when the crash happens. I can however perform the read on Computer A without incident.
    3. Not sure if this is related, but if I open the VI on Computer B, and then open the project, I am not able to drag Data Read from the project onto the block diagram. I also cannot perfrom any operations on the Shared Variable (like right click, ignore timestamp). I have to close the VI and reopen it from the project. Thinking back, this problem may have started when I opened the VI without opening the project.
    I am torn between abandoning Shared Variables and trying to figure this out. I would definetely prefer to use the Shared Variable, especially because I need some buffering. I'm guessing I can buffer things some other way. Not sure if I can remotely access a queue, or ... ?
    Solved!
    Go to Solution.

    I looked at STM, but I think the Data Socket VI's may be a better fit for me. It seems like Data Socket and shared variables are sort of intertwined, but I'm hoping DS doesn't suck as much as the SV seems to so far.
    I think NIC means network interface card? Anyway, I don't really know how many I have. The Data Writer is on a PXI8108 with Windows, the reader is an old crappy Dell that I inherited with the desk.
    I'm also not sure about the logos.ini file you referred to.
    My intention is to transmit an array of double waveform that is about 15 - 20 channels acquired at 100 - 1000 Hz. I think the Data Socket looks like the simplest way to do this, and I could live with 100 Hz if speed is a problem, but I sort of don't think it will be. I'll try tomorrow unless somebody has a better suggestion.
    By the way, I saw in another post a similar problem with Shared Variables that is supposedly fixed with the new patch for 2009, but I'm not sure I trust SV's because this will, for about thirty seconds of its lifetime, be one of the most critcal applications I've written, so I want confidence that it will work for those thirty seconds.

  • Programati​c Access to network published shared variable - Knowlege Nugget

    Wanted to Share a coding problem I have just resolved:
    I have been trying to debug the code above.
    It worked for one device and not the other (Identical devices: DevA,DevB)
    It has been throwing an error, unable to access variable.
    I resolved the problem by changing by changing the timeout to something > zero
    Hope this helps future travellers
    This seems onlt yo be a problem during the first connection to the variable,
    Subsequent reads don't seem to need it.
    It is almost as though it needs time to troll through the project shared variable database to finde the reference the first time through.
    iTm - Senior Systems Engineer
    uses: LABVIEW 2012 SP1 x86 on Windows 7 x64. cFP, cRIO, PXI-RT

    Ben wrote:
    Since I don't use shared varibales I have to ask...
    Is there a timestamp returned that reveals the state of the variable?
    Ben
    The timestamp is only available on the reads.  It returns the timestamp of when the variable was written to.
    One more thing to watch out for (we recently got bit by this).  The NPSV is actually written to a buffer (8kB?).  The variable is published either when the buffer is filled or 10ms has passed.  There is a command to flush the buffer to avoid this 10ms delay.
    There are only two ways to tell somebody thanks: Kudos and Marked Solutions
    Unofficial Forum Rules and Guidelines

  • Correct Shared Variable behavior

    I have a program, written in version 8.5, that has a shared variable used in an number of locations to shut down the program's major loops when the test system is being "shut down". I used a SV specifically to use its error in/out to force the execution order in these various loops. In 8.5 it has worked correctly, but yesterday I was helping my customer commision a new test system, using this program, and they only have 8.6, so we decided to migrate it all to this version. While still debugging the test system hardware we got an error which caused me to attempt to terminate the program. At this point I noticed that all but one loop had terminated correctly, and when I probbed the no terminating loop I discovered that it had had a hardware error, putting an error on the loop's error cluster. This caused the boolean Shared Variable to output a F rather than the T that had been written to it when I attempted the shutdown. This wasn't the behavior I remembered in my 8.5 version, so I created a quick little test, two parallel loops, one with the boolean SV in  the write mode with a control to toggle it F/T the other loop having the SV in the read mode, with its output set to stop the loop if T. I had an error cluster shift register in the second loop, with the SV's error in/out connected to it that had a control to introduce an error in the error cluster. On the system running 8.5 writing a T to the SV stops the loop regardless of the error cluster state, but on 8.6 it does not, with the SV returning a F if there is an error present.
    Has this been seen by others? Which is the correct behavior?    I ended up doing a really quick change, making a "real global" and putting it into a case statement within a VI so that I could retain the ability to have the error in/out chain. I should have used a functional global, which is my normal mode rather than a "real global" but was tired and had just had an educational discussion with my customer about SV vs Globals and for the few minutes it took was in the "global mindset".  I think it might be the first global I've used in a couple of years or more, I just was so flabbergasted about finding the apparent change in behavior.
    Putnam
    Certified LabVIEW Developer
    Senior Test Engineer
    Currently using LV 6.1-LabVIEW 2012, RT8.5
    LabVIEW Champion

    IMHO if a function's behavior hasn't been specifically defined for 3 major release cycles, and it performs one way, it shouldn't be changed, regardless of some philosophical "standard". Pre-8.6 it behaved by passing the error through, but still performing its own task, output the value written to it elsewhere, so why would someone think that making this behavior change to "if an error is present output the default" would not have major implications? We don't all have the luxury of rewriting our projects from scratch. Worse yet, no where in the "release notes" , "known issues", "changes since 8.6", do I see this mentioned. I wouldn't have known about it, possibly for some time, if in debugging the test system hardware we hadn't had a hardware error (which hadn't occured in the prior three months of "ringing out" the hardware) that generated and error on the error cluster. The shared variable was in the  various loops in my program to allow them to be stopped if an error was detected, or the operator was shutting down.
    I would suggest that you use some type of "functional global" also called a LabVIEW 2 style global  which uses a shift register on a while loop as the memory storage element in a while loop wired to execute only once (the stop node is wired "stop")rather than "real globals" unless you encapsulate the global in a sub-vi,. You can wire an error cluster straight through to allow the resulting vi to use the error chain for execution order control, as I had planned with the Shared Variable. You can also have a write case, read case, etc. inside the loop.  Search on the this board for "functional global" or "LabVIEW 2 style" (there were no globals back then).
     My fix at the moment is that I drove 250 miles (400 km) through a snow storm  last night, am going in this morning and scrubbing the 8.6 based machine and installing 8.5.1 to make both machines identical. I would have done this originally (and not found out about this issue) but last week I forgot to pack my 8.5 DVD's and the customer only has the 8.6 ones at this time. They will be calling the NI office that handles them for their own, I suspect.
    Putnam
    Certified LabVIEW Developer
    Senior Test Engineer
    Currently using LV 6.1-LabVIEW 2012, RT8.5
    LabVIEW Champion

  • Empty Shared Variables & Data Binding not working in dynamically called VI

    Hi,
    I have just upgraded a system from LabVIEW 2011 to 2012 DS2.  I have a real-time PXI system running several shared variables, hosted on the PXI.
    After what appeared to be a succesful upgrade I have a couple of odd issues. 
    1.  The PXI writes test data into a network shared variable, based on a typedef of an array of custom clusters.  The variable is disconnected from the typedef, as RT does not function with shared variables linked to typedefs.  It seems that writing a seingle entry to the array is fine, but writing multiple entries causes the variable to appear empty. 
    I still need to debug this a little more, as while I was station to do so this other issue popped up.
    2.  I have some controls on the Host app with data binding to shared variables.  The host app uses three VIs dynamically called into the wrapper VI.  One of these called VIs is not able to connect to its variable when inserted in to the wrapper, but it can if run independently.  The other two have no such trouble.  Where I see a problem, the indication LED is grey and the mouse-over text reads "no status".  What does this mean?
    Any clues?
    Thanks,
    Ian

    I have changed the Invoke Node to a Run Asynchronous node, and this seems to have fixed the data binding issue. 
    The other issue may be related to a bug fixed in 2012 SP1:
    368648 Network Stream operations return Error 42 when data type contains nested clusters of typedefs
    I am now getting error 42 when reading a particular network shared variable.  This variable contains the results of measurements, in a data type which contains an array of nested clusters of typedefs.  When there is a single entry in the array I can read the variable fine, but when there is more than one entry in the array it does not read and I get error 42.
    I have downloaded 2012 SP1, and will see if this helps. 
    Ian

  • 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!

  • CRIO and ni 9234 modules not working or communicating through fpga with accelerometers, fpga connected to real time application which is also connected to shared variables linked to modbus slave

    Hi,
    I have a compact rio which has a 4 way chassis attached to that chassis is three ni9234 modules they are linked using fpga to a real time application then using shared variables in the low speed loop that are linked to a modbus slave to communicate with dcs, the ni 9234's have accelerometers connected to them with iepe ac coupled option on the c modules, my problem is the real time application seems to be running okay even when power loss occurs it restarts with no problem and the fpga writes to the portable hard drive bin files fine but without a accelerometer connected I get low noise readings as soon as I connect a accelerometer to any one of the 10 outputs it just goes to a fixed number (0.03125) as soon as disconnect it again it reverts back to reading noise, I have run a scan on the modules and only get a spike when I connect or disconnect the accelerometer, I have tested the voltage at the pins of the module and I get 22 volts dc which makes it more likely that the hardware is not the problem but a software is maybe causing this to hang-up, I attach project and files for your perusal. I also carried out a new project which in scan mode directly linked the module input to shared variable and the same scenerio again. Help would be much appretiated. 
    Many thanks
    Jason
    Solved!
    Go to Solution.
    Attachments:
    logger 2plusmodbus2.zip ‏679 KB

    Whren using waveform acquisition with the 9234s we recommend the following FPGA and RT template.
    http://sine.ni.com/nips/cds/view/p/lang/en/nid/209114
    it can be extended as a data logger with:
    http://zone.ni.com/devzone/cda/epd/p/id/6388
    or using shared variables combined with scan engine
    http://zone.ni.com/devzone/cda/tut/p/id/9851
    The FPGA in all of these, as well as the RT framework have been used successfully by 1000s of users.  I would recommend giving these a try. 
    Preston Johnson
    Principal Sales Engineer
    Condition Monitoring Systems
    Vibration Analyst III - www.vibinst.org, www.mobiusinstitute.com
    National Instruments
    [email protected]
    www.ni.com/mcm
    www.ni.com/soundandvibration
    www.ni.com/biganalogdata
    512-683-5444

Maybe you are looking for