Quick update:
Gxsm4 now has a python hook to access or query probe data from the master scan, backported to gxsm3 now as well.
Thus, make sure to have scan window open (last scan) usually you will anyways as of tip control.
Run any GVP, STS, probe, ... manually or via script
Then grab this demo and run it, may tweak what to plot, see last line!
Enjoy!
~~~
import numpy as np
import matplotlib as mpl
mpl.use('Agg') # non interactive, no event loop... read more
Yes you are reading right:
RPSPMC is a life now -- and Gxsm4 is finally moving towards all new hardware with all new 100% FPGA powered engine under the hood!
Unleashing never seen SPM performance , monolytic -- all on one chip again! Complete, PAC-PLL, SPM-CONTROL, ... and the best, we are working on a very open and modular analog most high end to date!!! (no compromizes here!) 1ppm analog precision to come! Merged with the RP's 125MHz RF capabilities....
Get excited now!... read more
All new SPM control hardware 4 Gxsm 4 -- RedPitaya based and a 100% FPGA level core control:
https://github.com/pyzahl/Gxsm4/discussions/8
The Gxsm Team
-P
This workshop aims to bring the SPM user community together to share latest science from HR-AFM to various SPM niche sciences. We discuss capabilities for remote or autonomous control of instruments and analysis of data.
The field of “Scanning Probe Microscopy (SPM)” is continuing to grow into diverse facets of scientific data acquisition. “Home built” or specialized microscope instruments require the control of various types of (nano) positioning mechanisms in combination with line by line imaging. In this meeting we would like to showcase capabilities of existing facilities, and particularly look forward towards new demands and opportunities in the field.
We plan on engaging participants to present their particular application and problems and provide an opportunity to meet the developers of existing facilities (in particular the developers of open source GXSM project *) in a dedicated “hack-a-day” like session — having virtually hands on microscope operation demonstrations.... read more
I like to ask the Gxsm community to help, participate and present again in 2023.
We are in the early planning and workshop proposal phase and do need potential speakers!
FYI: 2023 User Meeting. This year, the User Meeting will be held from April 24 - 28, 2023, and will be virtual.
Please speak up and contact us if you are interested!
-Py
All further code base maintenance will be continued at the transferred SVN at GitHub as of 20220420.
Here:
SPM user community meetup: “hands on open” source SPM software virtual “Hack a day” learning session and future outlook on artificial intelligence driven autonomous SPM
The special workshop is currently scheduled for Wednesday, May 25, 2022, from 8 a.m. to 12 p.m. EST and Thursday, May 26, 2022, from 8 a.m. to 12 p.m. EST
and will be taking place in the context of "The NSLS-II and CFN Users’ Meeting at the Brookhaven National Laboratory" and will be held from May 23 – 26, 2022 and will be completely virtual.... read more
Happy New Year Every One!
There was a big Christmas/New Year's hack happening to bring alive a all renewed cutting edge GTK4 based Gxsm4.
Under the hood this includes a whole lot of porting, cleanups and code reorganizations. Besides primitive the gtk4 porting, parts required reworking functionalities as different -- but potentially better via nicer and cleaner code! And the biggest move to a all new build system called Meson/Ninja making building and maintaining a blast.
A few new or improved GUI features. Besides a minor but refreshed look. And still a few details to be smoothed out. So be careful with production use at this time!... read more
Update on the latest high speed PAC-PLL (Red Pitaya based) Gxsm / MK3-A810 add on with digital hi speed serial link.
After a long struggle redesigning and porting to the latest Vivado 2019.2 Xilinx FPGA development platform the feat it finally done and all seam working fine now.
Under the high speed FPGA hood:
Update:
today merged trunk with Gxsm-3.0-20191124-spmscancontrol-dev
going to Version Gxsm 3.52.0 Map ExplorerHD.
Key Features:
A GXSM3.0 (via python remote) JSON based socket server/client is now operational and a all re-newed fully non blocking "spm-scancontrol" plugin was created -- what implied a major code over haul of the old spm-scancontrol plugin and a few adjustement on the HwI's (MK2 and MK3). Previously injecting "while (event-pending) gtk-main-loop();" calls while scanning -- however, that was not working for the python interface as the "start-scan" subroutine was never returning until scan stopped and thus the python interface was blocked until the scan completed or was stopped by the user... So I had to redesign the whole complex crap using a state machine design with frequent non blocking calls from a "g-idle()" task which have to complete quickly each time.... Just a major task but all good now and to be tested. The issue is I can not use real threads for GUI related stuff -- not thread safe.... read more
GXSM 3.51.11 "Map Explorer" is evolving in SVN and near stable at this time, but please still be advised that it's a major new version with a lot of reworks of old code been modernized, and aload of new features. MK2 users shall resist from updating from default SVN at this time, as not tested with the MK2. MK3 only tested. HOWEVER, big news for Mark2 (MK2) users a all new MK2 DSP code with a first ever RTEnginee4GXSM on Mark2 was brought to life in the past days. It brings a hug boost in performance under the hood due to levering DSP idle time in a much more extensive and multitasking manner and thus freeing up valuable real time for critical data processing! Very well functional and ready for testing: https://sourceforge.net/p/gxsm/svn/HEAD/tree/branches/Gxsm-3.0-20191105-MK2-RTE-backports-devel/... read more
V3.50.2 features now a automatic "world map" management (per scan channel) option. This is only enabled when the "RAD" function found in the SPM Scan Control Window is enabled. Not recommended for minimalistic or low memory systems as this performs full data remapping conversions at scan start for every channel and may take noticalble extra time on slow machines and in particular with large scan data sets.... read more
Now going to V3.50.1 with latest features in SVN tested OK.
New: at scan start previous image data (if overlapping in any means) is remappe/interpolated to new scan geometry and shown while been updated with new settings while scanning.
One of the key idea for this is not only to "look nice" and get a better view rigth away, but to potentially have a "position template" for molecules, etc. if preparing for rescanning partial regions using the Sub-Line-Scan (SLS) mode for selected region(s). This way a template is available right away and no need to eventually rescan at high resolution in STM mode everything -- slow for a high line count plus pointless usually in STM.... but ncAFM may reveal local details now easy to navigate to and select....... read more
Important note for production use -- please postpone any updates from SVN.
WARNING: Temporary experimental code in SVN for testing purpose.
New feature of mapping any previous scan data to new scan geometry as possible is under evaluation. Feel free to test and report any issues.
UPDATE: New code/recoded parts stabilized and tested. Still please use with extra caution.
-Py
After real work testing found to be good and even better than ever!
Merge from branches/Gxsm-3.0-MK3-rtl-devel, code name "Next Level RTEngine", V3.50.0 to trunc (main stream version) is completed.
New versatile MK3 DSP real time engine:
How and what and why did this happened??
After some super productive long hacking nights it happend:
The all new RTENGINE4GXSM -- a new DSP RT scheduler -- is reality and already undergo first very positive lab tests!
Why? The need to more and particular more efficient use of DSP hard real time resources to serve short simple but high rep rate bursts of interrupt subroutine requests for high speed serial data package transmissions used for communication on a hard real time pixel rate basis, needed to finally make a digital link to the RedPitaya FPGA happen. Up 8 32bit channel can be boosed over fully bidirectional currently in a fraction of the time between "pixels". (~0.1ms) 1..5MHz McBSP serial clock -- possibly even faster pushing it. (Note: that needs a little custom interface hardware for line drivers going over CAT6 cable)... read more
Work on a final digital real time serial Link between the RedPitaya and MK3 is now completed and working.
-- WARNING -- : EXPERIMENTAL DSP CODE : but assumed to be stable if the new feature is not enabled.
Prooven reliable up to 6.25 MHz serial clock using a 4ft CAT6 cable. Default is set to 1MHz, plenty for even regular and fast STM scan speeds no hassle:
Currently transferring 8 32bit channels, while at this time only 4 are used for FPGA Phase/Freq/Ampl/Exec in BRAM Loop Transfer Mode. Selec: [Phase,Freq].
Use 10/16.8ms setting.... read more
Just completed adding a realtime resonance/tune curve fitting to the Inet Json RedPitaya Plugin scope in tune mode. Display after 15 first samples first fit data.
This new feature needs libgsl-dev package as using Lib GSL for Levenberg-Marquardt fitting method with geodesic acceleration.
With the introduction of new real time monitoring feature in Version 3.49.1 "Defender of the Electron" -- trying to do better! More visual realtime feedback on probe status and signal conditions... It's just a beginning of some ideas and still experimental but tested OK.
Besides several minor addition and tweaks a new plugin so far name Probe-HUD -- still having it's own decoration less window (move via Window-Key + LMB) -- desigend eventually to be used dynamically as temporary scan overlay, etc...... read more
Just a hint from the developer:
Recommending to use a lighter theme for the Gnome/Gtk3 desktop.
For a more efficient/responsive and faster less animated theme, try for example "Xfce Evolution" variant "Crux".
This on has no "animations" for activting a dialog and repainting all the elements in a different shade plus the layout is more compact and saves desktop space as well.
See here:
https://www.gnome-look.org/p/1191436/
or
http://www.itgroup.ro/WSX/browser.htm?.landingpage=wsx_content/en/linux/xfce-evolution.html#wsx-backclear... read more
A Gxsm-3.0 stable release tag copy was created for
Gxsm3 Version 3.48.0 Code Name "Proton Sword"
in SVN under tags/Gxsm-3.0-20180515-stable
This version includes several details eveloved over the past 8 month. And recent GUI addition related to a finer "Autosafe" channel level selection controls. Several math/plugins were optimized, evolving NC-AFM simulation plugin, advanved addition and featured for image export including legend details/options and much more.... read more
Hang in tight:
Gxsm-3.0+MK3-A810 will soon get a explorative new high-speed AD/DA+fast processing addition, completely independent but synchronized to the MK3. Looking far into the MHz regime... Guess what -- explanding the frequency detection range for NC-AFM (but not only) -- fully scalable for using an array of those new modules.
-Py
Created copy/tag: svn/tags/Gxsm-3.0-20171027-stable
For Gxsmm-3.0 V3.47.0 Action Eclipse -- minor tweaks, import plugin addition, python template script additions, optimized stich open mode.
Be advised: current trunk SVN will be more experimental for the coming weeks and will require more frequent DSP code updates to stay in sync. Also new direct DSP based digital IO is explored with intend of pixel based external data synchornization options. Alongside with new developments for using multiple (digital) external data/signal sources along with the MK3 as scan master.... read more
With 3.47.0 "Action Eclipse" not much changed visually. Added default action/control python script templates -- more to come. And much more planned on the python level part automated instrument control side.
However, a key addition/new control level on kernel module basis was implemented. Effecting only specific interaction with the MK3 signal control/management topology. So far signal control/management had to be restricted to exactly one task -- and was/could not be enforced. Else missleading signal read back could be the result.
Most users won't care as normal operation is not effected.... read more