# Problematic .mwel files **URL:** \ **Category:** Support\ **Created:** [January 17, 2024, 5:16pm UTC](https://mworks.discourse.group/t/problematic-mwel-files/946 "2024-01-17T17:16:03Z")\ **Posts on this page:** 8\ **Page:** 2
**Author:** ![taylor.xie](https://avatars.discourse-cdn.com/v4/letter/t/9fc348/32.png) [@taylor.xie](https://mworks.discourse.group/u/taylor.xie)\ **Post date:** [February 6, 2024, 2:45pm UTC](https://mworks.discourse.group/t/problematic-mwel-files/946/21 "2024-02-06T14:45:54Z")
Hi Chris, I implemented the new set\_laser\_channel macro and it worked! Thank you again for your help. Best, Taylor ---
**Author:** ![taylor.xie](https://avatars.discourse-cdn.com/v4/letter/t/9fc348/32.png) [@taylor.xie](https://mworks.discourse.group/u/taylor.xie)\ **Post date:** [February 12, 2024, 3:21pm UTC](https://mworks.discourse.group/t/problematic-mwel-files/946/22 "2024-02-12T15:21:21Z")
Hi Chris, In another protocol we used recently (.mwel file attached), the overlapping of two event codes was again causing a problem. I just wanted to send you this protocol as well to provide more examples of this issue. The two overlapped event codes in this protocol were the e\_laser\_off inside the turn\_laser\_on definition at the end of the “Stimulus On” state and the first event code e\_stimulus\_success in the “Stim Success” state. The symptom was that there was one e\_laser\_on followed by three e\_laser\_off but no e\_stimulus\_success. As an immediate, temporary solution, I added an extra vpixx\_send\_blackrock\_sync\_word(e\_laser\_off) before the e\_stimulus\_success at the beginning of the “Stim Success” state thinking that the success event code would not be masked by other event codes this way. The result of this was one e\_laser\_on followed by one e\_laser\_off and two e\_stimulus\_success. The temporary solution works for now but we are still confused by this issue and also the extra event codes that were sent in both versions. We would appreciate it if you could shed some light on this issue. Thank you! Best, Taylor [protocol\_LaserFrequency\_fixed.mwel](https://mworks.discourse.group/uploads/short-url/aT1A2gi5Iqfpu3cxemMDNOkpNNZ.mwel) (15.3 KB) ---
**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\ **Post date:** [February 12, 2024, 7:55pm UTC](https://mworks.discourse.group/t/problematic-mwel-files/946/23 "2024-02-12T19:55:57Z")
Hi Taylor, > In another protocol we used recently (.mwel file attached), the overlapping of two event codes was again causing a problem. I’ve been working on a fix for this problem. I’ll let you know as soon as it’s available. Cheers, Chris ---
**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\ **Post date:** [February 13, 2024, 2:38pm UTC](https://mworks.discourse.group/t/problematic-mwel-files/946/24 "2024-02-13T14:38:21Z")
Hi Taylor, > I’ve been working on a fix for this problem. I’ll let you know as soon as it’s available. The fix is now in the MWorks [nightly build](https://mworks.github.io/downloads/). It required reworking some of the internals of variable assignment, but the problem should be 100% solved. When you have a chance, please test out the nightly build and confirm that the issue is gone. Thanks, Chris ---
**Author:** ![taylor.xie](https://avatars.discourse-cdn.com/v4/letter/t/9fc348/32.png) [@taylor.xie](https://mworks.discourse.group/u/taylor.xie)\ **Post date:** [February 13, 2024, 9:25pm UTC](https://mworks.discourse.group/t/problematic-mwel-files/946/25 "2024-02-13T21:25:25Z")
Hi Chris, Thank you for the update! We were trying to test it out but one problem we ran into was that the Nightly Build version requires MacOS 12 or later and our version is MacOS 11.7.10 BigSur. Before we go ahead and update to 13 or 14, we just wanted to make sure that the system update is required for Nightly Build and also which version, 13 or 14, is better for us to update to? Best, Taylor ---
**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\ **Post date:** [February 13, 2024, 10:33pm UTC](https://mworks.discourse.group/t/problematic-mwel-files/946/26 "2024-02-13T22:33:02Z")
Hi Taylor, Yes, that’s right – the nightly build requires macOS 12 or later. Regarding 13 vs 14, I don’t have any specific reason to recommend one over the other. If you prefer to update macOS as infrequently as possible, then going with 14 would give you an extra year before you need to upgrade again. On the other hand, 13 has been available for a year longer than 14, so third-party software developers have had more time to smooth out any issues with it. That said, I haven’t personally encountered any problems with 14 vs 13. Cheers, Chris ---
**Author:** ![taylor.xie](https://avatars.discourse-cdn.com/v4/letter/t/9fc348/32.png) [@taylor.xie](https://mworks.discourse.group/u/taylor.xie)\ **Post date:** [February 14, 2024, 2:04pm UTC](https://mworks.discourse.group/t/problematic-mwel-files/946/27 "2024-02-14T14:04:57Z")
Hi Chris, Great. We will go ahead with the update and will let you know how it works out. Thank you again! Best, Taylor ---
**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\ **Post date:** [April 2, 2024, 1:27pm UTC](https://mworks.discourse.group/t/problematic-mwel-files/946/28 "2024-04-02T13:27:22Z")
[Previous page](https://mworks.discourse.group/t/problematic-mwel-files/946.md?page=1)