LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Fatal Internal Error

Hello,

 

I have a problem that I have never had before, and I am not sure how I go about fixing it.  

 

Labview Error.PNG

 

In my program, I have several multi column listboxes.  If I double click a line in the listbox, it asks if I'd like to delete it.  By clicking "okay", it usually deletes it.  I update the multi column listboxes using the "Item Names" property node.  However, only under a particular circumstance, the error pasted above occurs.  What I have noticed:

 

1)  It appears to always happen if I am deleting an entry from the listbox for the first time and it is the only entry in the listbox.  By first time, I mean the first time an entry has been deleted since starting the program.

 

2)  If I delete all the entries from the listbox one-by-one and get to the last entry, it does not occur.

 

3)  If I delete all the entries from a listbox one-by-one and then go to a different listbox that only has one entry, it does not occur either.

 

4)  If I am using "highlight execution" and I am under the same conditions as mentioned in 1), it does not always happen.  It appears to be an intermittent problem while using the highlight execution.  Where the problem occurs is when the "Item Names" property node is being written to.

 

5)  The first time the error did not occur during the highlight execution mode, I assumed maybe it was a timing thing.  I added a long, 5s delay along the error line and the first "Item Names" property node.  This did not help.

 

I've attached the Main VI and a sample config file.  In order to run the program, I select the instrument (34972A Keysight Scanning DMM), where to save and load the configuration file.  Each entry in the configuration file will set the monitoring conditions for a channel in the scanning DMM and log the data in its own file.  Then I click "Go" and all the channels will loaded into a multi column listbox depending on the test type.

 

This error occurs under the "Delete HTRB" event or any of the ether "Delete X" events.

 

Thanks in advance for your help, Natalie

0 Kudos
Message 1 of 9
(2,591 Views)

Oops, looks like I forgot to attach the Config file.

0 Kudos
Message 2 of 9
(2,589 Views)

