Realtime executable compilation question

[FWalker]

I am runninig a real time application on a cRIO 9012 using the tcp messaging protocol.   I read  values from analog input modules and write to a digital output modules pretty much following the basis of the examples provided on ni.com.   Everything runs perfectly when I run the Real-time application from the LabVIEW API, that is without compiling, just running the host VI from the desktop and the client/HMI VI from either My Computer or the target which is a TP-2012.    My problem is that when I compile and run the Realtime Application my digital outputs do not work.   In other words it seems that there is only one way communication from my HMI to the cRIO.    So my question is why would a VI work correctly under LabVIEW but not work when compiled and deployed to the target?  

[FWalker]

I just tried to debug the application, after selecting Operate>> Debug...>> Connect I get a compiler error message that says contact NI.   

[FWalker]

The error reads exactly:
                        Compiler error.  Report this problem to National Instruments Tech Support.   copy cvt refnum, csrsc=0x3

This same code pops up three times after hitting OK.   The third time the error window says the same thing except "refnum" is replaced with "bool" and csrc=0x0

After clicking OK the first code appears 2 more times.   I found a slightly similar situation in KnowledgeBase and quite frankly it seems beyond my scope of understanding of the software could someone please provide some insight?

[Kevin_H]

Hi Walker,

Thank you for contacting National Instruments.  I wanted to clarify a few things with you.

Your program works fine when the host VI (which will eventually be on the cRIO) is running on your development PC, and it has no problems communicating with the TP-2012.  The problem arises when you deploy this VI to the cRIO, and the digital output does not function, correct?

This error only appears when debugging the app?

What version of LabVIEW are using?  If you are using LV 8.2 or later, is there a reason you are using TCP over shared variables?

I look forward to hearing back from you.

Regards,

Kevin H

[FWalker]

Thanks  for replying Kevin.   I have since rewritten that section of code and it works like it should now.   I was trying to take the easy way out, all of my digital ouputs are written to the fpga through a cluster and I was using the property node "value(signaling)" to write to each individual control within the cluster.   Like I said it would work as long as I maintained the Desktop interface with the cRIO, but compiling and running onboard the cRIO alone would not work.   Attempting to debug with the "value(signaling)" property nodes would result in the above stated errors but I replaced them with the property node "value" and voila the debugger downloaded and interfaced with the running .rtexe.  The program worked just fine with the debugger running however as soon as I disabled the debugger the digital outputs stopped working.   I got rid of the property nodes, wrote directly to the fpga reference now everything works, I can turn off the desktop and run the cRIO with the TP-2012 without a problem.

Why do I use TCP?   My number of shared variables reached a point where I was usig too much network traffic as well as too much cpu time, and I'm simply not that good of a programmer to solve that problem, so I was advised by an NI rep. to try the TCP messaging protocol.   It is noticeably more responsive and uses alot less cpu resources, the block diagram is huge but I am satisfied with the results.

[FWalker]

I'm using LV 8.5 btw

[JamesTJ]

Why do I use TCP?   My number of shared variables reached a point where I was usig too much network traffic as well as too much cpu time, and I'm simply not that good of a programmer to solve that problem, so I was advised by an NI rep. to try the TCP messaging protocol.   It is noticeably more responsive and uses alot less cpu resources, the block diagram is huge but I am satisfied with the results.

I'd be interested in discussing this further with you as well as maybe taking a look at your application.  For one, because we designed the Shared Variable abstraction to aid people who didn't want to worry about all the complexities that come with raw sockets programming.  Also, I'd like to make sure that NSVs aren't using that much more of the network bandwidth than a comparable TCP implementation (because they shouldn't).

In the end, because the Shared Variable is an abstraction, it is always going to come with some level of overhead above a raw implementation, so sometimes stepping down to something more native is the right solution.  We've tried hard to make those cases smaller and smaller with every release.

[FWalker]

Hello James, 
  I understand what you are saying and let me clarify that the version of my code that used shared variables worked just fine, It did what I need it to do at my skill level as a LabVIEW programmer, which is somewhere between beginner and intermediate.    I will say that between the time I created my application using shared variables up to now I feel like I know a lot more, so perhaps if I tried to rewrite my code with shared variables I wouldn't have as many problems as I had before.    The main problems I had would occur when I would simultaneously run a continuos acquisition loop at 20S/s along with a DMA loop at 100kS/s,   The DMA loop would always overflow the buffer due to cpu overload but this could have been avoided perhaps by a more skillful programmer.    I used the variables to communicate through touch panel to switch valves, the response time just seems so much more rapid and consistent using the TCP method.    I prefer not to post my code here on the board because it contains somwhat proprietary information but if you will send me a contact email and I'll gladly allow you to take a look at it.

Fred Walker
Utron, Inc.