Iron_Scorpion

I have a program that reads a cDAQ NI 9221 Analog input card. Occasionally (1 in 3Billion), one of the values is 0.000000V. Using an NI 9189 chassis with an NI 9221 Analog input card. The task is set up to capture at an 8k rate and read n samples at a time. My program reviews the values and records a 2000 point chunk to excel if there is an error with the voltages. The program needs to run for 45hrs at a time, so over a billion readings per run. Once in a while, maybe once every three 45hr cycles, one of the errors logged is because of a 0.000000V reading. Adjacent readings are perfectly fine, and do not ramp in or out to 0. And since the 0 value is absolutely 0V I am suspicious that it is not coming from the DAQ but is instead a memory issue in the PC. Has anyone else experienced this? Here is an example of readings: 23.731911 23.762417 23.792923 0.000000 23.792923 1 occurrences in 3Billion is very good for consistency, but I am curious why. If the SW is stable looping for 3Billion readings, I don't think its anything with my code.

Rolf. Fantastic, you were right. Setting the resolve false makes it recognize the connection at the same time the device does. The program is running smooth now. Thank you, thank you. Such a simple change never dawned on me to try. I suppose my next step is to look into my DNS setup, and what changed. Oddly this issue popped up on 2 separate PCs at the same time. Thank you again.

Thanks infinitenothing, I am familiar with that example. Since it uses the white TCP Listen.vi whereas I use the tan create listener and wait on listener directly, I just changed the port number on the server example VI and ran it to see what would happen. Same results. Right as the White VI starts the device tells me it made TCP connection and I see TCP syn/acks on wireshark as well as a packet of data from the device. Then the device gets no response, so it disconnects and reconnects. All while LV is still running inside the white VI. After a few second pass and multiple messages from the device, the white VI finally finishes and data gets pulled inside the loop (with error 66). Again at this point the device has timed out and disconnected.

I have a VI that communicates TCP. It starts by jumping to a 'listen' case where it creates a TCP listener on port 7777, then uses the TCP Wait On Listener. If it finds an IP, it jumps to a read case. The TCP Wait on Listener has the listener ID passed directly to it from the create listener VI, resolve Remote address is left unwired (T), and the timeout is currently set to 100ms (I have tried numbers ranging 1ms-20s). I have been tracing communications with wireshark. If there is no device to connect to, the listener runs in 99-101ms. When a device is connected; wireshark shows tcp acks/syncs happening immediately after creating the listener. The device immediately sees the open connection and sends a TCP data packet. The wait on listener Vi will hang for around 16 seconds, then return the packet and an error 66 (peer closed connection). The error 66 is expected because the device has a response timeout and kills the connection on its side. The listen VI does not finish until the connection is closed by the peer. Why is the wait on listener Vi: 1) not seeing the connection immediately when wireshark sees it as open 2) if it doesn't kick when wireshark sees the connection, then why not when it receives the tcp data packet? 3) when there is actually data, why is it not timing out at 100ms? The only help I found online was https://forums.ni.com/t5/LabVIEW/TCP-Client-Not-writing-until-connection-is-closed/td-p/3576135?profile.language=en This is sort of what’s going on, only the roles are reversed. LV wasn’t sending till it closed the connection. He added an EOL to fix it. The problem I have with this is that my device doesn't use EOL (CR LF), each TCP is a concise complete message. If I make a simple Vi that sends TCP data packet (a copy/paste of the wireshark hex stream of the device), the program works great. LV may be adding the CR/LF or some EOL? If this is on track of the issue, Is there a way to not wait for EOL? Running LV17.0.1f3 64-bit Thanks everyone.

Inside the express Vi properties for the sine, there is a check-box for additional inputs. The one input I'm using is Phase increment. An optional input is phase offset, I don't have that active since I don't need to phase shift. what I expect the equation to do, is take my desired freq and calculate the necessary phase increment per clock tick for that freq. Where does the 2^32 come from? Is this function forced to a 32bit integer? I'm still wondering about the 40Mhz; is that the right clock freq to use? If my math is correct, dividing my frequency by 1.25Mhz for the clock should give me a phase increment very close to what I expect. I don't know why. Is it that the FPGA clock is 40MHz, but a derived frequency is actually used for these calculations? Again, thank you everyone for your continuous help.

