PS: Fixed the transformation, for the simulation case I actually have to use the "invTransform(x,y)" for rotation and not the native "forward" Transform() as applied to the actual tip.... what ever you need, depends on your "perspective" so to say.
The hardware base class manages a coodinate transformation matrix for rotation you may or should use... if you implement roation at all. You may opt to simply ignore it.
The coordinate system is "RHS", 0,0 Offset means the scan image should be centered at 0,0 absolute. Scan coordinates are always aligned with the X (fast) scan axis which is rotated by the rotation angle CW (means for example +15deg "tilts" the scan forward "downwards" right of the center) -- as illustrated by the PanView visually!
Positive X Offset should shift the imaged area to the "right". Positive Y Offset shifts the images area "up" in the base non rotated coordinate system.
You can open the "world map" to see what you scanned: enable it via RAD or manual "Scan->Update World Map" (F4) then check Scan->View->show world! The world is in the base coordinate system and non rotated. It can also be used to select a new / next scan area visually, else keeping track of what was scanned so far of the whole via offset accessible "world".
The "double" x,y values passed are in "DAC" units, and should map directly (with what ever actual resolution) to -32767.0 ... +32768.0 (16bit base historically). All Gain and sensitivity (Volt to Angstroems, etc.) are actually handled for you already vis the Gxsm core "Instrument" class and together with the Preferences settings.
The Simualtor "undoes" this to get back to "model" Angstroems (Gxsm thinks in Angstroems as basic length unit for xyz). You will find some transformation calls using
Scan Gains:
xscan = gapp->xsm->Inst->Dig2XA (x); // Digital to X Ang. (X-Scan)
and Offset gains
xoffset = gapp->xsm->Inst->Dig2X0A (x0); // Digital to X0 Ang (X-Offset)
see comments.
Final fix and comments:
staticdoublefz=1./gapp->xsm->Inst->Dig2ZA(1); // get Z resolutiondoublex=xi*Dx-Dx*Nx/2; // x in DAC unitsdoubley=(Ny-yi-1)*Dy-Dy*Ny/2; // y in DAC units, i=0 is top line, i=Ny is bottom line//PleaseNote:
//spm_simulator_hwi_pi.app->xsm->... andgapp->xsm->...
//areidenticalpointerstothemaing-application(gapp)classanditismadeavailabevietheplugindescriptor//incasetheglobalgappisnotexportedorusedintheplugin. Andeitheronemaybeusedtoaccesscoresettings.
x=gapp->xsm->Inst->Dig2XA((long)round(x)); // convert to anstroems for model using instrument class, use Scan Gainsy=gapp->xsm->Inst->Dig2YA((long)round(y)); // convert to anstroems for modelinvTransform(&x, &y); // apply rotation! Use invTransform for simualtion.x+=gapp->xsm->Inst->Dig2X0A(x0); // add Offset, use Offset Gainsy+=gapp->xsm->Inst->Dig2Y0A(y0);
PS: In my actual MK2 or MK3 DSP hardware the scan coordinate transformation is done on the DSP / hardware using this matrix in using MK2: 32 bit or MK3: 64 bit fixed point arrithmetic and it can rotate in "real time" actually safely even while scanning as it adjust the current angle to the target angle in small incremenmts....
I tell you this, as some functions may seam odd otherwise. The simulator does not really care about this and only uses the current value to transformations.
You may also buffer and "lock" / ignore rotation changes while scanning -- up top you.
Last edit: Percy Zahl 2019-12-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many thanks for the fix and rich post's details.
Let me answer about the hardware I am going to implement here: we have developed a light and flexible architecture based on the common RaspberryPi, which forms a pair with a microcontroller to perform real-time tasks (or better deterministic, time-related tasks, a luxury we cannot ask to an OS-based device directly as the RPi actually is). We have named this pair "EpsilonPi".
To build a scanning probe controller we have joined 3 EpsilonPi modules (and of course additional electronics) with the following dedicated tasks:
1. signal data acquisition from the measuring head and feedback control loop
2. low-resolution signal monitor and tip-sample approach
3. X-Y scan driver
The architecture is command-based and commands/data to/from the modules travel over the Ethernet using the strong and efficient ZeroMQ layer. Once at the RaspberryPi, data and command exchange with the electronics is carried out via SPI and Serial ports, but this is completely transparent to the GUI software which just "sees" the 3 modules via Ethernet.
Therefore GXSM3 will issue a set of commands to achieve a task, for example a line scan, getting back data.
I have then to add the ZeroMQ stuff to GXSM, which should be almost transparent (just a matter of installing Zeromq and CZMQ on the computer), and then modify the existing "simulator" routines with the proper command lists. All this trying to keep the project as clean as possible :-)
Although this architecture would allow more demanding tasks (for example rotation...) I will consider my first great result to get ready with these two implementations:
a) a 4-quadrant photocell monitor collecting the Deflection and Lateral force signals and showing them as a red spot in a cross window, to allow laser beam alignment in an AFM system (addressing module 2. of the above list)
b) AFM image acquisition thereafter (addressing modules 1. and 3. of the above list)
Only after getting these functionalities I could go on and implement more advanced features, such as Force Spectroscopy (a mode accounted for in actual architecture) or others.
Marco
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sounds neat. But you mus have added custom?? AD/DA hardware to it right?
BTW, if you ever need a really fast PAC / PLL for NC-AFM -- my RedPitaya (kind of open FPGA platform) will fit in perfectly, as it also coimmunicated with my DSP using a high speed SPI interface, well McBSP to be precise as I drove longer cables.
Last edit: Percy Zahl 2019-12-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, there is added hardware to manage all the signals.
Please, let me know where I can read more about your RedPitaya.
About software: I have switched to an Ubuntu 19.10 distro and, after adding many libraries I got the project compiled WITHOUT the python errors, confirming that it was a python lib version mixup. Great.
I need an advice to proceed: where is the most convenient place to add some ZeroMQ initializations and creation of the related threads ?
I guess it would be nice to confine my stuff into the dedicated /plug-ins/hard files but need to know where to put an overall intialization to run when one selects File -> Preferences ->SPM-NANOUP (yes, this is my controller's name :-) ).
Thanks !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regarding your question to "init" hardware, etc., do this at the "HwI plug-in" initialization and potential hardware probing phase.
Have a look at the sranger_mk3_hwi_dev.C for example. The constructor of the abstracted xsmhardware class is searching for the "DSP" device in that case and "hot" connects to it.
Im my "SignalRanger DSP" topology the DSP subsystem is 100% standalone and I can so to say "pull the communication plug" even reboot the control linux machine... and reconnect to it -- while it is potentially even still scanning and the tip is safe at all times! However, for sure I will loose the data stream and on going image, but I can reconnect, stop the potentially still going scan and continue ;)
I have to say this is a very nice and "good to know" scenario if anything goes haywire on the host or even power outage -- just need to battery backup the low power DSP and little electronics needed at minimum!
sranger_mk3_hwi_dev::sranger_mk3_hwi_dev(){...}
And this constructor is "called" at GXSM startup when the plugin is loaded -- or attempted to be loaded. The HwI Plugin - init() hook call created the sranger_mk3_hwi_dev class.
Same is true for the simulator.
Except there is not much to do for the simulator, but here you want to establish your hardware connection:
About the PAC/PLL (RP = RedPitaya) for fast frequency detection, and osc. amplitude control, etc. etc. -- I do have some even more advanced plans with this in near future: https://www.redpitaya.com/
The RedPitaya is a high speed (=225MHz!!) FPGA+AD/DA mini platform (~400$), see here and a few more news posts:
Just open the control Dialog, well you won;t be able to coonect, but see the controls!
Gxsm->Windows->Inet-Json-Rp-control
I need to find a better name for this. It is communication via Ethernet using a underlaying (packed) JSON data/control socket server (on the RP) and a client (implemened via the GXSM plugin) communication. This is not a particular "HwI" plugin, but a very generic GXSM plugin, can do anything! Here simply providing the control and parameter integration -- plugins can hook to the GXSM NetCDF data - save/load - events and add custom variables! You likely want to look into this later as well! The sranger... HwI's are storing a whole bunch of parameters.
.... One note about GXMS3 and RaspberryPI -- it's is working reasonable well on a RaspberryPI Model 4 using the default Raspbian! I did set that up with a 28" 4k monitor as you certainly need a little real estate for all the windows. For a Highschool student project last summer! Sure not as snappy as on a big bro i9 system, but very usable! I could not ge tthe 3D/GL working for 3D scan views, but not necessary.
greetings
-Percy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
PS: Fixed the transformation, for the simulation case I actually have to use the "invTransform(x,y)" for rotation and not the native "forward" Transform() as applied to the actual tip.... what ever you need, depends on your "perspective" so to say.
The hardware base class manages a coodinate transformation matrix for rotation you may or should use... if you implement roation at all. You may opt to simply ignore it.
The coordinate system is "RHS", 0,0 Offset means the scan image should be centered at 0,0 absolute. Scan coordinates are always aligned with the X (fast) scan axis which is rotated by the rotation angle CW (means for example +15deg "tilts" the scan forward "downwards" right of the center) -- as illustrated by the PanView visually!
Positive X Offset should shift the imaged area to the "right". Positive Y Offset shifts the images area "up" in the base non rotated coordinate system.
You can open the "world map" to see what you scanned: enable it via RAD or manual "Scan->Update World Map" (F4) then check Scan->View->show world! The world is in the base coordinate system and non rotated. It can also be used to select a new / next scan area visually, else keeping track of what was scanned so far of the whole via offset accessible "world".
The "double" x,y values passed are in "DAC" units, and should map directly (with what ever actual resolution) to -32767.0 ... +32768.0 (16bit base historically). All Gain and sensitivity (Volt to Angstroems, etc.) are actually handled for you already vis the Gxsm core "Instrument" class and together with the Preferences settings.
The Simualtor "undoes" this to get back to "model" Angstroems (Gxsm thinks in Angstroems as basic length unit for xyz). You will find some transformation calls using
Scan Gains:
xscan = gapp->xsm->Inst->Dig2XA (x); // Digital to X Ang. (X-Scan)
and Offset gains
xoffset = gapp->xsm->Inst->Dig2X0A (x0); // Digital to X0 Ang (X-Offset)
see comments.
Final fix and comments:
PS: In my actual MK2 or MK3 DSP hardware the scan coordinate transformation is done on the DSP / hardware using this matrix in using MK2: 32 bit or MK3: 64 bit fixed point arrithmetic and it can rotate in "real time" actually safely even while scanning as it adjust the current angle to the target angle in small incremenmts....
I tell you this, as some functions may seam odd otherwise. The simulator does not really care about this and only uses the current value to transformations.
You may also buffer and "lock" / ignore rotation changes while scanning -- up top you.
Last edit: Percy Zahl 2019-12-17
Many thanks for the fix and rich post's details.
Let me answer about the hardware I am going to implement here: we have developed a light and flexible architecture based on the common RaspberryPi, which forms a pair with a microcontroller to perform real-time tasks (or better deterministic, time-related tasks, a luxury we cannot ask to an OS-based device directly as the RPi actually is). We have named this pair "EpsilonPi".
To build a scanning probe controller we have joined 3 EpsilonPi modules (and of course additional electronics) with the following dedicated tasks:
1. signal data acquisition from the measuring head and feedback control loop
2. low-resolution signal monitor and tip-sample approach
3. X-Y scan driver
The architecture is command-based and commands/data to/from the modules travel over the Ethernet using the strong and efficient ZeroMQ layer. Once at the RaspberryPi, data and command exchange with the electronics is carried out via SPI and Serial ports, but this is completely transparent to the GUI software which just "sees" the 3 modules via Ethernet.
Therefore GXSM3 will issue a set of commands to achieve a task, for example a line scan, getting back data.
I have then to add the ZeroMQ stuff to GXSM, which should be almost transparent (just a matter of installing Zeromq and CZMQ on the computer), and then modify the existing "simulator" routines with the proper command lists. All this trying to keep the project as clean as possible :-)
Although this architecture would allow more demanding tasks (for example rotation...) I will consider my first great result to get ready with these two implementations:
a) a 4-quadrant photocell monitor collecting the Deflection and Lateral force signals and showing them as a red spot in a cross window, to allow laser beam alignment in an AFM system (addressing module 2. of the above list)
b) AFM image acquisition thereafter (addressing modules 1. and 3. of the above list)
Only after getting these functionalities I could go on and implement more advanced features, such as Force Spectroscopy (a mode accounted for in actual architecture) or others.
Marco
Sounds neat. But you mus have added custom?? AD/DA hardware to it right?
BTW, if you ever need a really fast PAC / PLL for NC-AFM -- my RedPitaya (kind of open FPGA platform) will fit in perfectly, as it also coimmunicated with my DSP using a high speed SPI interface, well McBSP to be precise as I drove longer cables.
Last edit: Percy Zahl 2019-12-18
Yes, there is added hardware to manage all the signals.
Please, let me know where I can read more about your RedPitaya.
About software: I have switched to an Ubuntu 19.10 distro and, after adding many libraries I got the project compiled WITHOUT the python errors, confirming that it was a python lib version mixup. Great.
I need an advice to proceed: where is the most convenient place to add some ZeroMQ initializations and creation of the related threads ?
I guess it would be nice to confine my stuff into the dedicated /plug-ins/hard files but need to know where to put an overall intialization to run when one selects File -> Preferences ->SPM-NANOUP (yes, this is my controller's name :-) ).
Thanks !
Glad about the error message been gone. But Debian is fine if clean ;)
Is this the RaspberryPI add on you build on top of?
https://www.epsilonpi.it/
Regarding your question to "init" hardware, etc., do this at the "HwI plug-in" initialization and potential hardware probing phase.
Have a look at the sranger_mk3_hwi_dev.C for example. The constructor of the abstracted xsmhardware class is searching for the "DSP" device in that case and "hot" connects to it.
Im my "SignalRanger DSP" topology the DSP subsystem is 100% standalone and I can so to say "pull the communication plug" even reboot the control linux machine... and reconnect to it -- while it is potentially even still scanning and the tip is safe at all times! However, for sure I will loose the data stream and on going image, but I can reconnect, stop the potentially still going scan and continue ;)
I have to say this is a very nice and "good to know" scenario if anything goes haywire on the host or even power outage -- just need to battery backup the low power DSP and little electronics needed at minimum!
And this constructor is "called" at GXSM startup when the plugin is loaded -- or attempted to be loaded. The HwI Plugin - init() hook call created the sranger_mk3_hwi_dev class.
Same is true for the simulator.
Except there is not much to do for the simulator, but here you want to establish your hardware connection:
About the PAC/PLL (RP = RedPitaya) for fast frequency detection, and osc. amplitude control, etc. etc. -- I do have some even more advanced plans with this in near future:
https://www.redpitaya.com/
The RedPitaya is a high speed (=225MHz!!) FPGA+AD/DA mini platform (~400$), see here and a few more news posts:
https://sourceforge.net/p/gxsm/news/2019/01/digital-high-speed-serial-link-between-redpitaya-and-mk3/
Just open the control Dialog, well you won;t be able to coonect, but see the controls!
Gxsm->Windows->Inet-Json-Rp-control
I need to find a better name for this. It is communication via Ethernet using a underlaying (packed) JSON data/control socket server (on the RP) and a client (implemened via the GXSM plugin) communication. This is not a particular "HwI" plugin, but a very generic GXSM plugin, can do anything! Here simply providing the control and parameter integration -- plugins can hook to the GXSM NetCDF data - save/load - events and add custom variables! You likely want to look into this later as well! The sranger... HwI's are storing a whole bunch of parameters.
See also the poster I attched here!
And in SVN:
https://sourceforge.net/p/gxsm/svn/HEAD/tree/trunk/Gxsm-3.0/plug-ins/control/RedPitaya-Support/
Last edit: Percy Zahl 2019-12-18
For the benefit of future customizing Developers, here is a comprehensive list of "apt-get install" commands issued to get GXSM3 compiled and built:
Thanks!
See also the "Installation Knowledge" discussion thread -- I keep it updated:
https://sourceforge.net/p/gxsm/discussion/297458/thread/3f0faafe/!
I used to have a similar script, located here, but not updated in a while.
https://github.com/StefanSchroeder/gxsm-snippets
.... One note about GXMS3 and RaspberryPI -- it's is working reasonable well on a RaspberryPI Model 4 using the default Raspbian! I did set that up with a 28" 4k monitor as you certainly need a little real estate for all the windows. For a Highschool student project last summer! Sure not as snappy as on a big bro i9 system, but very usable! I could not ge tthe 3D/GL working for 3D scan views, but not necessary.
greetings
-Percy