Are there limits to the number of cases, etc?

[twinsemi]

My vi needs two more inputs. I have it currently working with six Modbus connected oxygen analyzers (4 channels each) and when I do a Duplicate Case on the sixth analyzer monitor in my stacked sequence, I can't save the vi. The message is not very helpful. "LAbVIEW.exe has encountered a problem and needs to close. We are sorry for the inconvenience." Below that it reads, "If you were in the middle of something, the information you were working on might be lost." When this happenned the first time, I moved development over to an XP machine from my Vista OS computer. (which had 8 GB RAM) I did a bunch of other cleanup tasks, got back to adding the seventh and eighth analyzer monitor sequences and got stomped by the crash again.

LabView 8.0

60 GB HD, 42 GB available

Windows XP Pro, Service Pack 3

Intel 1.83 GHz

1 GB RAM

vi size = 2.8 MB

The communication setup is common for all of the Modbus devices. Inside the stacked sequence there is a MB Serial Master Query.vi for each analyzer, a whole bunch of indicators (27 for each analyzer) and a few case structures.

Anybody seen this before?

[bbystrek]

Certainly you're not hitting any case structure limits. I've seen several hundred implemented. I'd suspect though, that you might be restricted to the possible values that you can set the I32 selector value to. Not sure how this would apply to other data types like strings or enums driving the structure.

My reason for posting - From years of experience with LabVIEW over the years, depending on what resources your program is using, it's usually wise to re-boot after a crash. At least once you understand what's going on. Just don't necessarily expect everything to run right just because LabVIEW reopens.

Troubleshooting full crashes can frequently be cumbersome. When they are repeatable, as your instance appears to be, you might have a very careful look at what your doing. Sometimes someone experienced can detect what you could be doing wrong by simply observing.

You might also consider the impact of inappropriately stopping your code with the red stop button while debugging. Many times your code will leave a variety of resources hanging because the various closes and releases didn't get called. Sometimes this can make consecutive runs misbehave or produce unexpected behaviors.

[Mark Yedinak]

You might want to consider modularizing your code and rather than copying frames of a stacked sequence (which stacked sequences in general are not recommended) turn the code of the frame into a subVI that you can pass in parameters to. Your program would be easier to extend. You may also consider bundling your indicators into clusters. If all of these indicators are visible I can't image that your user interface is very readable or easy to understand. Not to be harsh but your code sounds like it could use some major rearchitecting. The sheer number of indicators and the complexity of each sequence frame may be contributing to your crashes.

[Grampa_of_Oliva_n_Eden]

QUOTE (twinsemi @ Apr 14 2009, 08:34 PM)

My vi needs two more inputs. I have it currently working with six Modbus connected oxygen analyzers (4 channels each) and when I do a Duplicate Case on the sixth analyzer monitor in my stacked sequence, I can't save the vi. The message is not very helpful. "LAbVIEW.exe has encountered a problem and needs to close. We are sorry for the inconvenience." Below that it reads, "If you were in the middle of something, the information you were working on might be lost." When this happenned the first time, I moved development over to an XP machine from my Vista OS computer. (which had 8 GB RAM) I did a bunch of other cleanup tasks, got back to adding the seventh and eighth analyzer monitor sequences and got stomped by the crash again.

LabView 8.0

60 GB HD, 42 GB available

Windows XP Pro, Service Pack 3

Intel 1.83 GHz

1 GB RAM

vi size = 2.8 MB

The communication setup is common for all of the Modbus devices. Inside the stacked sequence there is a MB Serial Master Query.vi for each analyzer, a whole bunch of indicators (27 for each analyzer) and a few case structures.

Anybody seen this before?

THe only thing close to that should not hit you LV 8. In pre-LV 7 you were limited to less than 550 controls on the FP. Do you have any idea how many you have now (both hidden and shown) ?

Ben

[bbystrek]

Have you tried, from a fresh Windows boot, just opening your code and trying to make your changes without ever running the code? If your code has a bug that's running your computer nearly out of memory, odd things might happen. Of course you can have a look at available memory using Window's task manager (from ctrl-alt-delete options).

Another last-ditch effort that I can think of - you might try a forced recompile to fix anything that might be corrupt. From what I've been told by NI, LabVIEW ordinary only incrementally recompiles sections of the diagram as you make changes. A forced recompile rebuilds all VIs in memory. You might want to make a complete backup copy of your code first. What you do is hold down the shift and ctrl keys and then click on the run button (perhaps should be done at the highest level VI). All VIs will want to be saved after this process completes. There's no dialog of any kind, just when the hourglass goes away, all VIs will show the asterisk in their title bars indicating that there are pending changes to be saved. If you have dynamically called VIs involved, you would have to open each dynamically called VI and do the same. I don't really know how often this sort of problem arises, but NI has directed me to try it on a couple of troubleshoots over the years. Both instances turned out to be something else, but it was another bit of wisdom to try.