1. I have been trying frequencies all over the range. Ultimately I will need between 45hz, and 7.07kHz. 2. No. I still get a sq wave. 3. Fluke 175 RMS handheld meter, and a Tektronix TPS 2024B 200Mhz Oscope 4. Scan mode is not apples to apples. In FPGA target I use the Sine Generator express VI, from the FPGA pallet. That Vi is not an option from scan mode. As it stands right now, that VI is the problem. I can create a sine wave using the High throughput sine VI, in FPGA target mode. But it would be much easier to implement if the FPGA sine wave generator Express Vi would work. As a question on the side. Does anyone know the calculation for output frequency to phase increment (input my desired freq, get out the value that goes into the sine gen VI). In the sine generator example from LV, there is a PhaseIncrement.Vi. It has the equation as (Freq/FPGAClockRate)*(2**32). Using this equation I can not get anywhere near a frequency I would expect. Should I not be using 40M for the FPGAClockRate?

Mark, I am not using hybrid mode, so based on that link I didn't expect this to help. I am running 2014 SP1 and rio 14.5, so I downloaded and installed rio14.6. I rebuilt the above VI and it just compiled with no issues. That is awesome, thank you. Unfortunately, the sine function is outputting a square wave (or a wave that looks more like a cap charge/discharge). My assumption right now is that this may be a casting issue with fixedpoint numbers. I'm digging into it.

Only Local

See the attached screen shot. This crashes compilation. "some of the compilation steps were not executed. refer to the Xilinx log†The xilinx log is what looks like hundreds of pages. I see many warnings, but nothing that looks like a critical failure. If I replace the sine wave with the square wave function, the code will run fine. I am running a cRIO-9067, with an NI-9269 module. All I am looking for is a simple output sine wave VI. Freq and amp variable going in, and a waveform out of the RIO. Any help would be greatly appreciated. I have been using NI's examples (http://www.ni.com/white-paper/3780/en/#Example, fig2) linking to my hardware. I suppose I'm looking for a few answers here: 1. Why does this fail compilation? 2. Does anyone have a VI that will just simply output a sine wave? Thanks again, Chris

I looked into turning off the debug option and it was already turned off. So unfortunately that didn't work. That article was how to remotely debug an exe. Any idea if that can be done locally?

-Yes this does happen in dev. The Vi is set to run on open. -I have not tried to turn off debugging when building the exe. I'll give it a shot, thanks. -Not sure what you mean "...executable in debug". If your suggesting watch the dev in highlight; Since the VI is set to run on open, I can't get to the block diagram until I stop the code. If I turn off the run-on-open setting, then reopen the code, then go to the block diagram, then click highlight, then click run. It does not happen. because I have clicked a bunch of times inside LV. Clicking something makes it better. Trying to debug it as an exe, as I described in my first post, I have put a popup in the very beginning of the code and run the exe. That popup will not show until I click an indicator. So there is really nothing to watch run up to that point, because the code isn't actually running yet.

yes

This program is a very old version of LV’s Test Executive. Our company purchased the source code to Test Exec all the way back in LV5.1 I believe. We have altered it to our needs and upgraded it to LV6.0, 6.1, 7.0, 8.0 and 10.0 This version of test executive does use an activeX HTML indicator on the FP, to view HTML datasheets of tested units. I have opened the program and left the computer overnight. It did not execute until I click on a string indicator the next morning. It is definitely triggered by clicking an indicator. It also appears that clicking a control will not do it; it must be an indicator. Usually we click the string indicator or the activeX HTML indicator, to get it rolling.

I have an executable in LV10 (on Win7). When I run the exe the program opens and shows the front panel, but is not executing until I click on an indicator. I have confirmed this by placing a single button popup immediately at the beginning of my code. When I open the exe, I see my FP but the popup will never show; until I click on an indicator. Then the popup shows and the program continues. It appears that LabVIEW itself is frozen until I click an indicator. Because, if I open llb and open the top level VI, I cannot close the LLB manager until I click on an indicator, in the open FP. I am inclined to believe that this is a windows issue. Possibly windows is disabling the execution of the program, because of the length of time that LV takes to open? Has anyone else experienced this? Any suggestions? I don’t believe there is anything I can do in LV code to alleviate this, because I have proven the LV code isn’t actually running yet.