Hi Chris,
I implemented the new set_laser_channel macro and it worked! Thank you again for your help.
Best,
Taylor
Hi Chris,
I implemented the new set_laser_channel macro and it worked! Thank you again for your help.
Best,
Taylor
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 (15.3 KB)
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
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. 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
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
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
Hi Chris,
Great. We will go ahead with the update and will let you know how it works out. Thank you again!
Best,
Taylor