High-Speed Digitizers

cancel
Showing results for 
Search instead for 
Did you mean: 

Fatal Error in drawmgr.cpp line 34999 or 3497

Hi,

I have been struggling to complete a relatively simple LabVIEW project.

The biggest problem I have been having is getting the size of the 3D graph on the target system set to the desired size.

I have spent several weeks and many e-mails trying to understand how to do this and why it is so very difficult to do such a simple thing but I still have not been able to get it right (see Jeremy Braden there at NI customer support for some of the history).

This has been frustrating and in the process I have not been able to complete other areas of the project including long term testing. �In doing some of this testing recently with a few different versions (different size 3D graph and different methods of accumulating the 3D graph data) I find that the system crashes after running a fairly short time of 1-3 hours.� This system needs to be reliable as it will be going into a museum for many people to see and play with.

Sometimes the program just freezes and gives no error message, most of the time when I stop the program I get the message:

Fatal Internal Error: "drawmgr.cpp", line 3499 LabVIEW version 7.0 you will lose any unsaved work.
For assistance in resolving this problem, please relaunch LabVIEW, or contact National

(Sometimes I see line 3497 on my XP machine - the target is Win2000)

Can you please help me resolve this problem?

I consider this a more important issue than getting the size of the 3D graph right as I can live with the graph being small but not with the system crashing (especially often).

Although, I would really like to understand why it is so very difficult to set the size of the 3D graph and how to overcome this problem.� Can you assist me with this a bit further?� The display works fine on the development system but when I build the application and run it on the target system the 3D graph shrinks. It does this on the two target system that I have tested so far. �This leads me to believe that there may be an issue with the install on the development system. �So far I find the best way to do this is to make the size of the graph on the development system oversize to compensate for the shrink that occurs on the target system.� I have also tried setting the size programmatically (as suggested by Jeremy) which sets the size nicely but causes the system to run slow once the size is set (it slows down to ~1 update per second from ~20/sec). As it has been difficult to debug the problem via e-mail, perhaps I could get someone in the local area to help ? either by stopping by here or I could bring the setup some place local.� I am willing to pay for the consulting as I need to get this project completed soon.

Thanks,
-Dan
0 Kudos
Message 1 of 8
(8,661 Views)
Due to your time constaints, I suggest you contact your local NI Sales Engineer to see if they can help or if they can recomend an Alliance Member in your area.

You have mentioned a number of diferent issues. The crashes are the most troubling.

I would venture a guess that memory size may be an issue with the update rate, but I am only guessing.

Just trying to help,

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 2 of 8
(8,661 Views)
Thanks Ben,
I am working with NI support and my local sales rep.
In addition I have spent the weekend understanding the problem more. I have narrowed it down to a memory leak in CWPlot3D- Plot3DSimpleSurface function. It leaks ~2K bytes per call. My system starts with ~127Meg in use and grows at ~1Meg per minute until crashing when ~151Meg in use after 28 minutes (the system has 256Meg memory).
Any experence with memory leaks in LabView 7?

Thanks,
-Dan
0 Kudos
Message 3 of 8
(8,661 Views)
If you post an example (in LV 6.1) I will take a look.

Is there a possibility you are not clearing old data?

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 8
(8,661 Views)
Here is my stripped down version. This is set up for LabView 7.0 but may work in 6.1 after I converted the 3D Surface object to the basic call. You will also need a 5102 or simular scope card and an input on the trigger (~10 - 100 pulses per sec will do).
The problem is in the 3D graph call.... if I substitute a 2D graph for the 3D graph it runs all night just fine - otherwise it crashes in less than 1/2 hour!

Thanks for your help,
-Dan
0 Kudos
Message 5 of 8
(8,661 Views)
Sorry dkrent but I am still running LV 6.1.

I still have about a month of work left on a major project that I started before LV 7 was released.

Do a save for previous version and repost if you want me to look.

Otherwise maybe someone can look at your example.

Have you tried sending your stripped down example to NI support?

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 8
(8,661 Views)
Hi Ben,

The problem has been narrowed down...
Thanks to Dirk De Mol at the NI office in Mtn. View CA. The memory leak occurs when you use Cursors on the 3D Graph. These leak memory (and objects). Evidently Cursors create new objects for each call and do not clean up. Dirk says he has filed a bug report.

The work around is Do Not Use Cursors!

I do not know if 6.1 has the same problem (you may want to check if you use 3D graphs) - but I understand it is still in the next release as of this date (tested by Dirk).

Thanks for your thoughts,
-Dan
0 Kudos
Message 7 of 8
(8,661 Views)
Congratulations!

When you first posted your questions you sounded pretty despirate. I hope the rest works out for you.

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 8 of 8
(8,661 Views)