Play Sound File triggered by notifier breaks after 21 days

[ProbablyPete]

Hello,

I'm away from my workstation today but will work up example code of my problem tomorrow morning.

I have an application that plays .wav files as a siren (alarm) sound. There's a start, looping middle, and ending file. I'm using "Play Sound File" in a flat sequence with a loop in the middle frame so that the repeating middle part can loop indefinitely. At each stage of the sequence, I wait on notifier to see if the siren should stop and clear the sound task.

The whole sequence sits inside a loop with a wait on notifier at -1 timeout so that the siren "engine" idles until notified to start.

This code is built as an exe and run from a TPC-2230 which runs 24/7. My problem is that after about 3 weeks, the siren part of the code begins to hang. As in, it won't even start playing the first bit of the sound file. This is after being idle, not after looping for extended duration.

Due to the nature of the application and a series of comical mis-steps, I have not been able to get "remote debugging" active on the machine so that I can see the wires while it is hanging. Are there any known issues with the way "Play Sound File" or the other sound output VIs work (lvsound2) that could explain what I'm experiencing?

[billko]

---

@ProbablyPete wrote:

Hello,

I'm away from my workstation today but will work up example code of my problem tomorrow morning.

I have an application that plays .wav files as a siren (alarm) sound. There's a start, looping middle, and ending file. I'm using "Play Sound File" in a flat sequence with a loop in the middle frame so that the repeating middle part can loop indefinitely. At each stage of the sequence, I wait on notifier to see if the siren should stop and clear the sound task.

The whole sequence sits inside a loop with a wait on notifier at -1 timeout so that the siren "engine" idles until notified to start.

This code is built as an exe and run from a TPC-2230 which runs 24/7. My problem is that after about 3 weeks, the siren part of the code begins to hang. As in, it won't even start playing the first bit of the sound file. This is after being idle, not after looping for extended duration.

Due to the nature of the application and a series of comical mis-steps, I have not been able to get "remote debugging" active on the machine so that I can see the wires while it is hanging. Are there any known issues with the way "Play Sound File" or the other sound output VIs work (lvsound2) that could explain what I'm experiencing?

---

Just from the description of your code, I can imagine several different things being wrong, all of them related to the code, not any perceived "bug" in LabVIEW.  We await your stripped-down VI.

[ProbablyPete]

@billko If there's an obvious different way that I should be approaching it, please point me in the right direction. My plan right now is to abandon the "looping wav file" and just "Sound Output Write" some waveform data to make the alarm sound. I'll upload snippets for both implementations tomorrow.

[billko]

---

@ProbablyPete wrote:

@billko If there's an obvious different way that I should be approaching it, please point me in the right direction. My plan right now is to abandon the "looping wav file" and just "Sound Output Write" some waveform data to make the alarm sound. I'll upload snippets for both implementations tomorrow.

---

I can't really offer any suggestions without first opening the VI you will be providing.  I only have LV 2018 on my computer, so it would be helpful if you could "Save for previous" and save it as LV 2018.  Sorry, and thanks.

[RTSLVU]

We need to see your code but by your description:

@ProbablyPete wrote:

.I'm using "Play Sound File" in a flat sequence with a loop in the middle frame so that the repeating middle part can loop indefinitely. At each stage of the sequence,

---

I would say you have some program architecture issues...

IMHO: The Sequence structure (flat or stacked) should only be used in a few very limited cases and this is probably not one of them..

[JÞB]

Running 24/7/365 is rather insane for a Windows OS. 

Did the millisecond timer rollover? Use Hi res timer

Did the loop run I32 times and stop incrementing?  Use a U64 shift register counter.

Show code!

[ProbablyPete]

@JÞB Will upload code tomorrow but thanks for making me think about some more things. 

Obviously I am not very experienced here, but do LabVIEW while loops stop when the counter rolls over? The loop shouldn't have gotten that high because most of the time it sits on an idle "Wait on Notifier". The counter isn't wired to anything so if it rolls over it doesn't matter to me.

The machine in question is one of NI's own TPC-2230's which ships with a pretty stripped down Win7 build. As-deployed, we're going to expect it to run for about a year at a time, it will be shut down and stored for a few months and then deployed again. 

I do have some additional things to think about regarding the machine/Windows. Since the TPC-2230 doesn't have an internal sound card, I'm using a USB speaker. Does LabVIEW notice if the USB speaker momentarily disconnects itself? Is there a way to re-identify sound devices if something like that were to happen?

[RTSLVU]

---

@JÞB wrote:

Running 24/7/365 is rather insane for a Windows OS. 

---

Honestly it's not that bad. I have had several long term tests throughout the years that have ran 24/7 for years at a time. Only being shut down once a year for calibration. I have done this this on Windows 95, 2000, 7 and 10 without issues.

[JÞB]

Windows will default to the "allow computer to shut down..." the USB hub manager.  You can use the device manager to deselect that setting under the USB hub controller power management tab.

The I terminal of any loop will stop incrementing at 2^16-1 & continue to output 2^16-1 forever for each > 2^16-1 iterations. That is just as big as an I32 can get.  It does not roll over to 0x00 (-2^16)

I too have used a non-determinisic OS to run 24/7/365.  I was insane at the time.  I cannot speak for others

[tst]

---

@ProbablyPete wrote:

Due to the nature of the application and a series of comical mis-steps, I have not been able to get "remote debugging" active on the machine so that I can see the wires while it is hanging. Are there any known issues with the way "Play Sound File" or the other sound output VIs work (lvsound2) that could explain what I'm experiencing?

---

I don't know about anything specific. I have places where I believe it works okay over longer periods of time, but I have actually checked how long they run.

My recommendation would be to add logging to the application. Log the progress. Log errors. Basically, whatever you can think of which could help figure out exactly what's going on. Is it calling the play VI and hanging inside? Is it calling it and returning an error? Is it not even calling it because there's an issue with a notifier? And so on. Since it takes three weeks to see, you would want to think of as many options in advance. Better to log too much than too little, but you also want to make sure you don't log so much that the file is too big or something.

Without any more details, my guess would be that maybe you're opening many references to your notifier and not releasing them. I believe LV has a 20 bit limit (~1M) on the number of references (I think this is separate for each reference type), but I'm not sure exactly what happens when you get there. If this is the case, finding all of the places in your code where you obtain a notifier could help. Personally, I prefer to avoid named notifiers and obtain just one reference and use that everywhere.

That said, this is a pure guess and it's likely not to be the case.