I am quite new for GXSM. I just got a SR-MK3&A810PLL from SoftdB and installed
the software with Gxsm liveDVD. The startup always freeze when "Gxsm plugin
loading" reach 100%. By the way, the startup with no hardware works fine. Is
there any suggestion what should I do?
Thanks,
Lifeng
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If there was a change in the interface afterwards your GXSM might crash. Percy
has at least released two patches (in June). All have the firmware version
30.15 - you should get this by trying the script initSR.py which is also in
the main menue.
Thorsten :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One mroe thing: While starting in the no hardware mode, please enter the
preferences and check for the correct devise: You should find on the first
page of the preference manager the device which should be /dev/sranger_mk2_0.
Thorsten :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks a lot for your quick answer! I did two things till now,
(1) In the preference page, put in /dev/stranger_mk2_0 as device, and then run
initsr.py. And below is what I got,
No device /dev/sranger0 found.
Device SR_MK2 found!
DSP code released:00.00.0
(2) Download SR3_applications_installer_V200 from softdb website, and use
minidebugger from the package. By choose "SR3_Pro" as card, I got Rev 1.50, I
wonder if this is the firmware version.
It seems I got something wrong or missed. What should I do next?
Any suggestion is highly appreciated!
Lifeng
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You did everythinkg right. The initSR.py usually returns the wrong DSP-
Firmware version for the SR-MK3Pro because the tools expects the number at the
wrong position in the memory. Is there anything else the scripts complains
about? Usually it checks the permissions of the device. If the script is
running without further complains, GXSM should have access to the board.
About the FPGA code :Usually, you do not have to upload that, too, if you
update the GXSM related DSP code. The FPGA is much more low level. The rbt or
rbt.vi file is contained in the old SR-MK2 driver package. Look for the file
SR2_Analog_810_V200 (with one of the afore mentioned suffixes).
The mentioned firmware revision you get from the minidebugger is resonable. I
have the same on my board. By the way, do you run the Distribution in live-
mode or in an installed version. I hope it is no problem of having not enough
physical memory while running in live-mode.
Last thing to try: Use another PC to check if the USB port is buggy.
Thorsten :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
About the FPGA code, I assume it comes with the right FPGA code pre loaded and
no need to update at any time. If you do so, use the latest rbt file for the
A810 provided by SoftdB.
PS: Do you have the PLL version (with TCO) or not? (beyond the precision gain,
it should not matter and they behave the same)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you fire up gxsm2 from command line (I assume you previously set
hardware/card in preferences to
Hardware/Card: SRangerMK2:SPM
and
Hardware/Device: /dev/sranger_mk2_0 (may be _1, ... if you have multiple SR
attached).
The Mk2 or Mk3 versions are auto detected and you have to just set as above --
they share the same driver and HwI, but the Mk3 provides more computing power
and functionality, PLL,...
This is what you should get as console output at start from the Mk2/3/PLL auto
detection:
You should adjust the preferences as indicated (even the auto adjustment will
work for this session but is not saved). Set type for ...C1-F1 to FLOAT and
save. The latest HwI version for Mk2/3 are requiring this.
The terminal message can be ignored... mostly informative/debugging for
developers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry to bother you again. I am trying to test the function of Mk3pll. And
below is problem I met:
When I click "scan" button in the main frame, all the GXSM windows (main,
channelselector..) will fall to respond, that is, I can not even stop the
scanning. At the same time, I got nothing from the output of MK3pll, all the
output voltage from Xs, Xo, Ys, Yo...are all close to zero. I feel I might
just missed something very simple, but I can not figure out what is wrong.
BTW, I update the DSP code to the lastest version. Below is what I got by
running mk3pro_spm_control.py
Magic ID: 3202EE01
SPM Version: 00003015
Software ID: 0000001002
DSP Code Released: 12.06.2012
I also tested the PLL loop under windows with the labview code provided by
softdb, and that part seems working.
Thanks,
Lifeng
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(3) Then I just click the "scan" button, as shown below.
I suppose this should give some periodic scan signal to drive piezo tube via
Xs Ys output. All the outputs are monitored by an oscilloscope but got
nothing. At the same time, I also noticed that the whole gxsm system fail to
answer any further action, and the only thing I can do seems to be "force
quit" as shown below.
I hope the description above can give you some clue about what I missed or
what is wrong with my settings.
Thanks a lot!
Lifeng
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
a) The DSP status is very odd (color indicators in pan view) FB is active but
not active in GXSM, scan/move is active, but not scanning or moving. Indicates
some thing "hanging" or/and DSP conditions/mode.
b) all values are zero -- not even noise at the tunnel input, even if grounded
I won't expect to read 0.000nA, it should fluctuate a bit around zero at
least.
c) Software ID and DSP code seams loaded OK and latest version as far as I can
see, but for some reason I have a feeling the DSP is not responding to
commands and Gxsm waits for ever. It may be crashed at bootup for a reason I
can not simply tell.
--
If you start fresh, DSP power up, plug in, and they start Gxsm:
1) how is the PanVIew (this status panel) looking like? Any numbers changing?
Is the left DSP load indicator a little fluctuating? It seams fairly high --
unless the PLL is all active (you must turn it on manually).
2) can you toggle the Feedback on/off, (in advanced folder), then the left
"green" LED (here on, strangely) should come on when turned on -- 1st thing
you may want to do.
3) Can you press "(Scan) STOP" button 1st thing after DSP startup and GXsm
start, does this do any thing? (this may recover the DSP to a default state),
then try to turn on the Feedback. Also may want to check GURU and ADVANCED
mode.
4) Can you change the Offset?
If nothing reacts, the DSP code is not properly loaded/flashed or some thing
else went wrong and the DSP program is not running normal. It is per design
extremely stable as it's a state machine design. However, if wrong memory
location were accessed/written (by what ever, including scripts or Gxsm)
things go wrong.
What is "dmesg" showing if you plug in the DSP (terminal command), any
warnings/errors -- if should just tell you that the DSP was detected and some
version info.
==> You did NOT got any warning related to DSP code version and Gxsm mismatch?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your quick answer! I just followed your instruction to make some
test. Here are some results,
(1) The values shown in the pan view are exactly zero without any fluctuation.
(2) The left DSP load indicator shows no fluctuating as well.
(3) When toggle the Feedback on/off in the advanced folder, the left green
indicator kept on for all the time.
(4) When start fresh, DSP power up, plug in, start GXSM, and press (scan)stop,
the only change in the pan view is the second color indicator from left will
turn from green to black.
(5) Changing the offset xy in the main frame seems can make some changes in
the pan view as below, but no real output on the front panel of MK3pll.
(6) The message from dmesg is,
usbcore: registered new interface driver sranger
SR: USB SignalRanger STD/SP2 Driver v0.50 20060621
SR-MK2/3: USB SignalRanger MK2/3 init
usbcore: registered new interface driver sranger_mk2
SR-MK2/3: USB SignalRanger MK2/MK2-NG/MK3-Pro Driver v0.30 20111030
usb 1-3: new high speed USB device using ehci_hcd and address 3
usb 1-3: configuration #1 chosen from 1 choiceto
SR-MK2/3: Allocated and initiated usb_sranger_mk2 device structure, size=672
SR-MK2/3: sranger_mk2_probe - USB SignalRanger MK3 device now attached to
sranger_mk2200
SR-MK2/3: sranger_mk2_probe - USB Devive Information:
SR-MK2/3: sranger_mk2_probe - SR2/3 USB Interface Configuration HPI->FAST
mode: OK
(7) There is no warning related to mismatch between DSP code and GXSM,
actually there is no warning at all.
Thanks again!
Lifeng
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Lifeng, I have a feeling your DSP code is not matching with the Gxsm version
you are running or some thing is wrong with the DSP/memory causing it crash or
been unresponsive.
No fluctuations and the way to high load (fixed, may even be a random wrong
reading), the "blue" (move indicator is on for no reason!?!?) should never be
on at startup -- very weird. All points to two options:
a) Gxsm is reading wrong memory locations due to version mismatches -- is you
Gxsm up-to-date from CVS? I actually do NOT know what the life CD version is.
@Thorsten should know)
Gxsm is actually checking for this and should warn you -- unless manipulated
or wrong header files compiles in/overridden.
b) Your Offset change seam only to effect the black box position, and NOT move
the tip -- (the center indicator is read back life from DSP and looks NOT
moved!) Offset change should briefly turn on the blue indicator (always on
here) .
c) Just checking: what are your piezo sensitivities (did you changed those at
all from default), Gains, etc. -- you may not want to use extremely small or
zero here -- this may cause "for ever" waiting if calculated step size may get
zero at some extreme point. Also Scan and Move "speed" settings should be
reasonable. if very very small, actions may take very long or for ever. (But
all this is no crash and recoverable by readjusting)
If you have the "life CD", may be you can try to build your own latest Gxsm
from CVS? As said, have to check w Th. for life CD code versions.
-Percy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I remember that I had similar problems as you described when I had an
intermeadiate version of GXSM running. Anyway, please make sure that you have
the latest GXSM Ubuntu Remix on your computer. I just releases the 12.04 LTS
version as distribution (http://www.ventiotec.de/linux/GXSM-
Linux.iso) or via my PPA.
I will crosscheck tomorrow on my system.
Thorsten :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I am quite new for GXSM. I just got a SR-MK3&A810PLL from SoftdB and installed
the software with Gxsm liveDVD. The startup always freeze when "Gxsm plugin
loading" reach 100%. By the way, the startup with no hardware works fine. Is
there any suggestion what should I do?
Thanks,
Lifeng
Hi Lifeng.
I am not sure what happens. I think you are right that there is a problem with
the HWI plugin for the SR-MK3. Do you know the firmware version of your DSP
code? I am not sure if softdb always delivers the latest version. The linux
distriution is dated from May.So please make sure that on your SR the
following DSP code is running:
http://sranger.cvs.sourceforge.net/viewvc/sranger/SRanger/TiCC-project-files/
MK3-A810_spmcontrol/FB_spmcontrol.out?revision=1.14
If there was a change in the interface afterwards your GXSM might crash. Percy
has at least released two patches (in June). All have the firmware version
30.15 - you should get this by trying the script initSR.py which is also in
the main menue.
Thorsten :-)
One mroe thing: While starting in the no hardware mode, please enter the
preferences and check for the correct devise: You should find on the first
page of the preference manager the device which should be /dev/sranger_mk2_0.
Thorsten :-)
Hi Thorsten,
Thanks a lot for your quick answer! I did two things till now,
(1) In the preference page, put in /dev/stranger_mk2_0 as device, and then run
initsr.py. And below is what I got,
No device /dev/sranger0 found.
Device SR_MK2 found!
DSP code released:00.00.0
(2) Download SR3_applications_installer_V200 from softdb website, and use
minidebugger from the package. By choose "SR3_Pro" as card, I got Rev 1.50, I
wonder if this is the firmware version.
It seems I got something wrong or missed. What should I do next?
Any suggestion is highly appreciated!
Lifeng
By the way, do I need to update the FPGA code as well during updating DSP code
with minidebugger? If yes, where can I find the latest version?
Thanks,
Lifeng
You did everythinkg right. The initSR.py usually returns the wrong DSP-
Firmware version for the SR-MK3Pro because the tools expects the number at the
wrong position in the memory. Is there anything else the scripts complains
about? Usually it checks the permissions of the device. If the script is
running without further complains, GXSM should have access to the board.
About the FPGA code :Usually, you do not have to upload that, too, if you
update the GXSM related DSP code. The FPGA is much more low level. The rbt or
rbt.vi file is contained in the old SR-MK2 driver package. Look for the file
SR2_Analog_810_V200 (with one of the afore mentioned suffixes).
The only other way to check for the firmware version is via GXSM. But as this
fails to start, ... I can maybe prepare a special verison of the initSR.py for
you to check on the SR3-Pro (instead of the SR2 for which is was originally
made). Wait a momemt, please try the mk3pro_spm-control-script. Here the link
to the latest version:
http://sranger.cvs.sourceforge.net/viewvc/sranger/SRanger/TiCC-project-files/
MK3-A810_spmcontrol/python_scripts/mk3pro_spm_control.py?view=log.
The mentioned firmware revision you get from the minidebugger is resonable. I
have the same on my board. By the way, do you run the Distribution in live-
mode or in an installed version. I hope it is no problem of having not enough
physical memory while running in live-mode.
Last thing to try: Use another PC to check if the USB port is buggy.
Thorsten :-)
Hi Lifeng,
Can you start up the
mk3pro_spm_control.py
script?
here:
SRanger/TiCC-project-files/MK3-A810_spmcontrol/python_scripts$
./mk3pro_spm_control.py
Then click on "SR MK3 DSP Info"? This should display this (latest code as of
CVS):
Magic ID: 3202EE01
SPM Version: 00003015
Software ID: 0000001002
DSP Code Released: 12.06.2012
-P
And just in case you are not using the supplied USB cable, it must be USB 2.0
rated, else trouble is on....
DSP Status LED is Green when plugged in?
any thing unusual/strange if you execute "dmesg" from command line? After
plugin you should see some thing like this:
...
usb 1-8: new high speed USB device using ehci_hcd and address 15
usb 1-8: configuration #1 chosen from 1 choice
usb 1-8: USB disconnect, address 15
usb 1-1: new high speed USB device using ehci_hcd and address 16
usb 1-1: configuration #1 chosen from 1 choice
SR-MK2/3: USB SignalRanger MK2/3 init
SR-MK2/3: sranger_mk2_probe - probing for B.Paillard Signal Ranger MK2/MK3 DSP
board
SR-MK2/3: Allocated and initiated usb_sranger_mk2 device structure, size=736
SR-MK2/3: sranger_mk2_probe - USB SignalRanger MK3 device now attached to
sranger_mk2200
SR-MK2/3: sranger_mk2_probe - USB Devive Information:
SR-MK2/3: sranger_mk2_probe - Vendor : 0x1612
SR-MK2/3: sranger_mk2_probe - Product: 0x103
SR-MK2/3: sranger_mk2_probe - Device Ver: 1.50
SR-MK2/3: sranger_mk2_probe - bulk_out_endpoint: 2
SR-MK2/3: sranger_mk2_probe - bulk_in_endpoint : 6
SR-MK2/3: sranger_mk2_probe - SR2/3 USB Interface Configuration HPI->FAST
mode: OK
usbcore: registered new interface driver sranger_mk2
SR-MK2/3: USB SignalRanger MK2/MK2-NG/MK3-Pro Driver v0.35 20120503
About the FPGA code, I assume it comes with the right FPGA code pre loaded and
no need to update at any time. If you do so, use the latest rbt file for the
A810 provided by SoftdB.
PS: Do you have the PLL version (with TCO) or not? (beyond the precision gain,
it should not matter and they behave the same)
One more, sorry...
If you fire up gxsm2 from command line (I assume you previously set
hardware/card in preferences to
Hardware/Card: SRangerMK2:SPM
and
Hardware/Device: /dev/sranger_mk2_0 (may be _1, ... if you have multiple SR
attached).
The Mk2 or Mk3 versions are auto detected and you have to just set as above --
they share the same driver and HwI, but the Mk3 provides more computing power
and functionality, PLL,...
This is what you should get as console output at start from the Mk2/3/PLL auto
detection:
percy@mimas:~$ gxsm2
GXSM-DebugLevel/PI-DebugLevel/ForceGDefaults: 0/0/0
DSPDev :/dev/sranger_mk2_0
DSPType:SRangerMK2:SPM
SR-MK2/3_HwI HardwareInterface Init
probing for MK2...
HWI-DEV-MK2-I** HwI SR-MK2 probing
HWI-DEV-MK2-I03-- SR-MK3-NG 1612:0103 found -- reassigning...
probing mark id: MK-3 identified.
HWI-DEV-MK2-BYBY -- closing all DSP links.
probing for MK3...
HWI-DEV-MK3-I** HwI SR-MK3 probing
HWI-DEV-MK3-I03-- SR-MK3-NG 1612:0103 found -- OK, taking it.
HWI-DEV-MK3-I** reading DSP magic informations and code version.
HWI-DEV-MK3-ICPU DSP-MAGIC : 3202ee01
HWI-DEV-MK3-ICPU DSP-SoftId : 00001002
HWI-DEV-MK3-ICPU DSP-Version: 00003015
probing succeeded: MK3 identified.
SR-MK2/3_HwI::sranger_mk2_hwi_query:: <SRangerMK2:SPM>
SR-MK2/3_HwI::sranger_mk2_hwi_query:: Adding DSP controls to menu
SR-MK2/3_HwI::sranger_mk2_hwi_query:: PAC check... HwI and PLL cap. present,
adding PAC control.
My problem seems solved. And the solution is to update the firmware version
with the minidebbuger in Windows, as suggested by Thorsten.
Sorry for the late reply, I can not access the forum for the past few days.
Thanks again to Thorsten and Zahl!
Lifeng
Hi Thorsten and Zahl,
I met some problems just after startup,
(1) A warning message popped out, as below,
Warning
MK2-A810 DataAq Preferences Setup Verification
==> Auto Adjustments done:
DataAq/DataSrcC1-ZType=LONG -> FLOAT
DataAq/DataSrcD1-ZType=LONG -> FLOAT
DataAq/DataSrcE1-ZType=LONG -> FLOAT
DataAq/DataSrcF1-ZType=LONG -> FLOAT
PLEASE VERIFY YOUR PREFERENCES!
Should I do something or ignore it?
(2) In terminal, I got a lot identical warnings
(gxsm2:1565): GLib-GObject-WARNING **: value "-nan" of type
gdouble' is invalid or out of range for propertyy2' of type `gdouble'(gxsm2:1565): GLib-GObject-WARNING **: value "-nan" of type
gdouble' is invalid or out of range for propertyy2' of type `gdouble'(3) I tried to scan, but GXSM seems got idled, no output from any BNC in the
front panel, and I got a message in the terminal:
SR-MK2/3_HwI::DSPControl_StartScan_callback
ROTM:
ROTM - SRSWAPED:
Thanks,
Lifeng
You should adjust the preferences as indicated (even the auto adjustment will
work for this session but is not saved). Set type for ...C1-F1 to FLOAT and
save. The latest HwI version for Mk2/3 are requiring this.
The terminal message can be ignored... mostly informative/debugging for
developers.
Hi Zahl,
Sorry to bother you again. I am trying to test the function of Mk3pll. And
below is problem I met:
When I click "scan" button in the main frame, all the GXSM windows (main,
channelselector..) will fall to respond, that is, I can not even stop the
scanning. At the same time, I got nothing from the output of MK3pll, all the
output voltage from Xs, Xo, Ys, Yo...are all close to zero. I feel I might
just missed something very simple, but I can not figure out what is wrong.
BTW, I update the DSP code to the lastest version. Below is what I got by
running mk3pro_spm_control.py
Magic ID: 3202EE01
SPM Version: 00003015
Software ID: 0000001002
DSP Code Released: 12.06.2012
I also tested the PLL loop under windows with the labview code provided by
softdb, and that part seems working.
Thanks,
Lifeng
I need to full "picture", no idea what you are doing -- sorry.
Please tell me step by step what you do.
Hi Zahl,
Below are some steps I took,
(1) startup with nothing abnormal, as shown below.
(2)
hardware info
channel selector
feedback and scan
Advanced
Graphs
(3) Then I just click the "scan" button, as shown below.
I suppose this should give some periodic scan signal to drive piezo tube via
Xs Ys output. All the outputs are monitored by an oscilloscope but got
nothing. At the same time, I also noticed that the whole gxsm system fail to
answer any further action, and the only thing I can do seems to be "force
quit" as shown below.
I hope the description above can give you some clue about what I missed or
what is wrong with my settings.
Thanks a lot!
Lifeng
I notice a few things not normal:
a) The DSP status is very odd (color indicators in pan view) FB is active but
not active in GXSM, scan/move is active, but not scanning or moving. Indicates
some thing "hanging" or/and DSP conditions/mode.
b) all values are zero -- not even noise at the tunnel input, even if grounded
I won't expect to read 0.000nA, it should fluctuate a bit around zero at
least.
c) Software ID and DSP code seams loaded OK and latest version as far as I can
see, but for some reason I have a feeling the DSP is not responding to
commands and Gxsm waits for ever. It may be crashed at bootup for a reason I
can not simply tell.
--
If you start fresh, DSP power up, plug in, and they start Gxsm:
1) how is the PanVIew (this status panel) looking like? Any numbers changing?
Is the left DSP load indicator a little fluctuating? It seams fairly high --
unless the PLL is all active (you must turn it on manually).
2) can you toggle the Feedback on/off, (in advanced folder), then the left
"green" LED (here on, strangely) should come on when turned on -- 1st thing
you may want to do.
3) Can you press "(Scan) STOP" button 1st thing after DSP startup and GXsm
start, does this do any thing? (this may recover the DSP to a default state),
then try to turn on the Feedback. Also may want to check GURU and ADVANCED
mode.
4) Can you change the Offset?
If nothing reacts, the DSP code is not properly loaded/flashed or some thing
else went wrong and the DSP program is not running normal. It is per design
extremely stable as it's a state machine design. However, if wrong memory
location were accessed/written (by what ever, including scripts or Gxsm)
things go wrong.
What is "dmesg" showing if you plug in the DSP (terminal command), any
warnings/errors -- if should just tell you that the DSP was detected and some
version info.
==> You did NOT got any warning related to DSP code version and Gxsm mismatch?
Hi Zahl,
Thanks for your quick answer! I just followed your instruction to make some
test. Here are some results,
(1) The values shown in the pan view are exactly zero without any fluctuation.
(2) The left DSP load indicator shows no fluctuating as well.
(3) When toggle the Feedback on/off in the advanced folder, the left green
indicator kept on for all the time.
(4) When start fresh, DSP power up, plug in, start GXSM, and press (scan)stop,
the only change in the pan view is the second color indicator from left will
turn from green to black.
(5) Changing the offset xy in the main frame seems can make some changes in
the pan view as below, but no real output on the front panel of MK3pll.
(6) The message from dmesg is,
usbcore: registered new interface driver sranger
SR: USB SignalRanger STD/SP2 Driver v0.50 20060621
SR-MK2/3: USB SignalRanger MK2/3 init
usbcore: registered new interface driver sranger_mk2
SR-MK2/3: USB SignalRanger MK2/MK2-NG/MK3-Pro Driver v0.30 20111030
usb 1-3: new high speed USB device using ehci_hcd and address 3
usb 1-3: configuration #1 chosen from 1 choiceto
SR-MK2/3: Allocated and initiated usb_sranger_mk2 device structure, size=672
SR-MK2/3: sranger_mk2_probe - USB SignalRanger MK3 device now attached to
sranger_mk2200
SR-MK2/3: sranger_mk2_probe - USB Devive Information:
SR-MK2/3: sranger_mk2_probe - SR2/3 USB Interface Configuration HPI->FAST
mode: OK
(7) There is no warning related to mismatch between DSP code and GXSM,
actually there is no warning at all.
Thanks again!
Lifeng
Lifeng, I have a feeling your DSP code is not matching with the Gxsm version
you are running or some thing is wrong with the DSP/memory causing it crash or
been unresponsive.
No fluctuations and the way to high load (fixed, may even be a random wrong
reading), the "blue" (move indicator is on for no reason!?!?) should never be
on at startup -- very weird. All points to two options:
a) Gxsm is reading wrong memory locations due to version mismatches -- is you
Gxsm up-to-date from CVS? I actually do NOT know what the life CD version is.
@Thorsten should know)
Gxsm is actually checking for this and should warn you -- unless manipulated
or wrong header files compiles in/overridden.
b) Your Offset change seam only to effect the black box position, and NOT move
the tip -- (the center indicator is read back life from DSP and looks NOT
moved!) Offset change should briefly turn on the blue indicator (always on
here) .
c) Just checking: what are your piezo sensitivities (did you changed those at
all from default), Gains, etc. -- you may not want to use extremely small or
zero here -- this may cause "for ever" waiting if calculated step size may get
zero at some extreme point. Also Scan and Move "speed" settings should be
reasonable. if very very small, actions may take very long or for ever. (But
all this is no crash and recoverable by readjusting)
If you have the "life CD", may be you can try to build your own latest Gxsm
from CVS? As said, have to check w Th. for life CD code versions.
-Percy
Hi Lifeng.
I remember that I had similar problems as you described when I had an
intermeadiate version of GXSM running. Anyway, please make sure that you have
the latest GXSM Ubuntu Remix on your computer. I just releases the 12.04 LTS
version as distribution (http://www.ventiotec.de/linux/GXSM-
Linux.iso) or via my PPA.
I will crosscheck tomorrow on my system.
Thorsten :-)
Here is a MK2 screen shot of normal operation, just current set to zero for
tip retract purpose.
MK3 is very similar.