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!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 /
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
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
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...
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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!
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
Hi Camiel.
In any case, the Ubuntu 14.04 64 bit is experimental. So please use the more stable 32 bit Version.
Thorsten :-)
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
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
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
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.
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
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.
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
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
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!
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!
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
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
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.
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.
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
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.
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 :-)
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.
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.
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?
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
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