Yes, I did set it to 10. I did also connected the PS2 controller and same result there, no reaction using the start button.
I will see what I can figure out 
. I am trying it on a test board right now…
Sorry
Kurt
The problem is not with the XBEE stuff it is with the Extra stuff… I should have noticed the problem with this Post…
The problem was I was cleaning up the code and trying to get rid of the assembly language code that was there. This was the wrong label!!!
The beginning of the function should be:
[code]fShowterminalPrompt var byte
TerminalMonitor[fShowTerminalPrompt]:
if fShowTerminalPrompt then
_TM_ShowPrompt:
hserout HSP_DEBUG, [13, 13, “Phoenix-Arc32 keyboard monitor”,13,|
" D []] - Dump EEPROM memory", 13, |
#ifdef USE_SSC32
" E … - Dump SSC EEPROM memory", 13, |
#endif
" O - Enter Servo Offset mode", 13, |
#ifdef USE_SSC32
" . - SSC command", 13, |
#endif
" S - DL seq(s) - VB only", 13, |
" T - Set or show debug Trace level", 13, |
" V - View Sequence", 13, |
" : "]
fShowTerminalPrompt = 0
endif
if (hserinnext 0x81) = -1 then _TM_NoInput[/code]
That is if there is no keyboard input then go to the return, not somewhere in the middle of the XBee code…
I updated the file in the zip file…
Arc32 with SSC32.zip (52.9 KB)
Thanks Kurt! 
I’m glad you found the “bug”. 
I’ll test it later today. I assume it should be enough to only replace the “extra” file then? I’ve already done many changes to the other files for Archer, so I was hoping to avoid that work again.
Yep it is enough to make a 1 line change to the extras file… But updated zip file so hopefully others won’t run into it…
Kurt
I’ve tested it for just a few minutes and so far it seem to work very fine!
I’ll let you know when I’ve done some more thorough testing.
Thanks Kurt!
ok, it didnt work for me 
I did as i did the last time, unpacked the project,
opened config_cfg.bas and activated the PHOENIX_ARC32_ONLY and dissabled CHR3_SSC32
opened phoenix_cfg.bas and dissabled USEXBEE
and compile
Error: FILE C:…\PHOENIX_V21.BAS(LINE 670) : [TOKEN XBEEOUTPUTVAL] : Expected Label
The error is in a mysterous passage:
Starting at line 663, the function CheckLiPoStatus in phoenix_v21.bas:
LiPoCycleCnt var byte
LiPoCycleVal var word
CheckLiPoStatus:
IF (LiPoCycleCnt = 15) THEN
LiPoCycleVal = LiPoCycleVal + 1
GOSUB XBeeOutputVal[LiPoCycleVal]
LiPoCycleCnt = 0
ENDIF
LiPoCycleCnt = LiPoCycleCnt + 1
return
the XBeeOutputVal only sends info to XBEE thou the SendXBeePacket command, and the value the code above is a calculated value “LiPoCycleVal” whitch is deffined in the begining as a word, an then it add the value one with each passage … The functionname “CheckLiPoStatus” sort of implied that the function shall check LiPo-voltage-status, and send it to the XBEE, but it inly sends a word who is rising by 1 every time it is run … strange, and hard to test because i dont hae a XBEE … hell, i dont even have a working hexapod … but but …
Solution:
move/change
LiPoCycleCnt var byte
LiPoVLVal var word
to the INIT in the begining under ;[VARIABLES] so it only get initialized once
fix the code:
CheckLiPoStatus:
LiPoVLVal = hservostate 33
#IFDEF USEXBEE
LiPoCycleCnt = LiPoCycleCnt + 1
IF (LiPoCycleCnt = 15) Then ;Send the voltage value to the transmitter every 15 cycle
GOSUB XBeeOutputVal[dec LiPoVLVal]
LiPoCycleCnt = 0
ENDIF
#ENDIF
if(LiPoVLVal < 315) then
high p45 ; turn battery warnign LED On
Sound cSound,[60\4000,100\5000, 60\4000] ; make some noise...
else
low p45
endif
Returndoes this work, or is this wrong ?
Yep sorry about that… That was debugging some stuff from Zenta. You can simply remove that complete function and the call to it… Or simply remove the actual code except the return and leave it as a place holder…
Kurt
I’m using another main file (phoenix_V21.bas). The original code I use is like this:
[code];====================================================================
;[CheckLiPoStatus]LiPo safety warning!!!
;If voltage drop to 6 volt give audio warning!! (The Polyquest LiPo must not go under 5,6v!)
;5,5v = 284
;6,0v = 310
;8,4v = 432
CheckLiPoStatus:
wLiPoVad = HSERVOSTATE P33 ; Read VL
IF (wLiPoVad<330) THEN ;330 = 6,44 volt
IF(HexOn) THEN
'Turn off immediately!!
BodyPosX = 0
BodyPosY = 0
BodyPosZ = 0
BodyRotX1 = 0
BodyRotY1 = 0
BodyRotZ1 = 0
TravelLengthX = 0
TravelLengthZ = 0
TravelRotationY = 0
SSCTime = 300
GOSUB ServoDriverStart
GOSUB ServoDriverCommit
HexOn = 0
LiPoLowVoltage = 1
;Sound P9,[100\2000,100\3000,100\4000,100\3000,100\2000] ;Major Warning beeper!
ENDIF
ENDIF
IF (LiPoLowVoltage) THEN ;Give a warning continously, since the voltage probably will raise a little when servos are turned off
;Sound P9,[100\2000,100\3000,100\4000] ;Warning beeper
HexOn = 0 ;Lets keep it turned off
ENDIF
bLiPoV1 = wLiPoVad*c2DEC/512 ;Calculate actual voltage with one decimal (fixed point)
#ifdef USEXBEE
; ;Send the voltage value to the transmitter every 15. cycle:
IF (LiPoCycleCnt = 15) THEN
GOSUB XBeeOutputVal[bLiPoV1]
'hserout “LiPo:”, dec wLiPoVad, " LiPoVoltage=", dec bLiPoV1,13]
LiPoCycleCnt = 0
ENDIF
LiPoCycleCnt = LiPoCycleCnt + 1
#endif
return[/code]
Do you use a LiPo? If not, you can safely remove it like Kurt suggest.
Nice codeing !
Yes i will be using LiPo, so the controllcode is neseccery
Thanks !
Hi Kurt,
I’ve a little Q regarding your chr-3.cfg.
I saw that you set the initpos using the cos60 (0,5) and sin60 (0,866) values:
cRRInitPosX con (cHexInitXZ * 0.5 + 0.5) ;Start positions of the Right Rear leg
cRRInitPosY con cHexInitY
cRRInitPosZ con (cHexInitXZ * 0.866 + 0.5)
Ive been using the same method in PEP for setting the body dimension for a circular body. But I’m wondering why you have the additional +0,5 ? Does it have something with float to integer or what? Just curious since I’m going to use similar method for calculating the variable body dimension to MorpHex.
Hi Zenta, the adding of .5 was simply for doing a round up operation when we do a conversion from float to integer. Probably not necessary, but …
Kurt
I am going throu the Phoenix code now (as you may notice)
In the section
;[MIN/MAX ANGLES]
There are several angles that are lager than 90 degrees … how is this ?
In my case i have rotated the neutral position (HSERVO 0) of the right front leg 30 deg towards the front to get an higher degree of movement utilization, but still i cant move my the servo more than 90 deg backwards becase of the ±90deg mecanical issues in the servos … does this meen some off you have servos going more than ±90 deg ? Or am i missunderstaning something ?
All of our servos are limited to right around 180 degrees from the full clockwise stop to the full Counter clockwise stop.
But what I think may be the issue here is if you look at the phoenix construction guide: lynxmotion.com/images/html/build131.htm at step 13 you will see that you move the servo horn by 1 click (15 degrees), so from that center point you will be able to go about 90+15 degree in one direction and 90-15 degrees in the other…
Kurt
But … do you meen i dont measure the real maximum angle (from HSERVO 0), but instead some theoretical angle calcultaed from another centrum …
… i think i havto do some serious codeanalyze…
What I should be saying, is that I just used these values 
Probably Zenta or Xan would be better at explaining them…
Kurt
These angles are simply mechanical limits. On Phoenix the femur can be moved further than 90 deg upward until they gets in physical conflict with others parts.
ok
So it dont make any real sence to put in values greater then 900 then ?
one click of the servo horn will be ±15º so values will now be at a limit of 75º and 105º (750 and 1050)
Oh yes, it make sense if the servos allow it. Like Kurt mentioned, if the femur servo is calibrated with the center point (the horizontal 0 deg) with a little offset the servo can move more than 90 deg in one direction (and not so much in the other direction). For example I did this on A-Pod:
cRRFemurMIN1 con -1050
cRRFemurMAX1 con 750
Here are all femur servos calibrated with and offset of about 15 deg. 90+15=105 and 90-15=75.