superfine stage control in ARM200 - dm-script

I was wondering if there was any way to control the "superfine" stage controls on an ARM200F through digital micrograph script commands.
The usual EMsetstageXY(xposition, yposition) will only allow for positioning of the stage by the motor controls to about 25nm precision and does not affect the superfine stage values.
I would like to be able to write a script that can control the stage position with superfine controls.

Unfortunately, such a command does not exist. The piezo-controls of the ARM200F are not exposed to the scripting language.

Related

Issues about placing controls out of the form?

I want to know if is a problem for my users, me, stability, or my VB .NET program when controls like textbox, development buttons or dev tools are placed out of the form body (by extand for using tools, and reduce before publishing).
Controls are enabled = false, or hidden but necessary for my program run flow.
This is a technique that used to be common, and even today I'm not aware of anything about it that will actually break anything: winforms is perfectly happy to let you position items out of the visible area.
But it's a little unusual to see anymore, because we have better tools for managing this.
I'll add a note about remembering to call SuspsendLayout() before changing a bunch of controls to reduce flickering, and ResumeLayout() when finished.

LabVIEW - can you use a numeric control as an indicator

I've written LabView code for a locking system.
The lock has a motion timer that relies on input from a numeric control. I've added a script file reader that needs to be able to change that timer value. Using a selector, I can switch between values, but I'd like it to update the value in the control, rather than override it, so that I can see it on the screen.
How can this be accomplished?
This is currently how I switch between the scripted version and the direct numeric input from the control:
So how can I get the script value to update the control box or is that not possible...?
Do you mean something like this? I created a little vi to demonstrate how the control is updated.
In most cases "property nodes" are the way to go. Every control has a lot of different options to chose from and usually if you look through the properties you will find what you're looking for :)
A little hint:
If you want to add "code" to your question so that other users can test it, you can create a .png file. To do this, you need to select the parts of the vi that you want to share, and click on "Edit > Create VI Snippet from Selection". Then you save that generated .png and upload it here as a picture. Then others can drag&drop it into their block diagram.
Important: Check the .png before uploading and make sure that you're not accidentally posting sensitive data of your company.

Is there a scripting interface for the new type of dock-able floating panels in GMS3?

In GMS3, there seems to be a new kind of floating palette that can be subdivided and has a wider area for UI elements (e.g. Display and Technique Manager). Can such UI panels be generated via DM scripts? The floating panels generated via DLGCreateDialog and RegisterScriptPalette are narrower and have more limited docking behavior, so it seems that it would be beneficial to be able to generate panels that follow the new UI model.
No, these panels ("Technique panels") are currently (GMS 3.1) not supported by script.

Which language should be used to create Auto-IT like scripts for screen detection?

I require guidance about auto-IT scripts(scripts that automatically control windows screen on base of scripts written). I need to know the language in which I can create such scripts or pre-made scripts which automatically control screen by detecting opened window and deciding what to do accordingly.
I mean to say the product should detect the screen and then decide what to do.
I think you don't know that AutoIt is a programming language.
You should use the
ControllClick
MouseClick
WinMove
WinActivate
commands.
Just googlesearch: AutoIt "command" and read how they work.
Good luck

What is the most efficient way to quickly understand how a complex LabView VI works?

What is the best way to understand a complex LabView VI that controls a motor?
My goal is to control the motor from a joystick.
The wiring diagram shown below allows a LabView user to control the motor from the LabView GUI: move a slider up and down either increasing or decreasing the desired velocity. As the slider's value changes, it is fed into a bunch of math controls and eventually gets converted into a command string for the motor to interpret. This command string, if I understand correctly, is bunch of bytes that get written to the serial port.
Instead of using the LabView GUI to control the motor, I would like to use the joystick.
What is the best way to approach this?
The joystick has pitch,yaw,roll,and throttle. Which one relates best to the velocity of a motor?
The answer to your title "What is the most efficient way to quickly understand how a complex LabView VI works?" is probably to do some combination of the following:
Look at the VI's inputs and outputs to try and understand what they are there for. The label and caption of controls and indicators may be helpful, also right-click to check the description and tip.
As well as controls and indicators, look for other I/O: queues, notifiers, global variables, file read/writes, instrument communications, and for any data storage that persists between calls such as an uninitialised shift register.
Look at the overall structure of the VI to see how it executes, e.g. is it a one-off operation, does it execute different cases depending on some input, does it loop until a certain condition happens, does it use a state machine structure, etc
Break down the VI's structure into smaller pieces that you can understand. You could print the diagram out and annotate it by hand, or add frame decorations and text comments to the diagram to record what you deduce. If the diagram is cluttered or poorly laid out, rearrange it as you go along (use Ctrl-click and drag on the diagram background to add blank space where you need it).
Set probes on key wires and watch them while the VI runs to see what happens
If possible, manually set the VI's controls to example values and run it to see what happens (this may not work if the VI depends on other parts of a program running at the same time)
Write a test wrapper VI that calls the complex VI and supplies it with example data or inputs to see what happens.
To address your specific question about the VI diagram you've posted, I can see various controls for quantities such as Velocity, Position, Amplitude, Max A (amplitude?), Frequency and so on. You need to decide which of these quantities should be controlled by which axis or output of your joystick. Then you need to add code that reads those values from your joystick, and modify the existing code so that the parameters you want to control are supplied by the joystick values instead of the front panel controls. You could probably just put the joystick reading code inside the existing loop, wire the joystick outputs to join up with the wires from the front panel controls you want to replace, and then change the relevant front panel controls to indicators from the right-click menu so that they will show the values you are getting from the joystick.
The best way is to write one from scratch. But you could analyse the code by clicking the Highlight Execution button to display an animation of the block diagram execution when you run the VI, and use probes to check intermediate values. And you probably should also do an on-line course, e.g. LabVIEW Training: Learn LabVIEW in Three or Six Hours
My answer to your third question is "throttle.".