Unable to Create Additional Broadcast Events - DQMH 2.1.0.4 - LabVIEW 2015

[topside]

Hello Delacor team,

I recently decided to try out the DQMH framework after your team demo'ed it to a group of us at my company. I was impressed with the level of tools provided through VI scripting that effectively builds the framework for you so I decided to use this in a work project; however I seem to have run into a bit of an issue in creating new broadcast events.

I used the DQMH project template and have built on the template Application.lvlib and currently have created 10 modules that my application uses. I have implemented custom events in all of these modules of which there are a total of 69 events (some broadcast and some request & forget) including the “out-of-the-box” broadcast events created for you. All was going well until last Friday where I attempted to create a new broadcast event in one of my modules - as expected the VI scripting tools opened the tester VI with the new blank event case to handle the broadcast I just created. I added the code necessary to this VI then put my new broadcast VI in the desired place in my module.lvlid:main.vi and saved.

I then attempted to open my Application.lvlib:main.vi which subscribes to all of the module events to which the dreaded "Access violation" exception message was thrown and I was kicked out of LabVIEW completely. This now happens whenever I try to create a new broadcast event in any module with seemingly any data argument type within this project. I have played around with a few things to see if I can make any sense out of this issue but so far nothing has prevailed. From what I can tell the issue occurs due to the new event reference added to the module's Broadcast Events--cluster.ctl. If I manually delete the new event reference from this cluster then I am able to re-open my main.vi; however I cannot proceed because I cannot add any new events to my modules without it breaking my entire application.

I just wondered if the Delacor team were aware of any limits in the number of broadcast events that can be created or had seen anything similar before? I have tried to replicate this on a colleague's machine and the exact same behaviour is exhibited. I am pondering whether this issue could be contained to LabVIEW 2015 and if an upgrade to SP1 or 2016 may cure it. At the minute I am stuck with this and am unable to proceed so may need to look at a simpler framework which would mean re-writing everything I have created so far.

If you could please let me know if you have any suggestions that would be much appreciated.

Thanks.

Seamus

[CRoebuck]

Seamus,

Sorry to hear about the issues you are seeing. It does sound like something is not well in the the Broacast Events--cluster.ctl

Are you running any kind of source code control? It would be useful if you could go back to the point where the offending broadcast event was first created in case the binary file has been corrupted in some way.

Failing that, if you could create a simple VI which uses the Obtain Broadcast Events For Registration.vi of each of your created DQMH modules wired to an Event Registration node and a corresponding Event Structure, then add a new Broadcast event to one of your modules. Do you see the Access Violation when opening your newly created VI?

Chris

[topside]

Thanks for your response Chris,

I am indeed using SVN for this development so I do have the option to go back to the project before the offending event was created. The first time this happened I had only just committed some changes so I discarded the offending code and updated to get back to where I was so I could try and re-create the event to see if something went wrong in the process. Unfortunately the same thing happened again. I suppose I should go back further in time to see if I can identify the point at which the trouble started however everything was running fine until the commit mentioned above.

I created a new VI and registered to all of the module events after having created the offending event but I did not try then adding another broadcast event at this point so that will be my next step.

Thanks for your help and I will report back with any findings.

Seamus

[topside]

Small update:

I seem to be able to create broadcast events again - I don't believe I was quite as thorough as I should have been initially as I found that in a couple of my modules I could indeed create broadcast events. Once a broadcast event had been created in one of these modules I was then able to create a broadcast event in one of the original troublesome modules, allowing me to open my Application.lvlib:main.vi and add handlers for the new events.

I suspect this issue has nothing to do with DQMH itself but more in what is happening with events in LV under the hood. It seems that creating this new event satisfied LabVIEW as far as to allow subscribing to events in the troublesome module. For now I think I will try and err on the side of caution as it seems like a bizarre occurrence and not something anyone has experienced in using DQMH.

Thanks.

Seamus

[FabiolaDelaCueva · Accepted solution]

Hi Seamus,

I sure hope it is a rare event, we have created large applications with a lot more broadcast events and have not seen this issue.

LabVIEW 2016 brought some improvements to events, including fixing the issue that caused some event cases to register to a different event than the event intended as mentioned before in this group.

If upgrading to LabVIEW 2016 is a possibility for you, maybe you benefit from other improvements done to the way User Events are handled.

By the way, every time you get that crash reporter window, please do send the report to NI. Every crash report they get, gets evaluated for the next LabVIEW release.

Let us know if there is anything else we can do to help.

Best regards,

Fab

[topside]

Hi Fabiola,

Thats a valid point and I will consider upgrading to 2016 for now as I am finding a lot of my user event cases are being assigned to different events as I had new broadcast events in my modules.

Thanks for your help

Seamus