LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VI freezes for first 10 seconds of code

Solved!
Go to solution

I have a VI that sends a digital trigger out through a 9472 DC sourcing power supply mounted in a 9187 cDAQ.  This trigger is used to trigger an external custom build DAQ that sends its data back to my VI as a tab delimited string over the USB port. The issue is that when I run the code nothing happens for the first 10 seconds of the code, the indicators on the front panel are not updated and the lights on the 9472 do not flash. 

 

I assume something is holding up the code, maybe a timeout type switch, for the first 10 seconds.  I have the code split into separate VIs (timer and DAQ read) and I do not have this problem. If I run the debugger I can not get the code to hang up. Also, if I set my S/s to 1 The code start right away, however, if I set the S/s to 2 I get a 10-second delay in the data, the output data looks like this:

 

0.501000 0.000000 0.000000 0.000000 0.000000
10.517000 54.000000 58.261550 74.109660 57.661940
11.018000 54.000000 58.240340 74.108100 57.663090
11.519000 54.000000 58.242510 74.112320 57.669850
12.020000 54.000000 58.235690 74.109390 57.670770
12.521000 54.000000 58.246300 74.119160 57.669560
13.022000 54.000000 58.253480 74.114660 57.671260
13.523000 54.000000 58.248350 74.116830 57.666190
14.024000 54.000000 58.263830 74.104190 57.669020

where column 1 is the time data. 

 

 

Any suggestion would be appreciated,

 

Best,

Austin. 

0 Kudos
Message 1 of 7
(3,603 Views)
Solution
Accepted by topic author Austin-Downey

You configure your serial port with a 10 sec timeout. Maybe it throws a timeout error, and because you did not connect the error wire out, you do not get info about it?

 

serial1.png

0 Kudos
Message 2 of 7
(3,574 Views)

I changed my serial timeout to 100 (0.1 seconds) and that seems to have removed the lag. Thanks! However, I do wonder why it causes a lag on this code but not on the code without the trigger portion?  Also, I connected the error out command and I still don't get an error when the time lag is present. 

 

Thanks again, 

Austin. 

0 Kudos
Message 3 of 7
(3,560 Views)
  1. Instead of this messy Flat Sequence Structure, you should learn how to use a proper state machine.
  2. The other problem is that, even if you have an error via serial comm, your code is not capable to capture it and report it to you...
  3. I am really not sure that your timing is proper. It is very strange, instead of a proper wait function, you have that "CPU burner" (PC tries to iterate it as fast as possible) While loop in the first frame of the sequence structure.
  4. Do you really need to keep the digital output line at a logical high state only for 1 msec? Then flip it back to False state. Does this triggering method actually work stable for you?
  5. You need to use a single digital output line, yes? At least this is what you config for the DAQmx Create Channel function: "cDAQ-SEC_test_benchMod1/port0/line0". If so, why do you use the DAQmx Write as "NChan 1Samp"? It should be just "Digital Bool 1Line 1Point". Of course it also works now with your single element Boolean array input, but not elegant...
  6. What is the required termination character for your serial comm? Do you have any manual for this custom made serial device?

 

In overall, I think you should reconsider your whole code. Could you give us more details about your project requirements? It can be tricky when you have to deal with tight syncing between a serial device and a DAQmx hardware. You might need a very different design pattern here...? If you give more details about your hardware, and what exactly you need to do (timing requirements, flow chart, etc.), more experienced people than me will jump into the thread and give better ideas...

 

Just as an ugly modification ("quick first aid patch"), see this how to capture errors from the serial com (sorry for the simple screenshot, i cannot create a proper LV snippet, LV2016 Code capture tool throws me "memory full error"):

 

serial_daqmx.png

 

 

 

 

 

 

 

0 Kudos
Message 4 of 7
(3,525 Views)

If you are pulsing that quickly, use a counter output instead of a digital line.  Most NI DAQ devices have this capability.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 5 of 7
(3,516 Views)

@crossrulz wrote:

If you are pulsing that quickly, use a counter output instead of a digital line.  Most NI DAQ devices have this capability.


As I understood based on the OP and the original VI, that the code should send a trigger, then read back data via the serial port. After this there is a 1 second wait. So every one second a trigger is sent (output high/low change) in 2 msec...

But it can be easily that I totally misunderstood the code 🙂 Lets wait for the OP to clarify further the requirements / hardware components. Specially we could hear more details about this custom DAQ which "spits" serial data when triggered...?

0 Kudos
Message 6 of 7
(3,504 Views)

Everyone, thanks for the feedback.  I am fully interested in trying to enhance this code, so let me share some information. I will try to answer the questions that were posted by Blokk

 

1) I agree,  (I have never used a state machine) however, I am currently running the test setup on a cDAQ as I try to work out a few engineering issues and I plan to shift it to a cRIO in the future, so maybe it would be better to hold off on that? Maybe not?

 

2) I think that is why you added the simple error handler VI? Still, I do not get an error when I run the code with a 10 second timeout. 

 

5) I updated my code to match your suggestion. I like elegant solutions 

 

3,4,6) I built the DAQs, so they send a tab delimited string back in the form of

[float \t float \t float \t float \n]. The DAQs are set up to run continuously whenever 5V is applied to the trigger port.  This is why I have to turn the trigger on and off quickly. Yes, as of now the trigger seems to be stable. If the trigger is in the HIGH position when the when the first data collection is completed the DAQ will take another sample and I need to prevent this. My main reasoning is I need all the Daqs to have a common time stamp. This is also why I have my trigger loop set up the way I do, it acts as a latch to release the code when I reach the next iteration of the time step.  

 

I have attached my updated code, I am still looking for the reason that the code waits the full timeout time the first loop of the code.  Again, I am not getting any errors in the code. 

 

1.png

 

 

0 Kudos
Message 7 of 7
(3,458 Views)