Module Synchronization Issue

[adkin]

I'm experiencing a confusing synchronization issue when starting up a second instance of a cloneable module.

When I first open the project and run the API Tester everything works fine. I'm able to run as many instances as I'd like they start and stop as expected. However, if I save the Main.VI of the module I'm testing (or working on), when I start the API Tester to re-test, I can only open a single instance of the module without error. When I try to open a second instance, after the configured timeout, I receive the following error:

Using a breakpoint on the Module Admin wire in Main.VI immediately upon startup, I've determined that the second instance does not start when Start Module is called - I've probed around and have no idea why, everything looks right to me until the error thrown by Wait on Module Sync which makes sense if the module didn't actually start. The breakpoint is only hit once I call Stop Module on the first instance.

Only after closing the API Tester and all open windows does everything return to normal. Sometimes I need to close and reopen the whole project to fix the issue. I've also tried wiring a TRUE constant to the Close Master Reference in the Main.VI to see if it changed anything, but it was the same.

If anyone else has experienced this, please let me know if you figured out how to eliminate it or have any insight about what is causing it. If there's any more information that would help narrow it down just let me know.

Thanks

Aaron

[shuttlefan]

does your clones stay alive?  
if not, are you closing them down properly?
How does your other modules know a new clone has started?

[adkin]

---

@shuttlefan wrote:

does your clones stay alive?  
if not, are you closing them down properly?

---

Clones are shutting down properly until this issue shows up. Everything closes, I receive all of the expected status updates and the library isn't locked indicating that everything closed as expected. Once it happens, only the first clone closes if I send the Stop request to all modules. It always appears that there is only a single clone running - which is probably true since it doesn't start until I stop the first one. Once the first one is closed, I can refresh the Module ID Ring and take control of the second instance, then the third etc. But it appears as if there is only a single clone running at any one time.

If I fire the Panel Close event from the API Tester, only the "active" clone is closed. Because the next clone in line seems to start as soon as the previously active one stops, the API Tester stops, but the library is locked. I can restart the API Tester and stop any remaining clones one by one, but never all at once.

It's as if each clone that was asked to start is queued up waiting for the previous one to stop first.

---

@shuttlefan wrote:
How does your other modules know a new clone has started?

---

At the moment I only have this single module and the Tester, so the only place I'm concerned with knowing about new clones starting is in the Tester via the Module ID Ring and status updates.

[FabiolaDelaCueva]

DQMH modules guarantee these three things right out of the box:

1. They start when you tell them to start
2. They stop when you tell them to stop
3. They report errors

If at any time any module stops doing one of these three things reliably, it is time to retrace your steps and see what was the last change you did to the code that introduced the new behavior. Using source code control for this is great because you can always go to the latest working version of your code.

That said, there have been corner cases that we have fixed in the past. Is there a simplified version of your clone that you could share with us that reproduces the behavior you are seeing?

Thanks,

Fab

[adkin]

I've attached a completely stripped down version saved as LV2020 that still exhibits the same behaviour.

Steps to reproduce:

1. Open project
2. Open API Tester and run
3. Start a few clones to demonstrate correct functionality
4. Stop API Tester
5. Open Module Main.VI
6. Save and close Module Main.VI
7. Run API Tester
8. The first clone should start normally, subsequent clones should throw a sync error (timeout is only 1000ms so I could test faster)

I'm running on Windows 10 with the most recent version of LabVIEW. At this point it seems to me like the Start Asynchronous Call VI is queueing up the next clone to call but isn't actually calling it until the previous one is finished executing. But I have no idea why that would be happening. Let me know if you're able to reproduce or not.

Thanks for your help,

Aaron

[adkin · Accepted solution]

Finally figured out what is causing it!

Started working on my next module and have been extremely cognizant of every small change and using the API Tester to confirm if this happens again. It turns out it has something to do with the new Save Version setting in the Project properties. When I leave the option as "Editor Version" or "24.0" everything works fine and I can't replicate the bug. Once it's set back to any earlier version, it becomes reproducible again until set back to the current editor version. I actually need this feature for collaboration, so I guess I'll just have to live with it.

Since this seems like a LabVIEW bug and not related to me or DQMH, I don't really know how to get it fixed.

Thanks for the help Fab. Ultimately it was just

... retrace your steps and see what was the last change you did to the code that introduced the new behavior.

---

that solved it.

Thanks,

Aaron

[Darren]

I was able to reproduce this issue where Project Save Version was affecting the execution of Start Asynchronous Call. I have filed Bug 2979528 to LabVIEW R&D to investigate the issue further.

[FabiolaDelaCueva]

Glad to be of service 😉

Fab

[adkin]

---

@Darren wrote:

I was able to reproduce this issue where Project Save Version was affecting the execution of Start Asynchronous Call. I have filed Bug 2979528 to LabVIEW R&D to investigate the issue further.

---

Glad to hear it's not just me!

Thanks,

Aaron