Missing block diagram

[Timmar]

Ouch, Gerd, careful with the truth, it hurts

That said, source control treats VI's as binaries so every time you change something, it takes an entire copy.

@643 kB, the required storage adds up quickly.

I tend to check stuff in when the the arrows are unbroken.  This one was a bit of a ripup and took quite a while.

My stupidity aside, does anyone actually care that Labview is crashing and corrupting souce code?

I kind of thought that this is a major defect and would be a showstopper.

For an IDE, this is unforgivable.

Tim L.

[GerdW]

Hi Timmar,

does anyone actually care that Labview is crashing and corrupting souce code?

I don't experience such crashing - using mostly LV2009 and LV2011. LV2013/2014 is used very seldom, but here I also experience nearly no crashes.

Sometimes those crashes are related to the things you use in your VIs. ActiveX components? Any other 3rd party stuff? Also VIs tend to get more unstable with their filesize (which is closely related to their BD size).

All you need to keep in mind is : "save early, save often"…

And limiting SCC by available disc space is really silly (IMHO)!

[Timmar]

The only exotics I use are Classes, and lots of them.  They are all standard build within LV,.

I am pretty sure are the crash triggers, I often get a crash when I try to manipulate dynamic data members, structures or inheritance.

Everything else is bog standard.

Philisophicaly speaking, I don't believe that I should be able write (source) code that crashes the development environment,

that has to be a Labview BUG!

or am I just tilting at windmills here.

Tim L

[crossrulz]

I make a habit of checking in code every night and then updating in the morning.  Seems to work pretty well with my team.

Yes, I am concerned with bugs in LabVIEW.  If you get the promt to sent the crash report to NI, send it.  And send it every time.  NI does look at those to prioritize bug fixes.

There has been weird bugs with LVOOP for a long time.  From what I have heard, most of those bugs are fixed.  You might have hit on one of the more obscure bugs.

And be sure to tell your underlings (Mark and Chase) "hey" for me.  It was fun hanging out with them all last week.

[Timmar]

It is interesting that you suggest sending the crash report.

When I contacted NI about this family of bugs 18 months ago, I asked if they could use my crash reports to trace the problem, they didn't seem to be interested in  investigateing them. after more than 100 crash reports I gave up sending them. 

Each report takes a couple of minutes to send.

This is precious time I need back to re-load my project (3+ minutes) and survey any damage that the crash has done. and re-deploy to target (7+ minutes)

Best way I have found to find problems (they are sneaky and hide under compiled code):

1. Clear compiled object cache,

2. See which arrows break, that will pinpoint any vi's with missing front panels or block diagrams.

3. Cross fingers it wasn't a .VI that you were working on

4. Use your source control tool to re-instate the corrupted .VI to an earlier version.

Tim L

[Yamaeda]

Ofcourse my LV crashes a few times a week, if you dont crash LV you're not working. 😄

I've not had a corrupted VI due to this since LV8.2, so you must be really unlucky.

You mention 643 kb, i hope that's not 1 VI. If so, that might be a problem. A big VI for me is 200kb, usually around 30-50kb.

/Y

[Hooovahh]

---

@Yamaeda wrote:

You mention 643 kb, i hope that's not 1 VI. If so, that might be a problem. A big VI for me is 200kb, usually around 30-50kb.

/Y

---

Harddrive space is cheap, as long as it isn't MB per file being committed who cares?  Something that helps with this is using the separate compiled code.  The compiled code is a small part of the VI file but it can save some of the space taken up by commits to SCC.

[Yamaeda]

---

@Hooovahh wrote:

---

@Yamaeda wrote:

You mention 643 kb, i hope that's not 1 VI. If so, that might be a problem. A big VI for me is 200kb, usually around 30-50kb.

/Y

---

Harddrive space is cheap, as long as it isn't MB per file being committed who cares?  Something that helps with this is using the separate compiled code.  The compiled code is a small part of the VI file but it can save some of the space taken up by commits to SCC.

---

Yes, HDDs are cheap, that's not the point and i assume the end code will be about the same size regardless, but big VI's has been problematic before, that's the point i was getting at.

/Y

[Timmar]

I agree, big VI's are a problem.

In LV 12 this VI would show broken arrow without an error message.

All I would have to do was add a control and then delete it and it would all work fine after that.

Seems to be fixed in LV 13 though.

VI has 100's of controls and lots of graphical elements - it is A SCADA for industrial application.

Part of my lost work was stripping it down an putting functionality into modules, in an attempt to reduce the code.

Unfortunaltely when you are dealing with front panel items they are difficult to manage them inside a sub.VI

More specificaly, you need to handle them as references and the code becomes quite obfusicated.

I am planning to go to xcontrols to simplify but I have been warned off them as historicaly they are prone to bugs, crashing and unexpected CPU usage.

P.S. they are a great solution concept.

[Timmar]

Hooovah,

I am working in a real-time environment and last time I separated compiled code from VI's (LV11), I couldn't run the built .RTEXE's.

Unchecked the box, and Hey Presto, it worked again.

I have wanted to try again but as with all things labview, these trials cost time and the rewards aren't tangeable