LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

RT target reboots due to system error

The RT target reboots and displays the following error after the normal setup info:

Reboot due to system error.
Redirecting output to log file.

I don't know where this "log file" is saved and I don't know why the rt engine restarts.

I have 3 PCI 6143 boards and I'm reading at 250 ksamples/sec. I'm storing the data to an RT FIFO (waveform dbl array type) and using TCP to send this to the host computer where I want to display in a graph. The vi on the target computer runs fine without any connection to the host computer. When the vi on the host computer starts up, however, problems start to happen.

The host computer gets the data from the target very slowly. It takes about 5 seconds for TCP Read to read the byte size. The byte size is about 600kb. After the byte size is read the rt engine mysteriously restarts and displays the message above. My system works fine if I change all the waveform dbl array types to DBL Array. The reason I want a waveform type is because the host computer is not getting enough data with the DBL Array. For example, instead of getting a steady, straight line in the graph, I get a line jumping from 0 to the value it's supposed to be over and over.

I'm using vis similar to the vis created by the RT Communication wizard for both the target and host communication.
0 Kudos
Message 1 of 14
(4,588 Views)
Can you provide more information on your system configuration? Which version of LabVIEW are you using? What kind of Real-Time controller do you have? What is the network configuration between the host and the RT target (i.e. - LAN or crossover cable, static IP or DHCP)? Are you doing a buffered or single point acquisition? Is anything running at time-critical priority? Can you post a simplified version of the VI that demonstrates the problem?

Regards,

Kristi H
National Instruments
0 Kudos
Message 2 of 14
(4,554 Views)
hi Kristi,

thanks for responding.

I'm using Labview 7.1 Real-time on a dell gpx 270 on a LAN (gigabit connection) using static IPs. I'm currently doing continuous analog acquisition on multiple channels (24 total). I have a normal priority loop managing the TCP connection, a time-critical loop within that acquiring data. On the host computer (another dell) I have all normal priority vis. I have 1 VI that contains 2 vis in it- a vi that handles the GUI and a vi that handles the TCP.

I gave up on using waveforms so i'm getting the y-component out of the 1D-waveform that i get from the daqmx vi and putting that into a 1D dbl array and storing it in an rt-fifo. By the upload, hopefully, you can see what i'm talking about. Without using waveforms the rt target does not reboot, but i still get jitter. The host computer (with the gui) seems to be reading an empty fifo more times than it has data. When I put a 100ms wait in the TCP loop on the host computer, I get the data slower, but no jitter. I don't know anything about timing so I'm guessing that's my major problem. Am I supposed to put waits inside of various loops?? I varied my time-critical loop wait time from 1ms to 3ms to see if anything would change, but no changes.

On a side note I will be acquiring data from a total of 13 6143 PCI boards from 5 different PCs when this is all done.
0 Kudos
Message 3 of 14
(4,547 Views)
You might try changing your time critical loop to normal priority. Because you are doing a buffered acquisition, you know that your acquistion will be deterministic since you are sampling your signal with the board's clock. The data is collected onto the board's FIFO and transfered with DMA into your LabVIEW application. Time critical priority normally only needed when you are doing other software calculations, in addition to your data acquisition (DAQ).

I have seen issues with doing buffered DAQ in a time critical loop because the DAQmx Read will attempt to use as much processor time as possible to continue checking for data. At time critical priority, this can block the normal priority tcp loop from running like it should and may explain why you aren't getting all of the data back on the host.

I would suggest either changing the priority of your DAQ loop to normal priority, or using a Timed Loop instead of a while loop around your DAQmx Read. The timed loop can be timed from the board's sample clock and be given a period equal to the number of samples you are reading during each iteration. I have attached an example that shows this.

I hope this helps. Please post a reply if you have further questions.

Regards,

Kristi H
National Instruments
0 Kudos
Message 4 of 14
(4,543 Views)
I got your example to work, but I'm not too sure I understand the parameters very well. The top part of the image I attached is part of my VI that I acquire signals. I'm not too sure what to set dt as. I'm thinking that it should be 1000 ticks so that I read in 250000 samples every second. Or dt should be 4 ms because that is the period. In my task I have the Rate at 250000 Hz and marked as Continuous sampling. My RT target has froze on me many times while playing around with the dt value. What is a ball-park value for dt? I've set my values from 8000 down to 4 and my loop only goes through once or not at all. By the way ticks and milliseconds are the same right?
0 Kudos
Message 5 of 14
(4,533 Views)
The dt input on the Timed Loop should be equal to the number of samples you are reading during each iteration. For example, if you were sampling at 1000 Hz and reading 200 samples during each iteration of the loop, dt should be set to 200. Notice that because you've wired the external timing source to the Timed Loop, the Timed Loop is looking for dt in terms of ticks of the sample clock, in this case.

According to your task, you are reading 250k samples and sampling at 250kHz. So, you would probably try a dt of 250000 ticks. However, you'll probably get error -200279 from DAQmx, which means you need to read the data more frequently.

If you have more questions, please post a reply.

Regards,

Kristi H
National Instruments
0 Kudos
Message 6 of 14
(4,525 Views)
My RT FIFO doesn't seem to write whenever I use a Timed Loop. Can you look at my simplified vi and see what's wrong? Also, I set dt=100 and the sample rate to 2500 to get 250000 samples/sec.
0 Kudos
Message 7 of 14
(4,512 Views)
It looks like you just need to wire the input of the FIFO Create called Elements in Array. By default, this value is one which is why you are only seeing one value in your read.vi. Make that 24 and you should see all of your values.

Hope this helps!

Kristi H
National Instruments
Message 8 of 14
(4,492 Views)
I got your example to work, got my example to work...thank you very much... but I guess I'm still a little confused on how I read 250K samples/sec. When I have the sampling rate at 100KHz and the dt=1000, it's ok until I get the -200279 error which I know means that I'm not reading fast enough. I tried setting the sampling rate to 100KHz and dt=90000 along with the # of samples/channel and i still get the -200279 error. I tried increasing my buffer size to 2000000 using the Daqmx Configure Input Buffer vi and I still get the -200279 error when the rate is 100khz. When I try setting the sampling rate to 250kHz, my target stops responding. What are the best values for dt, # of samples/channel, and buffer size to read in 250Ksamples/sec?
0 Kudos
Message 9 of 14
(4,475 Views)
Thanks for the example and help and quick responses.

I guess i'm still a little confused about the timed loop... I tried setting the sampling rate to 100000hz but no matter what I put for the dt and samples per channel, i always get a -200279 error. I even set the buffer to 2000000. Am I doing something wrong? I tried values from 50 to about 90000. If I set dt too low, the target stops responding. If I set the sampling rate at 250khz, the target stops responding. What values for dt, samples per channel, and buffer size would i need to get 250ksamples/sec?
0 Kudos
Message 10 of 14
(4,470 Views)