Strange #AUTO Galil program behavior

[Jeff_Birt]

Since I am using a 1842 which does not include the state of the extended I/O inputs in its DR (Data Record) I use a Galil program running in #AUTO to read the inputs, stash the value in the unused auxiliary registers and then wait 10ms and do it all over. This has worked great. Today while doing some testing Mach started up like I had reset the motion controller and ask me to choose which one to use. I recovered from this by grabbing a back-up of the Mach profile XML and then noticed that the Galil card did not seem to be executing #AUTO properly. I uploaded the program from the card and it was correct, I downloaded and burned a copy from the HD and had the same problem. If I do 'XQ #AUTO' it only runs once. Here are the pertinent parts of the Galil program.

#AUTO
REM This program automatically starts with power on
..... more REM
#START
DE (256*_TI3)+_TI2, (256*_TI5)+_TI4, (256*_TI7)+_TI6, (256*_TI9)+_TI8
WT 10
JP #START
EN

For the life of me I cant figure out why it seems to miss the JP. I even added some message outputs in like MG "In Loop" but only see it once as no looping is taking place. Has anyone else seen this. I would prefer to not try and do a Master Reset if I can avoid it.

[smurph]

Your MG "In Loop" doesn't repeat in SmartTerm?  If so, it sounds like MRST to me.  No error LED?

Steve

[NosmoKing]

Did you try TC to see if any thing comes up?
N.

[kcrouch]

Jeff,
I would suggest that the second line be "XQ #START,2" to cause execution in thread 2. The mach commands execute in the first thread which will interfere with the running of your program there. I don't have your full program and can't test it here.
Regards,
Kenny

[Jeff_Birt]

No error light

TC returns 0 (no errors)

MG _XQ return -1 showing that the program is not running.

Kenny, that is a good idea to execute it in thread 2. Right now I'm just using SmartTerm to try and diagnose the Galil card so any mach interactions are out of the picture, but that could have caused the initial problem.

FWIW here is the whole program:

#AUTO
REM This program automatically starts with power on
REM and continiously monitors the status of the servo
REM motors. If any motor is turned off then all motors
REM will be turned off and the brakes applied. If all
REM servo motors are on the brakes will be released.
REM It also reads the extended inputs and pops them into
REM the unused auxillary encoder registers so we can
REM read the inputs easily through the DR in Mach III.
XQ #START,2
EN
#START
IF (_MOA=1)|(_MOB=1)|(_MOC=1)
MG "Motors OFF"
SB 80
SB 74
MO
ELSE
MG "Motors ON"
CB 80
CB 74
ENDIF
DE (256*_TI3)+_TI2,(256*_TI5)+_TI4,(256*_TI7)+_TI6,(256*_TI9)+_TI8
WT 1000
JP #START
EN
#ININT
MG "Servos OFF, Brakes ON"
REM Turn the brakes ON, stop all axis
SB 74
SB 80
ST XYZ
RI

[Jeff_Birt]

I simplified the program to what is shown below and did a trace to send to Galil. I even removed the WT and tried it again, it just seems to ignore the JP. I'll let you guys know what the verdict was.

Program:

#AUTO
MG "At Auto"
#START
MG "In Loop"
WT 1000
JP #START
EN


Trace Dump:

:0 #AUTO
1 MG "At Auto"
At Auto
2 #START
3 MG "In Loop"
In Loop
4 WT 1000

[Jeff_Birt]

Well, the guys at Galil were stumped too. I did an Master Reset and even re-flashed the FW (and MR afterwords) and neither helps. It just seems to randomly stop parsing user programs. Guess it is time to send it in for repair. 

[Jeff_Birt]

Well I sent the card in for repair and it worked fine for the guys at Galil. They sent it back and asked me to let them know what happened here. I plugged it back in to the machines motherboard and it would quit running programs at random places. I then set up an old Dell with a fresh copy of XP, loaded the Galil drivers, plugged the card in and it worked immediately on power up. I'm reloading XP on the machine at this time. The guys at Galil are still unsure what could have gone wrong on the PC to cause this as they have never seen this particular problem before: lucky me!