Labview 2011, Is this the buggiest Version ever?

[Timmar]

Re: Large VI Problem....

Code Loaded O.K. But throws a less than helpful error during deployment error.

On return shows a broken arrow with no faults found.

I am not defending the code, it is legacy and I have had plenty to say about it's architecture already.

It has given me an "opportunity" to modularise it a bit better.

The downside is that there was no room in the plan to perform this exercise.

[Timmar]

Zach, As far as disconnecting typdefs,

This is library code that is used every 2-3 weeks on a new project and is in a gradual evolution with our product.

This cluster of arrays is the heart of our "Results" and is used by our operators on a SCADA Screen.

Disconnecting the typedef is a significant pain in the rear end for long term code maintainance.

iTm

[Timmar]

In Summary:

1. Labview 2011 Crashes on Exit A Lot - At Best 1 in 5, have seen 3 out of 4 when manipulating objects. Not sure if this is better than 2010.

2. Labview 2011 Crashes A Lot when manipulating objects - Override methods seem to be major culprit.

3. Com port initialisation sensitive to order performed (Event vs Polled)

4. Named Queues have different references for the same queue (Timbo's Coding Error exacerbated by in my opinion an illogical debug tool) - Copied (Branched) Queue References have the same Reference Number

5. VX Works has an existing Bug (Or "Known Issue" if you are a spin doctor) with typdef's and Shared Variables. It is particularly bad for arrays of typdefs, there is no workaround.

6. General wierdness with handling Classes (Can't call a dynamic instance from inside a static instance... Sometimes, it depending on polymorpism depth, sometimes can't/must execute parent from within child)

[rolfk]

---

@Jed394 wrote:

---

@Timmar wrote:

Myself and 3 other collegues have just migrated to Labview 2011 SP1.

We all experience frequent crashes, I am averaging at least 10 per day,

Anyone else using it experiencing this sort of problem?

---

I'm currently on LV 2011 SP1 and ever since LV 2010 SP1, i seem to get a lot more crashes.  I will say that 2011 SP1 doesn't seem to bug out very often while working on a project, but it seems to crash ofter when i exit the development suite.  I would say that 30% of the time when i exit labview it crashes and submits and crash report to NI.

---

I only see this when working with external code. But that is not surprising if my DLLs stomp on some memory sometimes during development. But I'm not using any LVOOP yet, so can't comment on it's likelyness to cause similar issues.

[IanC_]

I've also been getting quite a number of LabVIEW 2011 SP1 crashes (though nowhere near 10 a day!).  Win7 64, 32-bit LabVIEW, RT, FPGA.

With the new error reporting in 2011, I often conscientiously fill in my email address and a good description of what caused the crash, and send the report off into the ether.  I've never heard back about any of them - am I completely wasting my time?  Has anyone ever had any feedback from this?  Are NI monitoring the results properly, or are they just overwhelmed by the many thousands of error reports they're getting?

Thanks,

Ian

[Timmar]

I gave feedback the first 5 or so crashes,

I figured that they should have got the hint by now and don't waste my time anymore.

Hopefuly this forum post will reach the fine People at NI that with a bit of luck, will sit up and take notice.

Most bug related posts that I have made have been followed up by a staff member.

iTm.

[Zach-H]

I understand the typedefs issue is a major inconvenience, its something we deal with often when supporting Real-Time applications. It is a bug we've tried to make visible and are working on. The work around is to disconnect typedefs in both the build specifications and a case by case in the properties of shared variables based on custom controls (type definitions). Annoying as it it to go through each variable it is primarily due to the fact that the shared variable engine and the application builder are separate entities. 

Could you explain the COM port initialization more in depth?

[Timmar]

Sorry Zach,

I only Just read that you are with NI,

(When you posted "I can't speak for NI" I assumed you weren't one)

Coms Problem,

My applcation is on a PXI-1051/8108 and uses Com 1 (8108) and an 8433/4 RS 485 (422) card.

I use 2 different architectures for my Comms acquisition, An event based serial capture (LVOOP) and an on-demand port read (Old school GOOP).

They both use standard port init, Bytes at port and visa read.

The catch is if I initialise the on demand version second, the event based one on the 8433 ceases to work.

COM1 on the controller doesn't seem to be affected by this, even though they share a driver.

The odd thing was, if I commented out the visa reads and writes, the problem would not go away.

It was almost as if the VISA Controls and Indicators were causing the problem. (I am ony 80% confident of this, as they were parallel threads, it appeard as a race condition, commenting out different pices of code hid/exposed the bug. After I found a workaround, I did a happy dance and moved on, I was already 2 weeks down from the RTEXE problem, I couldn't afford more than the 2 Days I had already wasted on this.

[Timmar]

My Latest Bug:

Am I Wrong to expect the following.

Code that deploys from the development environment should

a: Build to an .RTEXE

b: Run on the target.

--------------------------

I can Deploy and Run my code but

I get the following message when building

I can make it disappear by Diagram Disableing out some specific, Unbroken VI's

I know I write some rubbish code from time to time, usualy manifesting itself as a broken arrow or unexpected functionality, When there is no Broken Arrow, or successful deployment,  I don't stand a chance.

[TroyK]

Maybe you're seeing the same problem many of us are seeing when compiling:

Try this: http://digital.ni.com/public.nsf/allkb/3CC2144F391E7C9C8625764D00722173

and this: http://digital.ni.com/public.nsf/allkb/705C2ECA081F3C7986256C0F00559B02

I also have to uncheck the box "Modify Project Library file after removing unused members".

Looks like you're having a hell of time with 2011.  

I spent about a week debugging when I "upgraded" to 2011 SP1 too.