Monkeymerlot
commented
4 years ago Going to use a Driver Management class.
Here is the start up routine:
It takes an array of paths to the drivers, and for each one it will start them, and initialize a cluster of events created for each driver. I initially wanted to do call by reference, but this wasnt possible as we dont have a set front panel where everything is based off of the same interface. For now, I think that setting the event cluster, which is named very uniquely, will suffice.
Front Panel of Refactored Driver:
Creation of Events in start up routine:
Send Stop Event to all drivers
Give them one second to stop:
If they stop in one second: Do nothing
If they don't stop in time: Consider them hanging, abort them:
Destroy all User Events
Destroy all VI References
And I envision its usage like so:
If the size of the image is greater than 100x100 (ie 100x100 um) then it is actually nm, and the ratio is 1000. If it is less than 100x100 um, then it is determined to be in um, not nm, and its ratio is simply 1.
It reads it in the Paths Apply Inkscape Ratio:
and Rectangle Apply Inkscape Ratio:
Normally we would have used OpenG Wait (ms), but instead we wait with abort in Litho Object Points:
And if Abort Notifier is True:
We send a stop command to the software, and then give it a second.
(edit: I want to add that since this doesnt stop the driver, it will stop the current object from being written, and then it will run the Object finish sequence where we set the voltage to zero and lift the tip up. If we happen to get it between objects, which would be exceedingly rare, it should just ignore the next object. If we get it while it is preparing to start the object, once it begins it will immediately stop.)
Where we create notifier and send it to the driver:
If we then hit "Abort" button while lithography is running:
And once lithography is finished and we get the Lithography Done Event:
Added event call back to post object stuff:
Added abort for initial move:
Fixed bug involving speed on move to initial point (wasnt orignally written, making it zero, thus dividing by zero gave inf, which was the time we would have waited for...)
ciozi137
Minor change. I made the move to initial point speed be equal to the value in the old program
Got this issue when I was running a built version of the program.
Previously I refactored a driver for the Asylum microscopes (MFP-3D and Cypher). There are only a few things that I need to do to finish this driver, and then I think it can be a replacement. I also want to redo the way that we call drivers and swap them. Here are the main things that I see that are bad practices and I should change when adding the new driver.
First, is that we send information by changing values on their front panels using named controls:
Instead we should user User Events.
Second, we currently abort VIs when swapping them inside of a subpanel and at the end. There is a better way to do this: First thing is that you don't need to abort a VI to take it out of a subpanel. Second thing is, you should never abort a VI period. Like ever. There are a few instances when you might have to as a last resort, but you should set up a way to stop them gracefully to begin with. Where we abort subpanel
Current method of swapping a subpanel:
So to implement this I think that it would be beneficial to think about having a User Event that will send a stop request. We can wait on some conformation that the VI has stopped. If it has not stopped in a certain amount of time, we can then abort it.
Other, less problematic issues (for now) Use of a global variable for information such as offset and the like.