04-03-2017 11:58 PM - edited 04-04-2017 12:23 AM
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.
Solved! Go to Solution.
04-04-2017 12:31 AM
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?
04-04-2017 12:58 AM
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.
04-04-2017 03:51 AM
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"):
04-04-2017 04:15 AM
If you are pulsing that quickly, use a counter output instead of a digital line. Most NI DAQ devices have this capability.
04-04-2017 04:56 AM
@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...?
04-06-2017 12:17 PM - edited 04-06-2017 12:20 PM
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.