Not wrong, but not the latest any more even I have not bumped up the Version Number since the move. Some new features: back-ports from Gxsm4 related to pyremote and other details are new. And I just made the adjustments for MOVE SPEED for MK3.
I committed the patch to the for some time now official and latest Gxsm3 at GitHub as we moved it over a year ago there -- the SF SVN is absolutely outdated, behind and left as it is: https://github.com/pyzahl/Gxsm3 PS: if you are adventurous you may play even with Gxsm4 (still need to forward patch this fix so), it fully supports the SRMK2/3, but is less tested and may have some issue in details. As we are moving on to a new hardware platform. Read more at https://github.com/pyzahl/Gxsm4
Glad you found it, sorry for the delay, was busy and not checking here. I'll look into patching the SVN accordingly. Now more focused on Gxsm4 and the next gen all new controller RPSPMC! But will do my best to maintain Gxsm3/SR-MK2/3 support.
Yes this is a known "issue". Move Speed calculations assumes or uses the same gain as XY-Scan. If you need a exact move speed, you need to compensate by the ratio between XY Scan vs XY Offset Gain.
added authors mapping
I have seen this one older debian system. This seam to be a desktop integration issue with the system/distro. To my best knowledge this not a Gxsm4 or meson problem. And I also found you can simply ignore it, it seams to work anyways! FAILED: install script '/usr/bin/update-desktop-database -q /usr/local/share/applications' exit code 1, stopped
I have seen this one one older debian/desktop integration issue with the system/distro. To my best knowledge this not a Gxsm4 or meson problem. And I also found you can simply ignore it, it seams to work anyways! FAILED: install script '/usr/bin/update-desktop-database -q /usr/local/share/applications' exit code 1, stopped
I looked up the (ThorLabs) KIM101. Key question is, how are you controlling this? Via python / USB? I do not see any direct trigger or control "input", digital or analog. What could be made to be activated/deactivated at DSP/real time level with some tweaks.. Did you tested that? Key question is the response time here all over and if that is going well at python time scales what is around 20..50ms at best. This not intended to be real time. What do you need or in other words: How fast are you moving...
There is a gxsm build in python script accessible via templates lib from the python console as part of the code collections in the "watchdog" template you may use and modify a copy for your needs: accessible via Py-Console Menu -> Action -> Control -> Watchdog see also here for the gxsm source location, line 407ff in (embedded templates): https://github.com/pyzahl/Gxsm3/blob/master/plug-ins/common/pyscript_templates.h Keep in mind: a) no hard real time via python, only control hi level actions and...
There is a gxsm build in python script accessible via templates lib from the python console as part of the code collections in the "watchdog" template you may use and modify a copy for your needs: accessible via Py-Console Menu -> Action -> Control -> Watchdog see also here for the gxsm source location, line 407ff in (embedded templates): https://github.com/pyzahl/Gxsm3/blob/master/plug-ins/common/pyscript_templates.h Keep in mind: a) no hard real time via python, only control hi level actions and...
There is a gxsm build in python script accessible via templates lib from the python console as part of the code collections in the "watchdog" template you may use and modify a copy for your needs: see also here for the gxsm source location, line 407ff in: https://github.com/pyzahl/Gxsm3/blob/master/plug-ins/common/pyscript_templates.h
3.11.2 in gxsm4 on Debian arhf.. Just to make sure, the python console window or plugin is not available at all you say or some thing iffy with it? This sounds like a library issue/not found etc. either at compile time, not build, OR what I suspect a ldpath issue and the runtime at plugin load fails finding the library and the plugin won't load then at all. Start Gxsm with full debug options: gxsm -D 10 -P 10 and digg in the output for the the pyremote plugin name and see if there are errors pointing...
Hi Nick, I do not recall the exact details out of my head, but I recall some thing major been incompatible < 3.11 -- so I am afraid we can not support < 3.11 any more. There were some macros to patch various changes/call back names, etc, and I cleaned all that historic junk up... You may dig into git history... likely the same similar issues you want the old code on the other side. sorry. PS: Try to move forward only and figure out the new ways! What exactly is not working with latest Python? Within...
I do not know how your approach mechanism is working in detail. The GXSM or SRanger based auto approach is a two step process: enable feedback and wait/watch it it gets into regulation or fully extends Z if in regulation, process completed. END. Ready to scan. if not retract Z piezo (fine) all the way then perform N coarse steps in Z (N steps shall be less than the Z fine range + plenty of safety room) repeat with enable feedback again.... THUS the END condition is found by this method safely. Any...
Just a note: how fast are you trying to scan? What is the Gxsm main window status line showing while scanning for the FIFO fill? The USB data transfer of USB2 and other critical data is shared and if you exceed 100% (stay below 50..70% to be safe) things get iffy and data is been lost -- in that case Gxsm looses the data stream and will halt. There is no automated limiting in place usual STM is typically way slower. But AFM in air or other methode may exceed the limits which are non trivial to estimate...
Not any more as the Python interpreter is now running in it's own thread. Gxsm is not effected by time.sleep(). However, you won't be able to "force stop" the python script while it is sleeping. -P
Hello, I am not exactly sure exactly about your plan, but via Gxsm python interface you may adjust the Bias to any value or program a ramp, or what so ever as you can set the bias using simply the gxsm python console. Example to ramp bias from 0 to 5V in 0.1 steps every 0.1s -- cut and paste this into the gxsm python console and run it! No need for any proprietary matlab. You also may use/combine this and manage any external "IO" python can access -- this said, everything is possible! import numpy...
Hello, I am not exactly sure exactly about your plan, but via Gxsm python interface you may adjust the Bias to any value or program a ramp, or what so ever as you can set the bias using simply the gxsm python console. Example to ramp bias from 0 to 5V in 0.1 steps every 0.1s -- cut and paste this into the gxsm python console and run it! No need for any proprietary matlab. You also may use/combine this and manage any external "IO" python can access -- this said, everything is possible! import numpy...
Hello, I am not exactly sure exactly about your plan, but via Gxsm python interface you may adjust the Bias to any value or program a ramp, or what so ever as you can set the bias using simply the gxsm python console. Example to ramp bias from 0 to 5V in 0.1 steps every 0.1s -- cut and paste this into the gxsm python console and run it! No need for any proprietary matlab. You also may use/combine this and manage any external "IO" python can access -- this said, everything is possible! import numpy...
Now for Gxsm4 and Gxsm3: probe data access from python!
Now for Gxsm4 and Gxsm3: probe data access from python!
Make sure you do not have a version clash between the gxsm build system python/numpy and a virt env, that is asking for trouble. Not exactly sure so. It should run python/numpy as of the .gxsm/python/VEnv... folder. If you do anything odd/mixing versions beyond that, no exact clue either: But as you know gxsm has compiled in pthyon support/structures and if there is a major version incompatibility you may ask for trouble a like! Thus I strongly recommend to NOT use a major (or any) different python...
Make sure you do not have a version clash between the gxsm build system python/numpy and a virt env, that is asking for trouble. Not exactly sure so. It should run python/numpy as of the .gxsm/python/VEnv... folder. If you do anything odd/mixing versions beyond that, no exact clue either: But as you know gxsm has compiled in pthyon support/structures and if there is a major version incompatibility you may ask for trouble a like! Thus I strongly recommend to NOT use a major (or any) different python...
I had a similar issue with numpy and un-checking, while very strange as numpy is not used at this point... I found I had a broken (after updates I think) up virtual python environment setup in .gxsm3/GxsmPythonVenv and after deleting it (rm or mv GxsmPythonVenv folder so Gxsm won't use it) the problem disappeared. May be you have a similar issue? I did not yet tried to recreate it... 1) No -- you'd need to recode this or better add an option. OR what I do if I do not want to autosave, simply uncheck...
I had a similar issue with numpy and un-checking, while very strange as numpy is not used at this point... I found I had a broken (after updates I think) up virtual python environment setup in .gxsm3/GxsmPythonVenv and after deleting it (rm or mv GxsmPythonVenv folder so Gxsm won't use it) the problem disappeared. May be you have a similar issue? I did not yet tried to recreate it... 1) No -- you'd need to recode this or better add an option. OR what I do if I do not want to autosave, simply uncheck...
UPDATE (there was never an issue, I had a messed up gxsm3 python VirtEnv -- all good - -problem solved by deleting broken GxsmPythonVenv!): Sorry, my bad. This is not yet 100% back ported to GXSM3, a feature Gxsm4 functional with Gxsm4! But the latest GIT has a few check buttons enabled in Gxsm3 (mainly do need to assign the id's via GUI building (simple), refer to the code where it is enabled). It works via the "gxsm.action()" method and has two action ids: one for ' CHECK-'... and one for 'UNCHECK-...'....
Sorry, my bad. This is not yet 100% back ported to GXSM3, a feature Gxsm4 functional with Gxsm4! But the latest GIT has a few check buttons enabled in Gxsm3 (mainly do need to assign the id's via GUI building (simple), refer to the code where it is enabled), but there is an issue with "checking vi a script", causing a odd crash (gxsm3 only) -- I had not time to resolve this yet. It works via the "gxsm.action()" method and has two action ids: one for ' CHECK-'... and one for 'UNCHECK-...'. See screenshot!...
I suggest to simply check the "autosave" box in any STS/GVP/... folder. And stick to the default auto file naming conventions based on the "master" (previous) scan name for auto save STS data. There is no partial "probe" at this time. Aborted scans, yes. One option would be to delete saved aborted scans data files. Anyways, not sure about your process or planning and aborting (script controlled??). Note; YOU CAN via script check/uncheck the auto safe options(s)! May be that helps? You can only query...
I suggest to simply check the "autosave" box in any STS/GVP/... folder. And stick to the default auto file naming conventions based on the "master" (previous) scan name for auto save STS data. You can only query a path from a loaded/saved scan channel. There is currently no way to "query" or "set" probe data file names/path as this is a plain text file export. However I have future plans to make (most recent) probe data as in GXSM memory directly python accessible as this is most useful. The main...
I suggest to simply check the "autosave" box in any STS/GVP/... folder. And stick to the default auto file naming conventions based on the "master" (previous) scan name for auto save STS data. You can only query a path from a loaded/saved scan channel. EXAMPLE CODE for name query and path/name/... separations: from string import * import os import time #folder = '/home/pzahl/BNLBox/Data/Percy-P0/Exxon-Yunlong/20220401-Cu111-PP-TS-prev-warmup65C/' full_original_name = gxsm.chfname(0).split()[0] postfix='X'...
Hi Bugrahan, I also looked up this other patch, they have been all committed to git right away after locating the issue. I am currently on vacation and can not test it again, but I am 100% sure there have been no further changes. Not sure what is happening, also all later Gxsm3 updates have not been related to any hardware, mainly addition to the pyremote infrastructure. Double check you do have a recent DSP code running! I did not adjusted any version numbers, thus you won't see any difference besides...
Hi Bugrahan, I also looked up this other patch, they have been all committed to git right away after locating the issue. I am currently on vacation and can not test it again, but I am 100% sure there have been no further changes. Not sure what is happening, also all later Gxsm3 updates have not been related to any hardware, mainly addition to the pyremote infrastructure. Double check you do have a recent DSP code running! I did not adjusted any version numbers, thus you won't see any difference besides...
If you are talking about this patch, I recall to have that "officially" patched in the main git. if (feedback_mixer.mode[mi] & 0x10) // negate feedback source? Else please remind me on details. Not sure what was related to lift mode. -P
If you are talking about this patch, I recall to have that "officially" patched in the main git. if (feedback_mixer.mode[mi] & 0x10) // negate feedback source? Else please remind me on details. Not sure what was related to lift mode. best regards -Percy Dr. Percy Zahl Email: pzahl@bnl.gov Center for Functional Nanomaterials WWW: http://www.bnl.gov/cfn Bldg. 735 - NC Brookhaven National Laboratory Work: +01 (631) 344-2968 Upton, NY 11973-5000, USA .^. /V\ //G\ Visit Gxsm now! Unlimited and free SPM+...
@stm I have not touched nor installed that in a decade... just using my old install (working fine on latest Debian). Well, I guess this is beyond Gxsm support in some aspects. Anyways, I can not really encourage any MK2/3 code hacks by "novices" as it is squeezed on the DSP at 100% capacity of the on chip fast RAM and even adding a line or two in fast code sections will fail the linking. Just as a warning. Sure can be counter acted via stripping "not utilized code/functions" for a particular project......
With the MK3 PLL the dFreq is stored as image, but the center Frequency F0 is also stored as meta data in the NetCDF file. So the absolute value can be always reconstructed. The reason for using dF is manifold, one is simply precision, the other no need for images.
Just commenting on this: a) the Mover Tab "Auto-Approach" is controlling the DSP/hardware level auto approach mechanism. What is a cycle of Feedback ON, check for ZS fully extended or in regulation (done and finished), else ZS retracting via inverted feedback. Coarse steps, and repeat checking.... This can can start/stop this via python only. (Unless you recode the DSP, at you fingers if you wish, C code -- but this is hard core low level, be warned) b) You can create your own on a "slow" python...
I highly recommend to use GVP as you started to explore already as this gives you any possible options and freedoms (the FZ dose not more than creating the vectors for you from a simplified parameter inputs and my be to simple for your needs). What is saturation? The reading? Z? Keep in mind: you ALWAYS start at the current Z and if the available range towards the Z-limits is insufficient it can not do more than hitting the limits = saturation. a) move/center Z with Z-Offset manually to have sufficient...
I highly recommend to use GVP as you started to explore already as this gives you any possible options and freedoms (the FZ dose not more than creating the vectors for you from a simplified parameter inputs and my be to simple for your needs). What is saturation? The reading? Z? Keep in mind: you ALWAYS start at the current Z and if the available range towards the Z-limits is insufficient it can not do more than hitting the limits = saturation. a) move/center Z with Z-Offset manually to have sufficient...
I highly recommend to use GVP as you started to explore already as this gives you any possible options and freedoms (the FZ dose not more than creating the vectors for you from a simplified parameter inputs and my be to simple for your needs). What is saturation? The reading? Z? Keep in mind: you ALWAYS start at the current Z and if the available range towards the Z-limits is insufficient it can not do more than hitting the limits = saturation. a) move/center Z with Z-Offset manually to have sufficient...
I highly recommend to use GVP as you started to explore already as this gives you any possible options and freedoms (the FZ dose not more than creating the vectors for you from a simplified parameter inputs and my be to simple for your needs). What is saturation? The reading? Z? Keep in mind: you ALWAYS start at the current Z and if the available range towards the Z-limits is insufficient it can not do more than hitting the limits = saturation. a) move/center Z with Z-Offset manually to have sufficient...
FYI: all MK2/MK3 DSP "firmware" (well not really a firmware, but the spmcontrol DSP software complied into COFF (.out files) to be flashed, the DSP firmware is a very low level and simple DSP kernel code, loader and the A810/PLL libs, never been touched by the Gxsm project). The DSP spmcontrol software is extremely mature and has not been modified in the last 4+ years or so -- at least nothing of concern or any version incompatibility with GXSM. I may have done a custom version/adjustment of details...
Update on RPSPMC -- Gxsm4 is going al lnew hardware with all new 100% FPGA powered engine under the hood!
That would be here: Gxsm3/plug-ins/hard/sranger_mk2_hwi_mover.C
do you have the "DSP" running at max clock, aka turbo mode? the configurator tool has a DSP Manager app, select the fast clock (688MHz or so) and confirm.
do you have the "DSP" running at max clock, aka turbo mode? the configurator tool has a DSP Manager app, select the fast click and confirm.
You must use the PLL optimized DSP code version. Get Outlook for Androidhttps://aka.ms/AAb9ysg From: discussion@gxsm.p.re.sourceforge.net discussion@gxsm.p.re.sourceforge.net on behalf of drew dvin@users.sourceforge.net Sent: Wednesday, September 4, 2024 7:55:59 PM To: [gxsm:discussion] 40919@discussion.gxsm.p.re.sourceforge.net Subject: [gxsm:discussion] Res-Phase jumpiness Hello all, I am using GXSM3 with the SoftDB MK3-PLL to set up frequency modulation feedback. I am first testing with the SoftDB...
Please use the PLL optimized DSP code.
Is there any "FB-SPM-control" firmware flashed to the DSP? It ignores SR devices with any other DSP code. Further once steps: once it finds a valid SPM-control on the DSP, it will check for the correct version.
Glad to hear. Anyways I do not understand the actual cause, I suspect some dconf schemata missing for the plugin in the version you are using. May I ask: You use a pre-build .deb package, the live image system install or the latest git-hub and build it yourself?
Dear Takayuki-san, I am thinking about what may be causing this startup crash after "PCS init: looking for org.gnome.gxsm3.pcs.plugin-libinet-json-external-scandata.rp-pacpll-phase-hold-am-noise-limit array_flag=0 pcs_count=0" but do not have a good idea. Nor I have ever see this problem. This "External PAC-PLL (RedPitaya control) " plug-in is always loaded, used or not. If the error is as of this one (may be a missing schema, but that usually is been indicated clearly). You can try to simply delete...
Dear Takayuki-san, I am thinking about what may be causing this startup crash after "PCS init: looking for org.gnome.gxsm3.pcs.plugin-libinet-json-external-scandata.rp-pacpll-phase-hold-am-noise-limit array_flag=0 pcs_count=0" but do not have a good idea. Nor I have ever see this problem. This "External PAC-PLL (RedPitaya control) " plug-in is always loaded, used or not. If the error is as of this one (may be a missing schema, but that usually is been indicated clearly). You can try to simply delete...
Dear Takayuki-san, I am thinking about what may be causing this startup crash after "PCS init: looking for org.gnome.gxsm3.pcs.plugin-libinet-json-external-scandata.rp-pacpll-phase-hold-am-noise-limit array_flag=0 pcs_count=0" but do not have a good idea. Nor I have ever see this problem. This "External PAC-PLL (RedPitaya control) " plug-in is always loaded, used or not. If the error is as of this one (may be a missing schema, but that usually is been indicated clearly). You can try to simply delete...
Hi, what do you need to plot? At the moment the only plots I am able to make are amplitude-distance but am still unable to generate the expected amplitude-distance curves, ??? If you need any custom signal generation you may also use the "GVP" tab to program any action schemes. -P
Oh OK that Retract CI value. Leave that positive, some where 100..300. Q: Is your Z-Scan going the direction as required when you simple test the feedback? Do this test: 1) Just connect Bias (OUT6) -> Tunnel Input Signal (IN0) to simple emulate a current via Bias. 2) Put Current Setpoint to 1nA or so (assuming simple 1nA / Volt for testing) 3) Put Bias = 0V => This should move Z-Scan all the way to fully extended (+10V for positive polarity) 4) Put Bias > "1V", say 2V -- what is > 1nA, this should...
A few points: A) make sure you Z-Polarity is set correctly, this is what determines if + or -10V is fully extended. (Gxsm3 -> preferences) Must restart Gxsm after adjusting. Then it will ask you to confirm to reconfigure the DSP (MK2/3) accordingly. (DO NOT RESTART THE DSP!) B) All CP, CI must be positive. Else you cause internal "confusions"... only for vert special purposes or testing they may be negative in linear transfer mode. C) "Retract CI" is a "speedup" using negative CI (CP=0) temporary...
This is never happening on any of my systems in years. Not while regular scanning. Please list your setup details -- at minimum this: Computer type/CPU/memory/Linux System Version/Swap Size/Free disk space Gxsm version/build/install type? (via Package/Ubuntu GXSM ISO/self build and installed/etc.?) Hardware: MK2 or MK3? Scan setup, size, scan speed... PS: The very only thing may happen or go wrong is if you push the scan speed to the combined limits of the USB bandwidth -- what is a complex figure...
This is never happening on any of my systems in years. Not while regular scanning. Please list your setup details -- at minimum this: Computer type/CPU/memory/Linux System Version/Swap Size/Free disk space Gxsm version/build/install type? (via Package/Ubuntu GXSM ISO/self build and installed/etc.?) Hardware: MK2 or MK3? Scan setup, size, scan speed... PS: The very only thing may happen or go wrong is if you push the scan speed to the combined limits of the USB bandwidth -- what is a complex figure...
This is never happening on any of my systems in years. Not while regular scanning. Please list your setup details -- at minimum this: Computer type/CPU/memory/Linux System Version/Swap Size/Free disk space Gxsm version/build/install type? (via Package/Ubuntu GXSM ISO/self build and installed/etc.?) Hardware: MK2 or MK3? Scan setup, size, scan speed...
OK. BTW: You actually can reconfigure the limits (lower included) via Gxsm I found: Open the configure Dialog and type in the value you want, BUT do not hit Enter or do anything else, just click OK and it takes it! PS: I have not yet figured out why it complains for all limits at -10 when hitting enter, or do anything else... and set it back to -10 then. PPS:: Fixed the config dialog issue. In git now. The Entry Spinner-Limits/updates were interfering, removed spin feature from config as not needed...
OK. BTW: You actually can reconfigure the limits (lower included) via Gxsm I found: Open the configure Dialog and type in the value you want, BUT do not hit Enter or do anything else, just click OK and it takes it! PS: I have not yet figured out why it complains for all limits at -10 when hitting enter, or do anything else... and set it back to -10 then. PPS:: Fixed the config dialog issue. In git.
OK. BTW: You actually can reconfigure the limits (lower included) via Gxsm I found: Open the configure Dialog and type in the value you want, BUT do not hit Enter or do anything else, just click OK and it takes it! PS: I have not yet figured out why it complains for all limits at -10 when hitting enter, or do anything else... and set it back to -10 then.
Send me what all "unusal limits" need and I'll have a look.
There is some odd issue, a more generic gxsm wide issue effecting all neg limits, been reset to -10 when edited... For a work around, do NOT use the dialog to adjust the limits, BUT use the system tool dconf Editor. See screenshot attached. Find the setting as shown and adjust the limits as desired (I put +/-20 in for a test). Do this before starting gxsm3 -- or restart it after adjusting as it does not get a change notification if you edit it there!
Try starting gxsm3 with debug option -P 10 (may use -D 10 -P10 for even more details) as shown below and see if you see messages from "pyremote" listed -- see a potential missing lib error at load time: ~~~ percy@ltncafm:~$ gxsm3 -h no -s -P 10 GXSM3 comandline option parsing results: => xsmres.HardwareTypeCmd = no => xsmres.DSPDevCmd .... = (null) => xsmres.UnitCmd ....... = (null) => xsmres.force_config .. = 0 => force gxsm defaults .. = 0 => debug_level .......... = 0 => pi_debug_level ..........
This sounds like the related plugin is missing -- possible was not installed as of a compile issue, may be missing lib, etc? Have a look if you can find the libpyremote.so plugin build and the lib installed, depending on your install mode in usr/local or usr: /usr/[local]/lib/gxsm3-plugins/common/libpyremote.so
I have to check if there is (must be, just not sure it it is at -10V) limit for the "neg limit" setting if I understand you right.... hang on...
I have a feeling your device permissions are not set to allow user access. check if $ ls -l /dev/sranger* looks like with rw for all: crw-rw-rw- 1 root root 180, 2 May 14 15:41 /dev/sranger_mk2_2 if not, you can adjust as root manually "chmod a+rw /dev/sranger*" or better permanently fix and automatize via having the rules file installed/copied here: /etc/udev/rules.d/49-sranger.rules This is provided via the sranger package/SVN and can be found here: SRanger/SR_MK2_MK3Pro/kernel-module/src/49-sranger_mk23.rules...
never heard about this or seen such an issue. make sure your computer and storage is not lagging... maybe?
See also my post above "This is very hard to debug..." getting lil messy here sorry... But one more easy check, see screenshot attached here. In DSP Manager App scroll down until you see the task ID018 "Request McBSP transfer". This should be "on Timer" IF NOT SCANNING (automatically) for idle monitoring purpose. (While scanning it is read in realtime matching the scan speed.) The number/counts shall change.
This is very hard to debug for me via this forum... all connections must be right to get started. a) 1st question is: did this ever worked? Proof? b) as I have not made those nor QC tested -- I very sorry, this requires RF measurement skills and dedicated RF / very high impedance measurement /test equipment to debug the actual signals without disturbing them... and this is beyond me to support. I have the equipment at home. Not cheap unless home made -- correctly. c) I can offer you a quality tested...
if in the GXSM Pan-View the dFreq is matching the number in the RP control – and sure when you get data while scanning into those McBSP-xxx channels! In the default startup configuration after connection all is set, you only need to enable the controllers. Particular: OpMode to "Streaming Operation" and make sure channels are set to : "Phase, Freq, [Am,Ex]" (all default) but if you switch to tuning or monitor IN1/2 in Scope mode the transfer is stopped. Gxsm may needs to configured right also, but...
OK glad to hear. If you see data transmission error/spikes -- this is related to incorrect impedance matching for RJ45 -- but may be the PostDoc who build it realized it and did it right (minor adjustments)... I do not have the number in my head, but the inputs need a matching load resistor... can be placed over the IC SMD pins directly. ideally also add in-line resistors also, but works without OK up to 4m cable or so! UPDATE and FYI: I do not know your interface / driver build, if using the PCB...
OK glad to hear. If you see data transmission error/spikes -- this is related to incorrect impedance matching for RJ45 -- but may be the PostDoc who build it realized it and did it right (minor adjustments)... I do not have the number in my head, but the inputs need a matching load resistor... can be placed over the IC SMD pins directly. ideally also add in-line resistors also, but works without OK up to 4m cable or so!
You got the right one, this is it debug.log -- my bad, not the server log... that is only important fort networking issues. So did that happen after startup or after adjusting some settings on your side (what)? I see a Freq adjustment. And controller parameters been changed. CP,CI are in dB -- so make sure not to enter odd values.... up to about -190dB (max slow) and possible not over -10dB at any time needed. I think it should and is not possible to enter invalid parameters causing a "signal 7"...
You got the right one, this is it debug.log -- my bad, not the server log... that is only important fort networking issues. So did that happen after startup or after adjusting some settings on your side (what)? I see a Freq adjustment. And controller parameters been changed. CP,CI are in dB -- so make sure not to enter odd values.... up to about -190dB (max slow) and possible not over -10dB at any time needed. I think it should and is not possible to enter invalid parameters causing a "signal 7"...
a) are there any numbers fluctuating or changing, status cpu %... working? To make sure it is a life first. b) send me a screenshot with OK connection Unrelated to you current issue: I am curious: did you (or who did) build the McBSP interface or where is that from -- as I did not provided it nor anyone else from the Gxsm team -- I first thought I missed some thing here. If it is a 1:1 copy of the in SVN / Gxsm provided -- there is a minor patch required to make it work stable with longer (than very...
While connection monitor on the rp the nginx log file, this may give you and me hints: root@rp-f05aa9:/opt/redpitaya/www/apps/pacpll# tail -f /var/log/redpitaya_nginx/ws_server.log you may adjust the verbose/logging level -- can be done via gxsm GUI, but obviously not when loosing connection right away. So you may need to adjust temporary in the source code the default settings for that. percy@ltncafm:~/SVN/Gxsm3/plug-ins/control/RedPitaya-Support/pacpll/src$ less main.cpp find and adjust (both lines)...
Sorry I missed that detail before in the output: "Web socket connection closed externally" (line of the log) This is not OK. This can mean various things, as the socket connection was dropped on the RP side after the server exiting for some error condition, any of those: a) the FPGA bit file is not the correct version, non existent, or the wrong FPGA/RP type/model. What exact RedPiatya are you using? Must be the 14bit version. Can be either regular Z10 or bigger Z20. The default FPGA bit file in...
Sorry I missed that detail before in the output: "Web socket connection closed externally" (line of the log) This is not OK. This can mean various things, as the socket connection was dropped on the RP side after the server exiting for some error condition, any of those: a) the FPGA bit file is not the correct version, non existent, or the wrong FPGA/RP type/model. What exact RedPiatya are you using? Must be the 14bit version. Can be either regular Z10 or bigger Z20. b) In general means the RP support...
Do you think the problem could be in the McBSP connection between the RP and the MK3-A810 or with the installation of the RP FPGA and support software? The output signal and all settings will work even without the McBSP connection -- only the DSP/Gxsm won't get data while scanning. Everything else will work. However, when I choose a Volume and a Frequency, the In1 Offset is 0mV, the DDS Freq is 0.0000 Hz and when I connect Output2 of the RP to an Oscilloscope I see nothing (just noise). No idea right...
Hi, OK, so you got that interface via Thorsten... did not know. Please have a look and follow the steps in the pdf I attached -- there are detailed instruction to get started! Do you really have set a amplitude right (put in 300 mV) and set the Frequency to 32000 Hz or so. Keep both regulators Ampl Phase OFF (not checked) to get started -- manual control. I see in your screenshot operation mode = "INIT BRAM TRANSPORT". That should not normally set to "STREAMING OPERATION" (to get data to GXSM via...
Hi, OK, so you got that interface via Thorsten... did not know. Please have a look and follow the steps in the pdf I attached -- there are detailed instruction to get started! Do you really have set a amplitude right (put in 300 mV) and set the Frequency to 32000 Hz or so. Keep both regulators Ampl Phase OFF (not checked) to get started -- manual control. Why this: ??? " Ref. frequency in the MK3-PACPLL control is set to zero."
Hi, OK, so you got that interface via Thorsten... did not know. Please have a look and follow the steps in the pdf I attached -- there are detailed instruction to get started! Do you really have set a amplitude right (put in 300 mV) and set the Frequency to 32000 Hz or so. Keep both regulators Ampl Phase OFF (not checked) to get started -- manual control.
Hi, the "analog" out option is not any more enabled and obsoleted -- was only for early testing and very limited in resolution. You will need the digital hi speed / real time serial link (RP 2 MK3 via McBSP) I designed. I do have a small number of prototypes I can provide at cost. Need to check myself and get a set ready. There will be a high speed serial link with drivers attached to both sides, one on the RP and one will plug between the MK3 and A810. Then a connection with two identical RJ45 (network...
What do you mean with McBSP connected -- this is not that "simple" and requires a special interface on both ends to work. See other message. Also for this you do need to enable the McBSP and a few settings via the mk3_spm_configurator.... for the connection to get a life. Oh, and do not try to do anything with that "web GUI" what is totally outdated and obsoleted by now. The Gxsm "Inet-JSON" plugin is all you need.
What do you mean with McBSP connected -- this is not that "simple" and requires a special interface on both ends to work. See other message. Also for this you do need to enable the McBSP and a few settings via the mk3_spm_configurator.... for the connection to get a life.
What do you mean with McBSP connected -- this is not that "simple" and requires a special interface on both ends to work. See other message.
Hi, the "analog" out option is not any more enabled and obsoleted -- was only for early testing and very limited in resolution. You will need the digital hi speed / real time serial link (RP 2 MK3 via McBSP) I designed. I do have a small number of prototypes I can provide at cost. Need to check myself and get a set ready. There will be a high speed serial link with drivers attached to both sides, one on the RP and one will plug between the MK3 and A810. Then a connection with two identical RJ45 (network...
Make sure the Z polarity is correct. Else you may have mechanical instabilities.
I am not sure, can you describe that behavior more clear? Gxsm at startup per design will not touch any DSP settings (unless you confirm a polarity change) or sure change parameters, etc. Also ADC's are never on or off. They are all 0V at power up. And the feedback is off at that point. PS: Restarting or even killing or (even restarting the PC) while the DSP stayed powered on will NOT at all effect anything what the DSP does, it will even keep scanning - -only you loose the data stream and will have...
Just in case: you have to restart GXSM after adjusting Z-polarity in stetting . But NOT the DSP. Gxsm will only adjust the DSP settings only once at Gxsm startup (there will be a message dialog informing/warning about it).
Hi! Please check you Z-polarity (not all systems are the same) settings in preferences -- i.e.if the feedback on with current setpoint settings > the current noise level is actually moving your tip "Z-Scan" towards the sample all the way (when coarse disengaged). And retracts Z all the way when Setpoint = 0 (as there is always noise it will retract) -P
Hi, three are various options, also do not know your data/issue to fix. Nor the purpose or intend like quick view or publication in mind. primitive line by line, plane, hi pass, ....
Tested myself and pushed to git now.
Edited/fixed the code snipped... I'll put it in GIT next.
Here is a quick "blind" (=untested) hack add on for to read all AICs (IN0..7) via RTQuery: Gxsm3/plug-ins/hard/sranger_mk3_hwi_spm.C /* ... "M" : AIC[1,2,3] // MK2 hack "N" : AIC[4,5,6] // MK2 hack "L" : AIC[0,6,7] // MK2 hack */ //#define MK2_SCAN_STRUCT_DEBUG gint sranger_mk2_hwi_spm::RTQuery (const gchar *property, double &val1, double &val2, double &val3){ const gint64 max_age = 50000; // 50ms const gint64 max_age_as = 250000; // 250ms static gint64 time_of_last_xyz_reading = 0; // abs time in...
I mean the RTQuery (HwI member function, default prototype) is only providing 3 return values. But I can easy create a modified version.... But if you are OK with 3 readings at once all is good. As you see the readings (all 8) are updated at once, and with a limited update rate (buffered) to prohibit USB/DSP overload issues if some one tries to poll arbitrary fast. Thus a consecutive query via "M,N,L" will most likely give you the last reading of all value sampled at the exact same time anyways!
Very good! I do not see any issues if it looks reasonable and nothing obvious swapped or so. PS: If needed: with few more hacks I could make it also return a vector of all values at once -- only this RTQuery function is not designed to do so.