RT ocasional error

[Sima]

Hi Sharonoff, that looks a lot better. You left out all the good stuff.

This line: "Thread name: LV TL[50100]: L599588" tells you right there that you the timed loop named "L599588" is where the RT crashed. Comparing your other error logs, do you see the same loop crashing all the time? Definitely try replacing this loop with a regular while loop and use the RT wait functions instead. This is what we had to do for a workaround. NI does not know yet why this is occuring in 8.2.1, but there will hopefully be a fix for it. I don't know whether it has been fixed in 8.5.

If replacing with a regular while loop doesn't fix it, then something else is going on with the code. We spend a good deal of time and effort picking at our code, which had been working for so long until 8.2.1, but when we replaced our timed loops with while loops, we we haven't had another crash - so far.

[TerraNova]

Hi!

Done with replacing Timed with Regular.
I'll post results after a while.

...Another wonder is that I couldn't reproduce this crash on another PXI system with absolutely the same parameters (with Timed Loops, off course). I've tried to for about a week (about 30 working cycles).

Moreover, yesterday, upon controllers excange among this two systems (leaving chassis and I/O modules), this problem followed CONTROLLER (PXI-8186). There was no crash on "good" PXI-8186 after about 10 working cycles (almost all the working day period), while the "bad" crashes every 3rd trial.
...Strange...

Suppose, when it'll be possible, I'll format hard disk and setup "bad" controller anew.

Thanks!

[Sima]

So you were running the same code on two different PXI systems, and one of them crashes but the other doesn't. I know where you're coming from, except we eventually saw the other systems crash. Some just took longer than others.

What about their setup? LV versions? Driver versions? Look under the RT system --> Software and compare versions of the drivers that are there.

If you took the image of the "good" PXI and put it onto the "bad" PXI, would it no longer crash? Or vice-versa: if you took the "bad" PXI image and put it onto the "good" PXI, would that start to crash?

And as you said, you could try to format the "bad" PXI.

[TerraNova]

Hi, Sima.

The thing is that I configured both controllers by means of the same WinXP-PC with the same parameters (one for use and one for my pre-use tests).

Still, the probability for the crash to occur eventually on the "good" PXI remains, off course.

Thanks.

P.S.: After TimedLoop replacing with regular no crashes have been detected for 3 days, at least, meanwhile.

[Sima]

Hi Sharonoff, is 3 days good? How often did it used to crash with timed loops? Now with regular while loops, how long is long enough to say that the problem no longer occurs?

[TerraNova]

Sima!

Thank you very much for your attention.

It looks like this problem has gone with the "bad" TimedLoop (mention: there still at least two "good" TimedLoops working simultaneously sometimes - they're acting fine :)).

Suppose, only thing to go is to try to reproduce crash on another PXI - it's no good meanwhile.

Regards.

[AK1JOHN]

I have had no problems with running timed loops from LV 8.5 on our PXI test chassis which uses one of the older processors running at 1.2Ghz. What I have run into is problems with running timed loops with Windows XP on a regular PC’s with the INTEL CORE 2/QUAD processor. When the same code is run on slower machines no problem shows up. The error message I receive seems to indicate that the timed loop itself cannot write to a memory location if I understand the error message correctly. Part of the error message also mentions a AMD feature code which I do not understand since the processor in use is a INTEL and not AMD.

The crash problem on my XP machines only occurs when more than one timed loop is being used, two or more loops running cause part of Labview to stop working. When Labview is restarted after such a Labview crash the Windows task manager reports multiple instances of Labview running. If all of these are not shut down it just keeps on adding more instances. I have had up to six Labview instances shown in the task manager.

I thought this was perhaps associated with our code a while back. So I built a simple VI that runs multiple timed loops at 100ms rate with different names for each loop and nothing more that a iteration counter display in the loops. This also causes Labview v8.5 to crash, but not totally since some functions appear to remain functional. What I have not tried is to reduce the system memory when XP is installed on one of the PC's from 4GB to 2GB as would need to be done if I was running real time on these machines. I should add that both of the machines I have with the INTEL CORE 2/QUAD processors work fine as real time targets when the system memory is reduced to 2GB.

I hope that the timed loop problem gets fixed soon since not being able to use it and being forced to use the while loop instead is causing some timing problems to show up in the project I’m working on.

[eek]

AK1JOHN,

One that I think needs clarification is whether you are running a RT application on a dedicated RT target or on a Windows computer. While you can certainly use timed loops on a Windows computer, you'll simply be using them to assign "downtime" in between iterations of the loop. In this respect, there wouldn't be any difference between using a While Loop with a timing VI and using a Timed While Loop. You won't be able to guarantee that the loop completes at a specified rate on a Windows OS because you don't have access to the priority that is given to the task (at least not through LabVIEW). This is where a dedicated RT target comes in. It runs the RT OS that allows you to assign specific priorities to your timed loops to ensure that they can complete at the specified rate.

So the cause of your crash might be because you have several timed loops that are attempting to run at a specified rates on an undeterministic system. If you need to address the timing issues that occur when you use regular While loops, then I would suggest you use dedicated RT targets in your application.

If I've misunderstood your problem, please clarify matters for me, as I would like to see if I can help you.

Cheers,
Emilie K

[AK1JOHN]

Emilie K,

My host application which crashes is running on a PC with WIN XP service pack 2. There is no realtime extension installed on the PC. What bothers me is why the timed loops work well on older slower PC's and not on the newer PC's I have. In the meantime I will juse the while loop functions untill I can identify the problem more clearly..

[Bill_in_Detroit]

This looks like the appropriate thread to post my question, and it looks like it hasn't seen any activity in a while so here goes:

I have an application running on my 8106 embedded processor, a PXI 1044 and LV 9 RT.  I am running a timed loop on the input side that outputs data to a queue.  The processing loop (a while loop containing an event structure) is running in parallel with the timed loop and it is triggered by the timed loop when data has been queued. After some many weeks of working with and refining this structure I have noticed that on longer runs (about 15 minutes or more) the Realtime process suddenly quits out of the blue, leaving no logs to give me any idea why.  I thought at first it was a memory problem and have read everything I can find within these forums on optimizing the code to avoid those issues.  Out of frustration I ran the Real Time System Manager (RT SM) tool to monitor the real time memory usage but it shows pretty flat memory usage and even more surprisingly, my application ran for over two hours without any issues.  It wasn't until I stopped & closed the Real Time System Manager that the problem I have been seeing reoccurred.  I have tried the experiment several times and as long as I keep the RT SM open and running, my application works fine.  If I stop and close the RT SM, the problem soon reoccurs.  I have included a small image capture of the RT SM so you can see I am only using a steady ~21 of the combined CPUs.  I am using about 3% of system memory continuously according to the RT SM. Any ideas?  One question I would like an answer to:  Are there any processes that run on the RT chassis in the background that are "suppressed" when the RT SM is monitoring memory and VIs?  What else can account for the behavior I am seeing here?