Hi Chris,
We noticed an issue related to laser with the new nightly build version. Besides the 3D shapes, this version also incorporated a modification to the QCUALOR plugin we discussed before. I’ve attached below one of your previous emails explaining the new plugin:
“The QCUALOR changes we discussed are now in the MWorks nightly build. Just to recap how things now work:
-
When the experiment loads, all channels are configured to “off”.
-
When start_io_device is called, only channels with non-“off” modes and channels going from a non-“off” mode to “off” are configured. No configuration commands are sent for channels with mode “off” that are already off.
-
When stop_io_device is called, all channels that are currently in non-“off” modes are configured to “off”. No configuration commands are sent for channels with mode “off” that are already off."
There are two problems we noticed:
- We have to physically switch on the laser before we load workspaces. We’ve discussed this but was interrupted by another more urgent problem back then. Looking back at our previous communications, the solution you offered was to configure the laser at the first start_io_device. We would like to follow up on this and see if this will solve the problem.
- After running a laser protocol for about a few minutes, the laser would be stuck at the on state. We had to switch it off physically and on again for it to come back to work but the same problem would happen again. The laser protocols we ran commended the laser to change the frequency or the amplitude trial by trial. I’ve attached the two protocols, the config_Laser, and the error displayed in the console.
Below are two tests we’ve done to troubleshoot this problem:
- We drove this laser with MWork version 0.13. The protocols ran and the laser was not stuck.
- We drove another laser with MWork nightly build. The issue I described above happened.
So we suspect that it was an issue with the new QCUALOR plugin.
This is urgent so thank you for helping us troubleshooting this. Please let me know if you have any questions. I’ve also CC other lab members so they are in the loop. Thank you again!
Best,
Taylor
(attachments)
config_Laser.mwel (5.63 KB)
protocol_LaserAmplitude.mwel (14.2 KB)
protocol_LaserFrequency.mwel (15.1 KB)
laser_troubleshooting.txt (14 KB)
Hi Taylor,
The QCUALOR changes you described are included in MWorks 0.13. There have been no subsequent changes to MWorks’ QCUALOR interface, so if you’re using a post-0.13 nightly build, the QCUALOR code is the same as in 0.13.
We have to physically switch on the laser before we load workspaces. We’ve discussed this but was interrupted by another more urgent problem back then. Looking back at our previous communications, the solution you offered was to configure the laser at the first start_io_device. We would like to follow up on this and see if this will solve the problem.
As I said previously, I don’t understand why you were ever able to load your experiment with the laser turned off. But, yes, we certainly could make the change I suggested.
After running a laser protocol for about a few minutes, the laser would be stuck at the on state. We had to switch it off physically and on again for it to come back to work but the same problem would happen again. The laser protocols we ran commended the laser to change the frequency or the amplitude trial by trial. I’ve attached the two protocols, the config_Laser, and the error displayed in the console.
The error “QCUALOR device did not respond to configuration command” indicates that MWorks is trying to send commands to the laser, but the laser isn’t responding. That sounds like an issue with the connection or (more likely) the laser itself. If you run your experiment with the log_commands parameter set to true, you’ll be able to see the commands that MWorks is sending to the laser and the responses the laser is sending back. The “did not respond” error should correlate with sends with no matching receives.
We drove this laser with MWork version 0.13. The protocols ran and the laser was not stuck. We drove another laser with MWork nightly build. The issue I described above happened.
Can you try driving each of the two lasers with both 0.13 and the nightly build? If it’s a software issue in the nightly build, then it should cause the problem with both lasers. On the other hand, if it’s a hardware issue with one of the lasers, then the problem should happen with both MWorks versions on that laser.
Cheers,
Chris
Hi Chris,
Before this new nightly build version, we were able to load without the laser on but the console would send a “fail to configure QCUALOR” error. But this change is mainly to make sure that we don’t burn the laser when we don’t need it. Thank you!
We just tried log_commands and I’ve attached the message in the console below. It does seem like there was no response sent back from the laser.
However, we’ve done the two tests you suggested. So in total we did:
- This laser + nightly build = not working
- This laser + version 0.13 = working
- Another laser + nightly build = not working
- Another laser + version 0.13 = working
So it seems to be a software problem?
Best,
Taylor
(attachments)
error.txt (10.6 KB)
Hi Taylor,
Yes, it does look like a software problem, although I’m having a hard time imagining how. Let me take a look through recent changes and see if anything seems relevant.
Thanks,
Chris
Hi Chris,
Thank you for your help. In the meantime, happy to do more tests if needed.
Best,
Taylor
Hi Taylor,
Before this new nightly build version, we were able to load without the laser on but the console would send a “fail to configure QCUALOR” error.
I’m confused. Do you mean that with MWorks 0.13, you could load the experiment without the laser on, but with the nightly build, you no longer can? That makes no sense, as the QCUALOR initialization code is the same in both.
Are you sure that you’re comparing the nightly build with the MWorks 0.13 release build? If you open MWServer’s “About” window (MWServer → About MWServer), what version number do you see? For the 0.13 release build, it should be “0.13 (2024.05.01)”.
Thanks,
Chris
Hi Chris,
The MWorks 0.13 that can load the experiment without the laser on is MWorks 0.13 (2024.03.13) version. Ideally, we would prefer loading experiments without turning on the laser. Thanks!
Best,
Chuyi
Hi Chuyi,
The MWorks 0.13 that can load the experiment without the laser on is MWorks 0.13 (2024.03.13) version.
Ah, now we’re making progress. I think you must mean “0.13.dev (2024.03.13)” – the “.dev” part indicates a nightly build, not a release build. Also, the changes that Taylor mentioned originally were made after 3/13/2024, so they likely are the cause of the current issue.
I will investigate further and get back to you.
Thanks,
Chris
Ok, thanks for the update, Chris!
Hi Taylor & Chuyi,
I’ve just published a new nightly build that defers initial configuration of the laser until the first invocation of start_io_device. This should allow you to load your experiment with the laser turned off. Be aware that the first invocation of start_io_device will now always configure all four channels, even if some of them are configured to be off, so it will take more time to execute compared to subsequent invocations where one or more channels are off.
After looking through the code and running some tests, I still don’t see any explanation for the missing configuration responses. However, it’s at least possible that deferring the initial configuration may have some effect – perhaps the laser isn’t ready to receive commands immediately after the serial connection is initiated, and sending them sets things up to break later? I don’t know why it would, but maybe we’ll get lucky and fix both issues with the same change.
If the problem persists, MWorks will now issue a different error message if it receives an incomplete response from the laser (as opposed to no response at all).
When you have a chance, can you please try out this nightly and see if it fixes either problem for you?
Thanks,
Chris
Hi Chris,
We will try it later today and get back to you ASAP. Thank you again for your prompt reply!
Best,
Taylor
Hi Chris,
We just tested the new nightly build. Problem 1 was solved - we didn’t have to turn the laser on until before we loaded a laser protocol.
However, the laser was still stuck at the on state after running for a few minutes. This time, it happened even earlier. I’ve attached the error message in the console below.
Best,
Taylor
(attachments)
error.txt (5.76 KB)
OK, thanks for letting me know. I’ll have to think about what to try next.
Chris
Hi Taylor,
When you have a chance, could you do a quick test of the current nighty build? I disabled a recently-added build setting that should really have no impact on this issue, but I’d like to rule it out all the same.
Assuming you still get errors with the latest nightly, the next step will be to roll back all the changes I’ve made since March to the QCUALOR interface, in order to see if something in those changes has somehow introduced this issue.
Thanks,
Chris
Hi Chris,
Yes, we will test it out this afternoon and get back to you. Thank you!
Best,
Taylor
Hi Chris,
We just tested the current nightly build. Indeed, the problem still persisted. I’ve attached part of the error message.
Best,
Taylor
(attachments)
mwork error.txt (4.29 KB)