fixing corrupt vi

[tfd]

I saved a vi with > 555 front panel objects, so Labview crashed - nothing new. However, this time it won't open the vi at all. (load.cpp - line 4835)

Previously, if I stepped over the limit, LV6.1 crashed, but later opened my vi having the last changes before I added an xtra object.

The vi is corrupted now, so how do I fix it?
Is there any place in LV6.1 where you can instantly get the current # of objects on the front panel?

I'm using DS linked objects, so I can't cluster them.

[Dennis_Knutson]

NI is the only place that you could possibly get the VI fixed so you should contact tech support and send them the VI. You could also try restoring from a backup (you have been making regular backups haven't you). However, I think you'll have to greatly reduce the number of objects on your fron panel. I don't understand your comment about not being able to use clusters. Datasocket can read and write to clusters.

[tfd]

I use very few of the objects in code. Most are just used to display data such as error conditions. All of the objects are individually linked to a plc using opc. Once an indicator is in a cluster, it cannot be linked on the front panel to datasocket, only the cluster can. This plc doesn't allow retrieval of clusters of tags, only 1 tag at a time.

The size is because of the amount of info to display. We already have 4 screens close to the 555 limit. Tabsheets and graphics are used to make it easier to follow.

Thanks

[modicon]

tfd wrote in message news:<50650000000500000009F50000-1042324653000@exchange.ni.com>...
> I use very few of the objects in code. Most are just used to display
> data such as error conditions. All of the objects are individually
> linked to a plc using opc. Once an indicator is in a cluster, it
> cannot be linked on the front panel to datasocket, only the cluster
> can. This plc doesn't allow retrieval of clusters of tags, only 1 tag
> at a time.
>
> The size is because of the amount of info to display. We already have
> 4 screens close to the 555 limit. Tabsheets and graphics are used to
> make it easier to follow.
>
> Thanks

I've corrupted a few myself with too-busy front panels. You may hafta
break up your app into a data coll
ection loop (where the ActiveX or
datasockets bring in the stuff into a local array) and a display loop
(where the array is parceled out into the clusters of indicators on
the front panel). I've got an app that reads 300+ items from 2 PLCs
into 3 clusters. The devil is in the details of the layout: making the
labels for each of the indicators show which array number it
references. I hide the ugly details by doing it all for each cluster
in its own subvi, passing in the data array and a reference to its
cluster.

By the way, my dataloop sends a notification every time it finishes
another list of items (the notifier being a string with the date and
time). Inside the display loop is a Wait On Notification with a 100ms
timeout. The actual display updating occurs only if TimeOut is False
on the notifier. The error output of the Wait On Notification is
wired right to the While loop stop condition. When a user hits the
application Stop button, it stops the Dataloop. Outside the dataloo
p
I kill the Notifier and this cleanly kills the display loop...no
locals or display loop timers needed.

[Randy_H]

Would you like to upgrade to LabVIEW 7.0? The 555 control limit is not present in LabVIEW 7.0 and you should be able to use your VI there.

Randy Hoskin
Applications Engineer
National Instruments
http://www.ni.com/ask

[tfd]

No thanks. Labview is too expensive to risk money and time on. If you look at what you get for your money its a shame.
- Sorry for the negativity, im a line programmer - 🙂