Why does indicator show uninitialized array?

[dakotasmith2]

Here is the Main.vi for my Real-Time Model Module in DQMH. This is running on a PXIe-8861 using NI RT OS.

In the INIT MODEL subVI I am initializing an array that should be a length 4 and all zeros. The size of those two channels are currently both 2 which is hardcoded inside the Settings DQMH module.

The array indicator here always shows this after it gets initialized

This is the EXECUTE MODEL subVI where in the READ FROM AI subVI I'm building the array from the INIT MODEL with the data read from the AI card. Here number of rows and counter refer to iterating through another array which was populated from reading a csv and works fine. The enabled part of the diagram disabled structures are just the tunnels wired straight across.

Here is the READ FROM AI subVI where the first part of the array is being populated with the data read from the AI card.

While the EXECUTE MODEL timed loop from the Main.vi is running, the values inside the AI and Bridge Input Raw indicator seems to be correct and nonzero. 

After the EXECUTE MODEL timed loop finishes its execution, the same indicator now shows an uninitialized array. Why does this happen?

[raphschru]

Hi dakota,

Most people responding on the forum don't have the last version of LabVIEW installed (here 24.0), so please attach your VIs saved for a previous version (preferred 21.0). To do that, go to File > Save for Previous Version... > 21.0 on your main VI.

Just by looking at the screenshots, I would say maybe your Model Data is cleared in the "Enabled" cases of your Diagram Disable Structures (DDS):

When you wrap code within a DDS, the wires are reset to their default value, so you have to manually add wires to make your data pass through.

Regards,

Raphaël.

[dakotasmith2]

Hi Raphaël,

I believe I have saved them in version 21.0 like you asked. Also, for the DDS Enabled I have just wired the tunnels straight across so I don't believe they should be receiving default values.

As for versioning, should I save all my code in 21.0 to allow for the most compatibility for everyone on the forum?

Thanks,
Dakota

[Kyle97330]

---

@dakotasmith2 wrote:

As for versioning, should I save all my code in 21.0 to allow for the most compatibility for everyone on the forum?

Thanks,
Dakota

---

I personally recommend 2019 for the version to pick.  I am on 2021, but I know some contributing forum dwellers are still on 2020 or 2019.

There are very few features that were in 2021 but not 2019 (Interface classes are the only big one I can think of) so there's a very small chance that the extra two versions of backsaving will cause problems.  

[paul_a_cardinale]

---

@Kyle97330 wrote:

---

@dakotasmith2 wrote:

As for versioning, should I save all my code in 21.0 to allow for the most compatibility for everyone on the forum?

Thanks,
Dakota

---

I personally recommend 2019 for the version to pick.  I am on 2021, but I know some contributing forum dwellers are still on 2020 or 2019.

There are very few features that were in 2021 but not 2019 (Interface classes are the only big one I can think of) so there's a very small chance that the extra two versions of backsaving will cause problems.  

---

Concatenating strings through tunnels didn't become available until 2021:

[raphschru · Accepted solution]

Hi again,

This is because your output indicators in your subVI do not receive any value when the stop condition occurs, so they are set to the data type's default value (empty array):

"Normal" case:

"Stopping" case:

Note: This is generally considered a bad practice to put control/indicator terminals assigned to the connector pane inside structures, as it can impact performance and, as you've seen, impact functionality as well. So this is better to put them in the top-level diagram of your subVI instead.

Here's a thread I found explaining why that may be a problem for performance when input control terminals are put inside a structure:

https://forums.ni.com/t5/LabVIEW/case-structure-parameter-efficiency/td-p/382516

I haven't found anything concerning output indicator terminals though, but the problem is really simple to demonstrate:

Running:

After stop:

Regards,

Raphaël.

[dakotasmith2]

Hi Raphaël,

Thank you for the response and detailed explanation! I guess I was incorrectly assuming that if the indicators are in the True case then when the False case runs, that part (True case) of the code wouldn't execute and therefore would just have the same value as before. 

This program is being built for a PXIe-8861 and I can't run it locally on my dev machine to see the block diagram and probe for values so that is why I put the indicators in the case structure. How can I probe for those same values? If I were to bring those indicators outside the case structure I'd either have to wire the tunnel out to use default if unwired or some other value than it is currently. 

Or is there some other way to probe these values? I'm basically wanting to have some "print" statement of all the values that get passed to that indicator. 

Thanks,
Dakota

[raphschru]

@dakotasmith2 wrote:

This program is being built for a PXIe-8861 and I can't run it locally on my dev machine to see the block diagram and probe for values

---

In the development environment, you can deploy and run your VIs on your RT target and access the front panels and block diagrams of your subVIs for debugging while they are running on the target... unless they are reentrant, which by limitation of LabVIEW RT, are effectively not debuggable. You can still temporarily turn them non-reentrant for debugging purpose.