gpascii crashes

[gshort]

 

I would appreciate some help with a crash I'm seeing inside a gpascii terminal. I first saw the crash when running GetResponse inside a background C application, but I've reproduced it here just using a terminal window.

 

I was actually testing what happens when buffer lookahead is set up to use 4 motors in a CS when there is actually only 3 defined in the CS. I was expecting an error, and I get this error, however I wasn't expecting a crash.

 

Referring to the attached screen shot.

 

I have a subprog which I use to reset the environment. I call this from the terminal with:

 

cx ldata.coord=1; call ResetPartProgEnviron;

 

In the adjacent unsolicited output window are various send prints from inside this subprog which show the progress of the subprog:

 

Port 2: Enter ResetPartProgEnviron

Port 2: ResetPartProgEnviron - 1

Port 2: ResetPartProgEnviron - 1a

Port 2: ResetPartProgEnviron - 1b

Port 2: ResetPartProgEnviron - 1c

Port 2: ResetPartProgEnviron - 1d

Port 2: ResetPartProgEnviron - 1e

Port 2: ResetPartProgEnviron - 1f

Port 2: ResetPartProgEnviron - 1g

Port 2: ResetPartProgEnviron - 1h

Port 2: ResetPartProgEnviron - 1i

Port 2: ResetPartProgEnviron - 1j

Port 2: ResetPartProgEnviron - 2

Port 2: ResetPartProgEnviron - 3

Port 2: ResetPartProgEnviron - 4

Port 2: ResetPartProgEnviron - 5

Port 2: ResetPartProgEnviron - 6

Port 2: Exit ResetPartProgEnviron

 

I then show that there is at this point no error in the CS by running

 

Coord[1].ErrorStatus;

 

in the terminal, which responds with...

 

Coord[1].ErrorStatus=0

 

I've then listed my motion script which I know to generate an error in the CS:

 

list prog 1

N65536M21

N65537S51

N65538M3

N65539F100

N65540G1X(-10)Z(-20)B10

N65541F300

N65542G1X0Z0B0

N65543M5

 

I then run it with...

 

&1 start 1

 

...and check the error status

 

Coord[1].ErrorStatus;

 

which is again the error I expect...

 

Coord[1].ErrorStatus=18

 

However when I try and re-run the subprog to reset my environment, this time the gpascii terminal explodes:

 

cx ldata.coord=1; call ResetPartProgEnviron;

Illegal instruction

root@192.168.0.200:/opt/ppmac#

 

The unsolicited output window, this time shows it has started running the subprog, but never completed. More worrying is the fact that the terminal has crashed, and this is what I also see when I try to do this programmatically from my background C application.

 

Any guidance on how to proceed is much appreciated.

 

gpasciicrash.bmp

[Guest DavisG]

one suggestion is to plug into the serial port and watch what the processor is spitting out in Hyperterminal. Sometimes debug information goes out through that port which is not seen anywhere else.

[gshort]

Thanks. I tried this but sadly there was no additional information output to the console.

[bradp]

Ok I have some explanations for you and a solution. First the solution, use the command

 

&1 cpx ldata.coord=1; call ResetPartProgEnviron instead of &1 cx ldata.coord=1; call ResetPartProgEnviron

 

cpx runs the routines according to motion program rules and cx runs according to plc rules

 

The way cx works is that it creates a plc program inside the communications thread and then executes. This is why the communications thread dies. The command causing the problem is the rapid command. You will get the same crash by just giving

 

&1 cx ldata.coord=1 rapid

 

Normally rapid in a cx command will not cause a problem. So there is some logic bug when the ppmac is in this state and the cx rapid is executed. So our developer is looking at this and probably I will have a fix before you even read this mail. But in any case I think you might consider the cpx as these routines were initially written to run as motion programs and there might be some timing issues when they run as plcs. For example your M5 will probably fail because as a plc the while loop

while (Motor[mot].DesVelZero == 0) {dwell 0;} // Wait for motor to stop

 

will work very different. Since dwell does nothing this will loop 65K times very fast and then exit as 65K is the default loop limit in a cx command.

 

Update:

PPmac firmware June 10th 2011 and newer have fixed the issue with rapid in the cx command