Why does this work in Labview 8.6 but not 2013?

[altenbach]

---

@Norbert_B wrote:

Hm, the big difference is that the for-loop approach uses a SINGLE CLFN for three calls which are configured to be "dynamic" (path input).

---

Well, I still think the problem is with NI (bug?), since it actually workd in earlier versions.

If anything, running in the UI thread (as they currently do) should be safer. I would expect fewer problems.

I sometimes use dynamic CLFNs in loops and never had issues. 

[josed12b]

The dll is thread safe according to the developer. I've tried "run in any thread" and I get the same result. 

No special attach/dethach code exists in the DLL.

I've added shift registers to all the signals that dont need indexing and i still get the same result.

[JÞB]

---

@crossrulz wrote:

---

@JÞB wrote:

I might be insane but try replacing the path tunnels with a Shift register.

---

Yes, Jeff, you are insane.  But that has nothing to do with LabVIEW.

I fully agree that you should be using shift registers for the fields that need passed through as well as the error cluster.  But I don't see anything here that would cause issues.

---

Funny Tim.

I noticed that the path in the config page was not the same as the path on the BD.  With some of the magic that LabVIEW uses to locate DLLs by path or by name I thought this could be a candidate for the difference and it still might be since LabVIEW stores the relative path internally (Acording to prophesy).  The code "Should" work as it is unless that path magic is really not quite as magical as we would think.  

Try another quick test with the full path in the BD constant.

And another, without the path terminals at all.  This might be "Expected" behavior (To unload the DLL) when, in theory the path could change between iterations.

[altenbach]

---

@JÞB wrote:

I noticed that the path in the config page was not the same as the path on the BD. 

---

According to the help. the internal path is ignored when an external path is configured, so that should not make a difference:

"When you place a checkmark in the checkbox, any library referenced in the Library name or path control will not be used."

[Yamaeda]

The type casted string isn't the same in the unrolled version, could that be a factor?

/Y

[altenbach]

The later attached actual VI has an empty string in both cases.

[crossrulz]

---

@josed12b wrote:

The dll is thread safe according to the developer. I've tried "run in any thread" and I get the same result. 

No special attach/dethach code exists in the DLL.

I've added shift registers to all the signals that dont need indexing and i still get the same result.

---

Have you tried removing the path consants and unchecking the "specify path on block diagram"?

[Darin.K]

Double check the calling convention specified in the CLFN.  In older versions LV would automagically correct incorrect settings here, starting in LV10 or so, it can no longer do that.

I usally see crashes with incorrect calling convention, but it is definitely something that has changed between then and now.