Natalie,

 

     Thank you for attaching your code.  I cannot run it because there are other sub-VIs or functions that it requires that I don't have (so I have a broken Run Arrow).  I can't easily view and understand it because I don't have a 13000 x 4000 pixel super-large monitor on my laptop.

 

     At this point, it is difficult to tell if you've found a true Bug (possibly not) or are doing something not quite right.  The easiest way for you to test this is to write a very small routine that just tests the functionality that isn't working.  As you know your code best, one way to do this is to make a copy of the existing program and start "throwing away" huge chunks of it that do "everything else".  From your description, it sounds like the ListBox code is probably isolated near the beginning of the program, and sets up all the later stuff (which you don't need for testing purposes, so can delete).  As you do this, do yourself a Big Favor and compact your code, getting rid of the Wide Open Spaces.  [Do you know about the Cleanup Tool, the "Broom" at the end of the Block Diagram Toolbar?  That is supposed to help you "neaten up" your Block Diagrams.  I never use it, myself, as I like to "code neat" from the beginning, but you might find it helpful ...].

 

     If you get a small "Config List-box only" routine that still is failing, post it, along with any sub-VIs it needs, and I'll take another look.

 

Bob Schor

0 Kudos
Message 3 of 9
(2,566 Views)

Hi Bob,

 

Thanks for your reply.  I realize my code takes up a lot of screen space, and I use the cleanup tool, too.  I think it takes up so much space because I have property nodes for several list boxes as well as charts.  I wish it was smaller, too.  If it weren't for those property nodes, I think it would be much more compact...  But maybe I'm missing something.

 

I can send the other VIs if you like...  However, I'll make a copy of that code and throw out all "the other stuff".

 

Thanks, Natalie

0 Kudos
Message 4 of 9
(2,564 Views)

The "secret" to making compact Block Diagrams can be summed up in a few words -- Intelligent Use of Sub-VIs!  A LabVIEW Project with hundreds of sub-VIs, many of which adhere to the idea of "Do One Thing Well", will be much easier to understand, to maintain, to debug than a Gigunda Single LabVIEW VI.

 

Bob Schor

0 Kudos
Message 5 of 9
(2,550 Views)

Hi again Bob,

 

Thanks for calling me out on my messy code!  I learnt how to use references to controls which cleaned up my code a lot.  PLUS, that error has gone away.  I'm not sure why because I decided to clean up the code first before solving that error.  It makes me a little apprehensive because I still don't know what the problem was...

 

The only problem I am having now is that there is still a lot of extra blank space even though I've used the cleanup tool.  I checked through each event and I feel like the screen could still be a lot smaller.  It's like the tool is stretching out the loops/structures.  I've attached my code without the Sub-VIs (there's some information in some that I don't want to post publicly).  However, if you have the time and are able to do so without the Sub VIs, please let me know if you have any ideas as to why the cleanup tool isn't making my code smaller.

 

Thank again!

0 Kudos
Message 6 of 9
(2,534 Views)

A couple of points, in no necessarily-logical order:

  • The Cleanup Tool helps make totally-out-of-control Code and Wiring a bit neater.  It does try to straighten wires, group related wires together, and get rid of some white space.  I don't know the algorithm being used, but it does strike me as a "difficult problem".  I never use it on my own code -- I "start small" and try to keep wires short and horizontal, and group controls and indicators fairly tightly (I turn Icon View off for Controls and Indicators, of course, as do you).
  • Whenever you have a Structure, such as an Event, While Loop, Frame, etc. that has wires that go through it, make sure they enter and exit at the same level and put the tunnels as close to each other as you can.  This will give you lots of parallel wires, and will keep the Error Lines straighter.
  • Here's an example from one case of your Error Structure.  All I did was arrange the input and output terminals so the wires are horizontal and tightly grouped, and "hand-packed" the functions to fit.  If, in addition, I put all of the code for this case into an "Event Sub-VI" to do all the work, it would be even smaller, 32 x 32 pixels.  But wouldn't there be too many wires going into and out of the sub-VI?  No, only a few -- Error In/Error Out, and a Gigunda-Cluster of all the rest (which could be used for all the other Event Case Sub-VIs).  I know I yell about "pictures", but this is only a "concept" (I had to do a little "damage" to the rest of the code, sorry ...)

Neat Event.png 

Bob Schor

0 Kudos
Message 7 of 9
(2,520 Views)

Thanks so much for helping me out on my code.  I'm going to get working out to make it cleaner and more modular.

 

Thanks again!  Natalie

0 Kudos
Message 8 of 9
(2,502 Views)

@Bob_Schor wrote:

A couple of points, in no necessarily-logical order:

  • The Cleanup Tool helps make totally-out-of-control Code and Wiring a bit neater.  It does try to straighten wires, group related wires together, and get rid of some white space.  I don't know the algorithm being used, but it does strike me as a "difficult problem".  I never use it on my own code -- I "start small" and try to keep wires short and horizontal, and group controls and indicators fairly tightly (I turn Icon View off for Controls and Indicators, of course, as do you).
  • Whenever you have a Structure, such as an Event, While Loop, Frame, etc. that has wires that go through it, make sure they enter and exit at the same level and put the tunnels as close to each other as you can.  This will give you lots of parallel wires, and will keep the Error Lines straighter.
  • Here's an example from one case of your Error Structure.  All I did was arrange the input and output terminals so the wires are horizontal and tightly grouped, and "hand-packed" the functions to fit.  If, in addition, I put all of the code for this case into an "Event Sub-VI" to do all the work, it would be even smaller, 32 x 32 pixels.  But wouldn't there be too many wires going into and out of the sub-VI?  No, only a few -- Error In/Error Out, and a Gigunda-Cluster of all the rest (which could be used for all the other Event Case Sub-VIs).  I know I yell about "pictures", but this is only a "concept" (I had to do a little "damage" to the rest of the code, sorry ...)

Neat Event.png 

Bob Schor


LOL my litmus test is if the code looks BETTER after you use the cleanup tool, you need to re-think your coding technique.  😉

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 9 of 9
(2,496 Views)