[twinsemi]

Thanks for the comments, all. I was out of the office yesterday, so today am back at it. Here is a new bit of info. The crash upon saving was after the edit. It can not run this way either. When I run the vi after adding the seventh monitor frame to the sequence, the error message comes up as follows:

Insane object at BDHP+534EDC in "OxiFTE 5003.vi"; {graphics } (0x80); Label (COSM)

Upon closing the dialog box, I get a series of about 40 nearly identical ones, just slightly different addresses for the insane object. The vi continues to run after that. The seventh analyzer monitor subpanel displays on the monitor tab and all of its indicators work normally. I was able to save the vi under a new name, but the next time it ran, LabVIEW crashed with a fatal error. (not the same insane message) Now it can't be saved even when it is freshly loaded.

As to your suggestions:

- I have tried about every combination of fresh boots and edits and running things.

- As to memory limitations in Windows, this was happening identically in my 8 GB machine, and in the XP unit, it is using 483 MB while running the vi.

- As to modularizing, yes that would be one way to try to get around this, and it is a consideration. However, it may not be the most time efficient way. With the addition of these last two frames to the sequence, this version should be going out the door. I may not be able to convince our customer that the extra time to recode is acceptable. (of course it may be my only option if no other solution makes it.

- I don't use the toolbar stop button, since there is a big red one coded into my main loop.

- Doing the forced recompile produces the same result. (original posted error message)

- Number of controls in the whole vi is 65. No controls are in the troubled portion of code, only indicators. (the controls are on different pages and the monitor function is suspended when the operator uses controls.)

- Not sure what the I32 selector values are that you are refering to, bbystrek.

[Mark Smith]

QUOTE (twinsemi @ Apr 16 2009, 09:32 AM)

Thanks for the comments, all. I was out of the office yesterday, so today am back at it. Here is a new bit of info. The crash upon saving was after the edit. It can not run this way either. When I run the vi after adding the seventh monitor frame to the sequence, the error message comes up as follows:

Insane object at BDHP+534EDC in "OxiFTE 5003.vi"; {graphics } (0x80); Label (COSM)

Upon closing the dialog box, I get a series of about 40 nearly identical ones, just slightly different addresses for the insane object. The vi continues to run after that. The seventh analyzer monitor subpanel displays on the monitor tab and all of its indicators work normally. I was able to save the vi under a new name, but the next time it ran, LabVIEW crashed with a fatal error. (not the same insane message) Now it can't be saved even when it is freshly loaded.

As to your suggestions:

- I have tried about every combination of fresh boots and edits and running things.

- As to memory limitations in Windows, this was happening identically in my 8 GB machine, and in the XP unit, it is using 483 MB while running the vi.

- As to modularizing, yes that would be one way to try to get around this, and it is a consideration. However, it may not be the most time efficient way. With the addition of these last two frames to the sequence, this version should be going out the door. I may not be able to convince our customer that the extra time to recode is acceptable. (of course it may be my only option if no other solution makes it.

- I don't use the toolbar stop button, since there is a big red one coded into my main loop.

- Doing the forced recompile produces the same result. (original posted error message)

- Number of controls in the whole vi is 65. No controls are in the troubled portion of code, only indicators. (the controls are on different pages and the monitor function is suspended when the operator uses controls.)

- Not sure what the I32 selector values are that you are refering to, bbystrek.

I have found one of the only ways to get rid of insane object errors is basically throw away the problem VI and start over - this isn't quite as bad as it sounds - just open a new VI and start copying parts from the old block diagram one section at a time. Save after every copy operation. After a while, you may copy something that gives the insane object error. At that point, throw away that section of code and start rewiring everything in it from the function palette. Then try saving again. If that works, start copying again. Rinse and repeat until the entire VI compiles and saves correctly. Time consuming but it works since there's something in the original source that just won't run correctly and LabVIEW just can't identify it and flag it at compile time so you can't find it and take it out without a trial and error process like this.

Mark

[Jolt]

QUOTE (mesmith @ Apr 16 2009, 11:57 AM)

I have found one of the only ways to get rid of insane object errors is basically throw away the problem VI and start over - this isn't quite as bad as it sounds - just open a new VI and start copying parts from the old block diagram one section at a time. Save after every copy operation. After a while, you may copy something that gives the insane object error. At that point, throw away that section of code and start rewiring everything in it from the function palette. Then try saving again. If that works, start copying again. Rinse and repeat until the entire VI compiles and saves correctly. Time consuming but it works since there's something in the original source that just won't run correctly and LabVIEW just can't identify it and flag it at compile time so you can't find it and take it out without a trial and error process like this.

Mark

If you have to rebuild anyway I would reconsider the suggestion to move away from stacked sequences - even if you don't have to rebuild getting rid of sequences is a great exercise and good programing practice anyway... Try State Machines!

[crelf]

QUOTE (twinsemi @ Apr 16 2009, 11:32 AM)

When I run the vi after adding the seventh monitor frame to the sequence, the error message comes up as follows:

Insane object at BDHP+534EDC in "OxiFTE 5003.vi"; {graphics } (0x80); Label (COSM)

Upon closing the dialog box, I get a series of about 40 nearly identical ones, just slightly different addresses for the insane object...

You totally need to use the http://wiki.lavag.org/Insane_Objects' rel='nofollow' target="_blank">peak heap function. Everytime I've gotten an insane object, peak heap has been my saviour :worship:

[twinsemi]

I believe that I have found the problem. Insane in this case is caused by a creation of a property node (in the duplicated frame) without an associated indicator. The indicator is in a different frame of the sequence where its visibility is controlled. After making the new frame with the unasigned property node, if I right click and select Find Terminal, nothing happens, since it doesn't get created. It is confusing because the indicator appears on the front panel. But it only gets duplicated because it is withing a tab control that duplicates it there. If I had gone on to make all of the needed changes before saving or running the vi, I probably wouldn't have seen this.

[bbystrek]

QUOTE (mesmith @ Apr 16 2009, 11:57 AM)

I have found one of the only ways to get rid of insane object errors is basically throw away the problem VI and start over - this isn't quite as bad as it sounds - just open a new VI and start copying parts from the old block diagram one section at a time. Save after every copy operation. After a while, you may copy something that gives the insane object error. At that point, throw away that section of code and start rewiring everything in it from the function palette. Then try saving again. If that works, start copying again. Rinse and repeat until the entire VI compiles and saves correctly. Time consuming but it works since there's something in the original source that just won't run correctly and LabVIEW just can't identify it and flag it at compile time so you can't find it and take it out without a trial and error process like this.

Mark

I had forgotten about this bit of tribal knowledge. I hadn't noticed it earlier, but you have your primary LV version listed as 7.1.1 - this sort of thing did happen once in a while back then. I've seen it either two or three times myself over the years, and once each with two different coworkers, all of us building different applications. In all cases if I'm remembering it right now, it was the insane error that arises or the VI simply refuses to let you save. The fixed had worked every time. We originally learned about it from NI. It was caused by some sort of corruption. Just as Mark says, all you have to do is copy the code into the diagram of a new VI. His suggestion to isolate should be definitive if a full cut and paste still creates the error.

[Mark Yedinak]

I would agree with Jolt though that if you need to recreate the VI you should give serious consideration to rearchitecting it. The overall description of your VI does not sound like a very robust design and it certainly doesn't sound like it is very easy to extend. While you might say that it is not worth the time to fix it now you may find that maintenance over the the life of the application will be difficult and time consuming. If I ever have to go back into old code that is poorly designed to change something I generally will spend a little extra time to clean things up. This sounds like it might be a good oportunity to do that with your code.

[bbystrek]

QUOTE (twinsemi @ Apr 16 2009, 01:37 PM)

I believe that I have found the problem. Insane in this case is caused by a creation of a property node (in the duplicated frame) without an associated indicator. The indicator is in a different frame of the sequence where its visibility is controlled. After making the new frame with the unasigned property node, if I right click and select Find Terminal, nothing happens, since it doesn't get created. It is confusing because the indicator appears on the front panel. But it only gets duplicated because it is withing a tab control that duplicates it there. If I had gone on to make all of the needed changes before saving or running the vi, I probably wouldn't have seen this.

Could be the cause by touching on some sort of a bug, but you can't "create" the insane error intentionally no matter what you do under normal circumstances, you can only make your code broken (not capable of running). If you're fix turns out to work, I'm glad. This is one of the more painful type of LV problems to troubleshoot. I once had a random crash on the order of a few times a week - turned out to be an NI supplied VI accessing a DLL failed to specify a dimension for an output value. Many hours and lost on that one.

[asbo]

QUOTE (crelf @ Apr 16 2009, 01:09 PM)

You totally need to use the http://wiki.lavag.org/Insane_Objects' rel='nofollow' target="_blank">peak heap function. Everytime I've gotten an insane object, peak heap has been my saviour :worship:

Oooooh, very cool. :thumbup:

[twinsemi]

As to my version, it is my profile that is old, since I haven't updated it lately. Version currently is 8.0.

As to the restructuring and extensibility, the code that I have WAS scalable up to a little while ago. A change to it where I moved some items into a different frame of the sequence caused this problem. I had a difficult time catching it because LabVIEW created the appearance of a slider indicator (after duplicating the frame with the tab) when it didn't actually put into the diagram. I have now restored my code structure to have all of the pertinent sliders in the sequence where they are primarily used. It multiplies like a rabbit now. All of my variable names are nicely incremented and the world is a beautiful place again.

Thank you all for your help. I don't think I would have found it without.