Labview 2011, Is this the buggiest Version ever?

[Timmar]

Dilute my Post above,

I used a "Named Queue" in my create VI for the parent object,

This is why the Queues are inexcorably Linked,

Doesn't explain why the didn't have the same reference though,

I suspect that is a trade secret

Tim L.

[rolfk]

---

@Timmar wrote:

Dilute my Post above,

I used a "Named Queue" in my create VI for the parent object,

This is why the Queues are inexcorably Linked,

Doesn't explain why the didn't have the same reference though,

---

It is documented that Queues (and all the other synchronization objects like Notifiers etc.) will only create one queue, if you use the same name. To get truely individual queues you need to either create them nameless, or find a way to create a truely unique name. The good news is that queues (and the other synchronization objects) are application context local, so a queue in application context "Project X" with name "Q" will NOT be connected to another queue with the same name in applicatoin context "Project Y".

Queue refnums are like most refnums in LabVIEW internally an index into a reference table. So if I open a refnum to Queue X twice I get also two different refnums that point in fact to the same reference. This has been discussed in the past. LabVIEW does some special handling for FP objects refnums since it has proven to be a performance problem to treat every control refnum as an independant reference instance to the same control. So if you use control refnums you will see the same hex value for the same control, since the refnums are actually internally created at the time the FP is loaded and then passed around instead of creating a new refnum whenever you use for instance a property to retrieve a refnum to a control.

Refnums for IO sessions are another issue where you could end up with different hex values for the same resource. However some IO resources use some locking in the open refnum function, since it makes no sense to open two references to the same IO resource, as the underlaying communication link can not handle concurrent transmissions.

In short the hex value of a refnum tells you not really much. It's definitely not a pointer in most cases but its implementation details are private to LabVIEW, not so much because it's a top secret but because NI doesn't want to document it as that would prevent them from changing it in the future if the need should arise. I'm sure that the change to 64 Bit LabVIEW was in fact a challenge in that respect. Most refnums in LabVIEW are some 32 Bit magic value while a few are in fact more pointer like!

[Jed394]

---

@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.

[Timmar]

And yet another one for the List

A collegue of mine and I have just burnt 2 Man weeks chasing this one:

I have a shared variable that is an array of typedef'd clusters.

If I write to that shared variable from an Event structure, The built RTEXE (PXI-8108) won't launch.

The Dev deployed version works.

Will be posting this one seperately when I get the time to isolate just the code.

Combine this with a mystery where the order in which seperate serial ports are initiailised matters

I am 2 weeks behind in my project.

iTm.

[Zach-H]

The type definition problem is a known issue, #292012, with LabVIEW 2011 Real-Time Module. Its documented here. Its an issue we see fairly commonly, and R&D is aware of it. 

I'm not sure what you're referring to about serial port initialization, but if you have current SSP service, feel free to call into our support line (1-866-275-6964), and an Applications Engineer will be happy to help you with the problem.

If you don't have current SSP, I'm sure some of the enthusiasts here can help you discover what's going on as well.

It is unfortunate that you've lost so much time during development, but we do appreciate the feedback.   

[Timmar]

Zach,

Thanks for the info, This would have been great to know Weeks ago, C'est La Vie.

Our Case is a little more sinister, We always build with "Don't Disconnect Typedef's" and this particular workaround didn't help.

If it wasn't set, we would have had in excess of 20 Shared Variables with Typedef's Causing the Fault. so... Good to know.

Our Specific case was the only variable that was an array of typedef's, The Array is/was a typedef itself.

We had to disconnect the array and the Cluster itself before it would work again.

It does leave a gaping hole in my structured architecture.  If I need to add something to the cluster, I will need to go on a scavenger hunt to find all the instances where it is used (there are lots).

Any Insight to when this will be resolved?

I am guessing it missed the .SP1 Rollout by a few days.

The biggest concern is that we have recently migrated from LV10.1 to 11.1 and have lost (not gained) functionality.

It effectively makes our Development System Licence worthless since we can't execute previous version software on it.

(Another bug that I unearthed appears to limit the number of VI's that you can have on any one block diagram).

So 4 Weeks later, I am now at the same position I started at with Labview 10.1

[Zach-H]

Hey Timmar,

Just to be clear on the second work around. You can base the shared variables off of custom controls all the way up to building your application into an executable with the "Disconnect type definitions" selected. At that point you'll need to open the properties of each shared variable and select the large flashing button that says "strip from type definition." I realize this can be pain staking, but hopefully by the time you're ready to build your application into a executable to run headlessly you won't be making many changes to your type definitions.

I am not a spokesperson for the company and I can't say when a fix will actually be implement, but It looks like R&D is aiming to solve the issue for the release of LabVIEW 2012. 

There isn't a hard limit to the number of VI's on a block diagram that I know of, but there is definitely a limit to the size of a block diagram as all of the elements on it are held in memory while its open. 

That's why we highly encourage the use of subVI's in best programming practices. Does LabVIEW crash as soon as you open this large VI? Have you watched the memory usage of your computer while it tries to open the VI?  

[ErnieH]

That is quite a list of bugs. Are these going to be fixed in LabVIEW 2011? Or will we just have to live with these problems if we don't go to 2012?

[Zach-H]

I know this is a long thread, but for a summary of it there was a large discussion of LVOOP in the first two pages between four issues being mentioned. One was resolved (not a bug), one is a know issue with the LabVIEW Real-Time Module, and the other two we are still discussing. 

[ErnieH]

I am a little confused. So a know issue is not a bug? We should plan around that in our code if using 2011?