Hi Taylor,
The commands were sent at the places where I intended them to be. They were also sent at the exact same places for each trial. It might be an underlying design of the laser so we will try to see if we can figure out why.
Yeah, if you’re seeing both the SEND and RECV messages, then the laser has received and acknowledged the configuration command. The timing variability must be due to whatever is happening on the laser.
It is strange, though. As far as you can tell, is the laser operating as intended, irrespective of the timing variation? At the low end of the range (2ms), I wonder if the laser is doing nothing other than receiving and acknowledging MWorks’ commands, which might mean it isn’t doing any actual configuration in those cases. On the other hand, if it does successfully configure itself in 2ms, why does it sometimes take much longer to do the same amount of work?
I think we misunderstood when the channels would be configured to “off” with the new plugin. Now we have to turn the laser on before loading the animal’s experiment. However, we realized that we might not want the laser to be on since the beginning of the session. Sometimes we only need it to be on for some of the protocols happening later in the session. Is there a way to change this? Can this configuration happen when we turn on the laser instead of when we load experiments?
By “turn the laser on”, do you mean literally pressing the power switch on the rear of the device? And with the old version of the plugin, you could press the switch after you loaded your MWorks experiment? If so, I don’t understand how. Even though the old version of the plugin didn’t send configuration commands at load time, it still opened a connection to the laser on load. If the laser was powered down, I don’t see how the connection could have succeeded – unless the laser’s serial I/O component is active even when the power switch is off, which seems pretty strange.
In any case, MWorks has no way of knowing whether the laser’s power switch is on or off. We could change the plugin so that no configuration commands are sent until the first time you invoke start_io_device. That would make the first invocation longer, since all four channels would always be configured, but it would eliminate the load-time configuration commands.
Cheers,
Chris