RT system monitor reports several VIs as "bad" then crashes

[testingHotAir]

Ok.  I set the two top loops to the same priority...same behaviour.  It doesn't look like the loops are executing at all.

The timing source and dt in the middle loop are hidden so I can see all the wires going into the left side of the loop.

Looking at the actual time indicator isn't telling me anything as the controller crashes before this indicator is written.  

I tried moving the SVE server to the host PC, but that only reduced my processor usage by ~3% while the top level VI is idling.  To gauge the effect of the shared variables on processor usage I built a simple VI that just had a single timed loop running on the controller and a single while loop on the host PC with shared variables being read and written to.  Each variable I added seems to account for a 1% increase in processor usage over the ~10% basline for the timed loop running without anything in it at 100ms iteration time.  I have 37 shared variables in the program that I'm having trouble with, which would account for ~37% of the ~50% processor usage I'm seeing if the little test VI predicts that behaviour accurately.  

Do I need to completely rethink my architecture here?  Am I simply using the wrong hardware for the job?  Any suggestions on how to decrease processor usage?

Thanks again!

[rex1030]

Well in general, if its possible to host the shared variables on the pc, do it. Keep in mind one of the awesome things about the VxWorks operating system is that when the processor gets really busy with your program, 'unimportant' processes like network connectivity get neglected and you lose connection with the device.

Unfortunately it seems the obvious stuff isn't your problem. What I suggest you do is start disable diagraming large chunks of your program until it works. This will help you narrow down exactly which part of your program is bombing. It sounds basic, but you would be surprized how effective it is. 

Were you testing the program the whole time everytime you added something new and then suddenly this started to happen when you changed something in particular or did you write a lot of it and then try to test it?

Message Edited by rex1030 on 11-02-2009 01:49 PM

[testingHotAir]

I've been working on this system for a little over a year now and have been testing each piece along the way.  I've commented out all the recent additions down to the point that I have just enough functionality to turn the thing on without doing any damage and it still crashes.  I noticed that the VIs that are commented out are still listed as running in the RT System Manager.

Is there a way to regain the connection after it's lost other than resetting the controller?

[rex1030]

I have never found a way other than waiting for it to wake up, which some programs do.

What were the most recent parts you worked on if it worked up until recently?

[testingHotAir]

I added a VI that controls a Rockwell drive over RS232 and another that controls two orifice changers, also over RS232.  I also rebuilt the project to clean up conflicts.

[rex1030]

Was the program running fine before you added these subVIs? It would follow logically that the problems lie here.

Tell us more about these VIs. Screenshots? I know with VISA read and write it can get a little tricky. Have you tried the disable diagram trick to see if your program doesn't crash without these VIs?