Ubuntu and GXSM upgrade to 14.4 and 3.02

Help
2014-08-28
2014-09-17
1 2 > >> (Page 1 of 2)
  • Camiel van Hoorn

    Hi,

    I was using gxsm2 on Ubuntu 12.4 with the MK3-PLL spm controller. Today I upgraded my system to Ubuntu 14.4 and gxsm 3.02. I also updated the signalranger firmware to the newest version.
    In the pan-view window the signal from the AFM position detector is read wrong. The I-avg value is stuck at -0.0055 nA. If i unplug the connector the signal changes to -0.0013 nA. So it is responding. I used the A810 AD/DA monitor application to figure out what is wrong. There the Ch-0 shows the right voltage of about -1.3 V. I think it is some gain issue. But I did not change anything in the settings.
    Someone any idea what could be wrong? And how to solve this?

    Thanks a lot!

     
  • Percy Zahl

    Percy Zahl - 2014-08-29

    Hi! Sorry for the inconveniences.There have been a lot of developments recently.

    Current it Gxsm 3.10 Signal Master Evolved (out of SVN). The live DVD and ppa's are always a little behind.

    There are a few configurations effecting the "PanView Reading for "nA":

    a) The Gxsm Preferences (Instrument/nAmpere2Volt = 1.0 for no gain with repect of Volts to "nA")

    b) With the introduction of the Signal Master now the Signal to be used must be configured as RMS/AVG Module input. The obvious default is "In0" and not eventually MIX0. I temporary used the mixer channel, those have a different internal scaling with respect to 32bit (+/-15.16 bits for In0) and (+/-23.8 bits for MIX0..3) signals as there room for computation is needed -- all fixed point -- thus you may see a factor of 256 if you use a mixer channel and do not correct for it.

    c) The actual signal definition (dsp_signal.h) -- normally no need for adjustments.

    You may check via the Patch-Rack (mk3-spm-configurator.py script) what is the actual input for ANALOG_AVG_INPUT.

    Also check via the Siganl Monitor the actual reading of the AVG Siganl and if it matches it's input.

     
    Last edit: Percy Zahl 2014-08-29
  • Thorsten Wagner

    Thorsten Wagner - 2014-08-29

    Hi Camiel.
    In any case, the Ubuntu 14.04 64 bit is experimental. So please use the more stable 32 bit Version.
    Thorsten :-)

     
  • Camiel van Hoorn

    Hi Percy,

    Thanks for your answer. In the configurator ANALOG_AVG_INPUT was set to MIX0. I changed it to In0. Now the panview reads the right value. But it says I: in staid of I-avg: and de I-RMS: disapeared.
    The feedback loop is still very slow. Do I have to multiplty the CI and Cp values by 256 then? Or can I change a setting somewhere else to correct for this?
    Afster restarting the MK3 box GXSM was unable to start. I had to resflash the firmware and restart the computer to get it up and running again.

    Would it help to update via SVN to 3.10?

    @Thorsten I installed 32 bit 14.04 and installed gxsm via apt-get.

    Thanks Camiel

     
  • Percy Zahl

    Percy Zahl - 2014-08-29

    Hi!

    yes 3.10 would help with the default settings! I added serious automatic startup configurations and tests to make sure you have a good starting condition without manual extra work.

    Yes, CP and CI are about 256x also and this I kept -- so you work now with typical values around 20..50 -- up to 100 is mostly OK and stable.

    You may need to reconfigure the allowed CP/CI Entry ranges (right click, configure). If you start 3.10 with a NEW account (no old gconf apps/gxsm2 settings) -- only then you will get the new ranges automatically!

    Not sure why your RMS reading is not there.
    But it depends on the actual "q" (IIR filter reading), if that is 0 (FBW) or not available -- then it assumes an older DSP not having RMS available. Try this: enable the IIR and have a setting of not full bandwidth.

    -Py

     
  • Camiel van Hoorn

    Hi Percy,

    I tried both option, but still cant get it to work. When using the 3.02 installation I could set the ANALOG_AVG_INPUT to In0 (in staid of the default MIX0). This works fine until I restart the system. Then I have to apply the changes again, or the program crashes upon startup.
    Before I had to use CP and CI settings between 5 and 10. SO now I can use setting between 1000 and 2000. But it works (I am doing AFM, not STM don't know if that makes a difference)

    I also installed the 3.10 GXSM via SVN ( I did this in a virtual machine for testing)
    Without hardware the gxsm software works.
    When I start gxsm with hardware enabled many popups open en then it crashes. I didn't know how to build the kernel headers manually so I installed the sranger-modules-mk23-dkms via apt-get.

    I hope you can help me out.

    Camiel

     
  • Percy Zahl

    Percy Zahl - 2014-08-30

    a) the latest DSP code (from SVN) has the correct IN0 DSP power up defaults (besides other settings and checks and automatic setups optimized in Gxsm).(But can try to store to flash as well via the signal manager.) Also you do normally never to restart or power cycle the DSP even after a computer restart. Everything, even the feedback, etc... is staying alive also if unplugged from USB! Gxsm will re-connect at any time!

    b) 1000...2000 (and also 5..10) seams very high, but is technically OK if it works stable for you -- you must have a quite low external "loop gain".

    c) many popups??-- hmm, sound like a connection problem. DSP code also updated? Any clue what they say or what is printed on the console last? No need to update the kernel module, in long tiem no change here -- only if you update your system kernle you need to recompile it to matvh that.

     
  • Camiel van Hoorn

    With the DSP code you mean the MK3 firmware? I now flashed the MK3 with the FB_SPMControl.out from svn. That helps a little. I now can start Gxsm with hardware support without crash. But I still get many errors and popups it is complaining about configuration errors. (I lost contact via remote access due to a restart. I can post a screenshot on Monday when I am back to work)
    It also complains about a wrong firmware version. 30.41 was installed, gxsm is built for version 30.43.

    When I installed gxsm via svn I went into the gxsm-svn dir and run autogen.sh. Then make and make install.

    Do I have to do something else to get it to work? via apt-get I had to install sranger-modules-mk3-dkms separately. Do I have to build this from the dir plug-in/hard/MK3-A810_SPMControl

    Camiel

     
  • Percy Zahl

    Percy Zahl - 2014-08-31

    That's a start. Even I am not sure why it misbehaved before, it should just complain about the old DSP code as it did now.

    If you get the DSP binary code or ".out" file (or not really firmware, that would be a different level, but not to worry about.) from here (current SVN):

    pzahl@phenom:~/SVN/gxsm-svn/plug-ins/hard/MK3-A810_spmcontrol$ ls -l *out
    -rw-rw-r-- 1 pzahl pzahl 167691 Aug 20 21:59 FB_spmcontrol.out

    This should get you Version 30.43 with date make 2014-08-18.

    ----- just double checked:

    define FB_SPM_VERSION 0x00003043 / FB_SPM main Version, BCD: 00.00 /

    define FB_SPM_DATE_YEAR 0x00002014 / Date: Year/MM/DD, BCD /

    define FB_SPM_DATE_MMDD 0x00000818 / Date: Month/Day, BCD /

    The configuration "warning or information" is OK and you have to check it's all as you want it later. If all set right it will only show you teh current output configuration as a pure informative dialog at startup.

    Would need to know your detailed SPM setup, HV amp features, etc. -- in particular how you want to deal with offsets. Most simple: Internal/digital (mean no external offset), analog external, or a digital Link to the Smart Piezo Drive HV1....

    don't worry about the kernel module -- this is only a interface to talk to the DSP and was not changed in a while as very universal.

     
  • Camiel van Hoorn

    DSP code version was fixed by powercycle the MK controller. It is now 30.43
    Didnt change much except for that gxsm now crashes on startup.

    This is the system I am using:
    - MK3-pro/PLL controller (august 2013)
    - For contact mode AFM imaging
    - Manual piezo amplifiers connected to output Xs,Ys and Zs (No smart piezodriver)
    - No Ananlog offset adding (set it to false in preference channel) (An offset is added by the piezo amplifier to allow -+ moving of piezo)
    - AFM position detector connected to FB1 (In0) for feedback loop.
    - Ubuntu 14.4 running in VirtualBox virtual machine
    - Gxsm installed via svn
    - sranger-modules-mk23-dkms installed via apt-get

    When I now start gxsm some popups appear and than it crashes (see screenshot3). Probably the popups look like screenshot1.

    I am able to run the MK3_spm_configurator.py script. in the 810 AD/DA monitor the right values are shown in AD/DA In reader. (screenshot2).
    When I start the SPM sginal patch rack the computer starts to run really slow. Like it is a lot of effort to communicate with the controller.

    for now I will use the apt-get installation with manual settings. That works good enough at the moment

     
  • Percy Zahl

    Percy Zahl - 2014-09-01

    screenshot2 -- looks all fine as of what I can see.
    screenshot1 -- some thing is totally wrong with GXSM trying to identify the DSP signal configuration. At this time -- did you had anything else running (the script, etc. accessing the DSP)? Was this the right DSP version?
    screenshot3 -- strange, beyond the segfault nothing unusual.

    But I see you runninng this on a virtual machnine -- well this may be trouble, I did this once for demonstration purpose. To make the scripts, etc working I had to cut down on update refresh/rates significantly (they are not user accessible and fixed normally).

    The issue is the USB stack performance is very poor in emulation and this may cause all kind of odd side effects very hard to predict. For any serious operations I strongly recommend a real native system.

    Regarding the segfault, what I see -- it happens about when gxsm is spawning the PANVIEW -- what indeed is periodically querying (about every 100ms) via RTQuery parameters like current, etc. from the DSP. And if that timeout function take too long to execute and get the data it may get called interleaved (while it's still in progress) and this causes all kind of troubles non intended to happen normally. Also you would be seriously limited in scan speed due to a bad bottleneck in data streaming.

     
    Last edit: Percy Zahl 2014-09-01
  • Percy Zahl

    Percy Zahl - 2014-09-01

    So please -- do us a favor and get a native system install to avoid all these troubles! A VM is great, but hard hardware control and real time a really bad idea. May in a few more years.... was not possible at all just a few years back!

     
  • Camiel van Hoorn

    I was only running this in a virtual machine because I didnt want to screw up my native system. So only for testing. I also tried the Ventiotec gxsm-ubunu combi in a virtual machine and it worked perfectly fine.
    My gxsm 3.02 installation (on native machine) works ok now with the setting changes you mentioned earlier. i only need to multiply the CI and CP values by 256. So I will leave it like this. Maybe update later if I have time.

    Thanks for your help!

     
  • Percy Zahl

    Percy Zahl - 2014-09-01

    Oh understand -- that actually is in general a good idea!
    However, the latest version 3.10 I still highly recommend and I am running it on my Createc LT-STM since I committed the code. There should not be any problem on a native system.

    PS: But I am not using the "Ventiotec Ubuntu based distribution" but as developer always the latest Ubuntu LTS and also stable Debian -- both perfectly fine, 64bit systems. Install to /usr/local as default for builds from SVN.

    Please let me know if you need and further help -- anything related to the "GXSM life CD" I have to forward to Thorsten as he manages those and natively they are always a little behind plus it's hard for us few developers to have "the stable" version, always some thing new and also always some thing eventually to fix... -- would need more project help!

    So all I can do is keep the main trunk SVN as stable as possible, major new constructions are in development branches -- but at merge down time (what recently had to be done) there is always a transition with a few glitches. But I can say now is a good time reached to say V3.10 is a good one :)

    greets
    -Py

     
  • Camiel van Hoorn

    Hi Percy,

    I decided to install the 3.10 version on my main system because the 3.02 also started having problems.
    So I installed a new clean ubuntu 14.4 (lernel 3.13.0-35) 32 bit.
    After installing all the dependencies I downloaded and built the SVN trunk
    Then I stalled the sranger-modules-mk23-dkms via apt-get
    I also have the latest version of the DSP code installed.
    It looks like I am almost there, but stil have some problems. When starting it finds the SRanger MK3 box. but then it comes with a weird error: "HWI-DEV-MK3-I** weird endianess of host (PPC?) not support yet." (see screenshot) Any idear what the reason could be?

    Camiel

     
  • Percy Zahl

    Percy Zahl - 2014-09-04

    It looks your DSP is not correctly programmed.

    a) did you flashed the lastest DSP code using the minidebugger?
    b) did you power cycled (restarted) the MK3 DSP after that?

    GXSM read a wrong MAGIC number or actually 0 from what I see. This means the DSP software "FB_spmcontrol.out" is not running at all or is some thing else.

     
  • Camiel van Hoorn

    I did flash the latest DSP code via the Windows application SRx_Analog810_SelfTest en restarted the box. I think I already did this multiple times.

    Now I did it again and it seems to find the dsp. But terminates with the following error:

    sranger_mk3_hwi_dev::query_module_signal_input_config
    Query_Module_Signal[inpid=4099]: found Sig -1 [v-7557957] *** mindex=-1, signal_id=-1, act_address_input_set=0, act_address_input_signal=284184032
    Segmentation fault (core dumped)

    higher in the console output I found this error:
    ERROR query Signal for Mod-Input[39]: si=-1
    sranger_mk3_hwi_dev::query_module_signal_input_config
    Query_Module_Signal[inpid=12330]: found Sig -1 [v-7557957] *** mindex=-1, signal_id=-1, act_address_input_set=0, act_address_input_signal=284184020

    I found that using the SR3_Minidebuger I can also select a FPGA_File. Could it be that I have to update this also?

    Is there a way to reset the dsp to factory settings? Maybe this helps.

    With the dsp configurator script I can acces the dsp and everything seems to work fine.

     
  • Percy Zahl

    Percy Zahl - 2014-09-06

    I did flash the latest DSP code via the Windows
    application SRx_Analog810_SelfTest then restarted
    the box. I think I already did this
    multiple times.

    Sorry, no this is NOT flashing the DSP at all nor using the the SPM DSP program you need!

    This tool only loads a A180 test program directly from disc -- and won't reflash the DSP!

    Please start up the Minidebugger tool and select the MK3-Pro.

    Then find the FB_spmcontrol.out file for the MK3 and use if for "Write DSP":
    from SVN (Gxsm-2.0) plug-ins/hard/MK3-A810_spmcontrol/FB_spmcontrol.out

    The A810 / FPGA support code you do not need to touch or reflash, if should be factory default and does not need any updates.

    -P

     
    Last edit: Percy Zahl 2014-09-06
  • Camiel van Hoorn

    Hi Percy,

    That could explain something. I will try this next week when I am back in the lab. I was using the SRx..selftest program because Thorsten told me to do so when I updated the firmware earlier. It also had an "reflash firmware" button. After this procedure, gxsm was not complaining about a wrong firmware version anymore so therefore i thought that it was working.

    Hopefully the minidebugger solves the problem.

     
  • Thorsten Wagner

    Thorsten Wagner - 2014-09-09

    Dear Camiel.

    The SRx_Analog810_Selftest does the job as well as the minidebugger which is a little bit more low level. That is why I advice to use the selftest application instead. Please do not forget always to power off and on the controller afterwards.

    As you have a controller with PLL, please use also the tool SPMReset of the softdb PLL application to reenable your PLL afterwards. Again power off and on. If you do not have the application download it following the link www.softdb.com/SignalRangerMk2/SoftdB_SPM_PLL_1_84.exe

    Thorsten :-)

     
  • Camiel van Hoorn

    Ok,
    I did not know about this SPMReset. Could this cause the gxsm crashes? I will try it on monday.
    Last night I followed Percy's procedure again. After restart, gxsm still crashes with the same segmentation fault.
    The strange thing was that when I tried to start gxsm before restarting the DSP it didnt crash. But it crashed when I started a scan.

     
  • Percy Zahl

    Percy Zahl - 2014-09-13

    Is gxsm recognizing the SPM software on the DSP now -- what is the terminal output, the last few lines before it terminates. Not sure if it is a crash or a abort -- if the hardware module detects the DSP but then can not find any DSP with the right software running it will abort GXSM as it can not proceed.

     
  • Camiel van Hoorn

    I think gxsm recognizes the DSP code. The output I get is attached.
    Sometimes it also complains about the MAGIC numbr and terminates. Then I install the DSP code again and I get the output in the attachement again.
    There is still something wrong with the comunication between gxsm and the DSP.

    When I update the DSP code I never get an error. I now also did the DSPReset Thorsten sugested. This did not make any difference.
    So I am quite out of options now. I think I am going to make a clean install with the Ventiotek disc or installing from Apt-get. This worked before. Unless you have an other brilliant idea. Is there a place where I can find a complete log file for more information?

     
  • Percy Zahl

    Percy Zahl - 2014-09-16

    I have a feeling there is a version mismatch between the DSP code and gxsm.

    What exact Version and build date you have for Gxsm and the DSP?

    I strongly recommend NOT to use any of the older development versions with any not exactly matching DSP code than:

    GXSM: (From Menu->Help->About)
    GXSM 3.10.0 "Signal Master Evolved"

    and via Gxsm tools->hardware info
    Version: Signal Master Evolved
    --Magic Info--
    Magic....... : 3202EE01
    Version..... : 00003043
    Date........ : 0000201400000813

    translated into V30.43 Date 2014-08-13

    and well as you currently can't do this the configurator script will get the this briefly in the main menu header, start

    python_scripts$ ./mk3_spm_configurator.py

    and see what is printed in top of the app-buttons, some thing like:
    SR dev:/dev/sranger_mk2_0/1/..
    V3034-Y20140813

    ---->>>>>>

    Query_Module_Signal[inpid=4099]: found Sig 0 [v-1] *** mindex=-1, signal_id=-1, act_address_input_set=0, act_address_input_signal=284184032

    and yours reads some totally out of range index where I get "Sig 0 [v-1]", you read "Sig -1 [v-7557957]..." -- what I may not catch as error everywhere.

    It should continue like this:

    [...]
    TQ: setup signal monitor[18] <== S53 (Z Offset)
    sranger_mk3_hwi_dev::change_module_signal_input
    PanView::start_tip_monitor

    (gxsm2:24842): Gtk-CRITICAL **: IA__gtk_object_get_data: assertion `GTK_IS_OBJECT (object)' failed

    (gxsm2:24842): Gtk-CRITICAL : IA__gtk_label_set_text: assertion `GTK_IS_LABEL (label)' failed
    BiasGain:0.99485
    sranger_mk3_hwi_dev::query_module_signal_input_config
    Query_Module_Signal[inpid=4099]: found Sig 0 [v-1]
    mindex=-1, signal_id=-1, act_address_input_set=0, act_address_input_signal=284184032
    5=> Topo,*
    6=> A2
    7=> A3
    8=> A4
    9=> Mix-In 0-ITunnel
    10=> AIC1
    11=> AIC2
    12=> AIC3
    13=> AIC4
    14=> AIC5
    15=> AIC6
    16=> AIC7
    17=> C1
    18=> D1
    19=> E1
    20=> F1
    sranger_mk3_hwi_dev::query_module_signal_input_config
    Query_Module_Signal[inpid=4100]: found Sig 24 [v-1]
    mindex=-1, signal_id=-1, act_address_input_set=0, act_address_input_signal=284187272
    5=> Topo,*
    6=> Mix-PLL Exci Frq LP
    7=> A3
    8=> A4
    9=> Mix-In 0-ITunnel
    10=> AIC1
    11=> AIC2
    12=> AIC3
    13=> AIC4
    14=> AIC5
    15=> AIC6
    16=> AIC7
    17=> C1
    18=> D1
    19=> E1
    20=> F1
    sranger_mk3_hwi_dev::query_module_signal_input_config
    Query_Module_Signal[inpid=4101]: found Sig 2 [v-1]
    * mindex=-1, signal_id=-1, act_address_input_set=0, act_address_input_signal=284184040
    .....

     
    Last edit: Percy Zahl 2014-09-16
  • Percy Zahl

    Percy Zahl - 2014-09-16

    There is something totally funky.

    This signal vector index can not be negativ per definition, only == -1 is not use (scalar only).

    Do you have 32 or 64 bit system install -- just curious, not sure if that can cause a problem should not? -- I only use 64 bit Linux since they exist. I do not see one right now and it should be non, but may be tricky some where...

    It is computed here:

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    int sranger_mk3_hwi_dev::lookup_signal_by_ptr(gint64 sigptr){
    for (int i=0; i<NUM_SIGNALS; ++i){="" if="" (dsp_signal_lookup_managed<span="">[i].dim == 1 && sigptr == dsp_signal_lookup_managed[i].p) return i; gint64 offset = sigptr - (gint64)dsp_signal_lookup_managed[i].p; if (sigptr >= dsp_signal_lookup_managed[i].p && offset < 4*dsp_signal_lookup_managed[i].dim){
    dsp_signal_lookup_managed[i].index = offset/4;
    return i;
    }
    }
    return -1;
    }
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Only odd behavior may (on a 32bit system only!!!) if the resulting index is HUGE (gint64) and then assigned to the dsp_signal_lookup_managed[i].index struct member what I be leave is an INT and this will be 32bit on a 32bit machine and then if offset/4 is > (2^31) -- what also would be normally nonsense and totally out of any range ever existing on the DSP. Then it may result by this assignment into a negative (fairly random big number). But the pre requisition is that the allowed variable dimension (dsp_signal_lookup_managed[i].dim) is already way wrong as well...?!?!? All very odd.

    Strongly looks like apples and bees to be with a bad version mismatch! As there was a transition -- non to be ignored.

     
    Last edit: Percy Zahl 2014-09-16
1 2 > >> (Page 1 of 2)

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks