axis assignment failure

[jtaseff]

We have a linear motor that needs to be dynamically reassigned between two coordinate systems. We have a PLC that schedules the motion programs for the coordinate systems, and manages the timing of the axis assignment properly when no motion programs are running.

 

It works 99% of the time, but fails sporadically and irreproducibly, on the order of every 5-20 minutes. The assignments are getting made around every 15 seconds. As suggested in the manual, we are making the release/assignment as follows.

 

cmdSuccess=1;

Ldata.CmdStatus=1;

cmd"&1 delete lookahead"

sendallcmds

while(Ldata.CmdStatus>0) {}

if (Ldata.CmdStatus<0) { cmdSuccess=-1; send1"delete fail %d",Ldata.CmdStatus }

Ldata.CmdStatus=1;

cmd"&1#12->0"

sendallcmds

while(Ldata.CmdStatus>0) {}

if (Ldata.CmdStatus<0) { cmdSuccess=-1; send1"assign fail %d",Ldata.CmdStatus }

Ldata.CmdStatus=1;

cmd"&1 define lookahead 1500"

sendallcmds

while(Ldata.CmdStatus>0) {}

if (Ldata.CmdStatus<0) { cmdSuccess=-1; send1"define fail %d",Ldata.CmdStatus }

 

 

There are a number of different failure modes observed.

 

1. The #12->0 command fails and returns -20 (illegal cmd or illegal syntax??)

2. The define lookahead command fails and returns -34 (buffer full??). Trying to define it from the terminal after everything is stopped also returns the -34 error.

3. The commands do not fail, or the send1 debug messages do not get sent, but the LHSize in question is still 0 afterward. Trying to define lookahead later (when a program checks that LHSize==0) succeeds.

4. Same as 3, but trying to define lookhead from a program or the terminal returns the -34 error.

 

 

 

I am running a stress test in an almost blank pmac project and have seen all of these failures a few times.

 

 

Any input on possible causes, what the error codes mean, better ways to check the status, or better ways to have 2 CSs use the same motor at different times would be appreciated.

[steve.milici]

How are you verifying the state of "no motion programs are running"? This may be the cause.

[jtaseff]

It's checking for Coord[x].ProgActive==0 before trying to release or assign the motor.

 

Additionally, in the stress test I'm running now, no motion programs are being run - it's just a plc trying to release and then assign a motor every 5 seconds, nothing else going on. It usually gets the -34 error if it does fail.

[steve.milici]

You may also need some small timeouts between steps, especially when deleting and defining lookahead.

[jtaseff]

I just tried again, adding in 0.25 second delays between each command (after the cmdstatus clears, before the next is sent). Still no dice. It's occasionally getting the -34 buffer full error, always on the define lookahead command, both for adding and removing the motor from the coordinate systems.

 

I tried another test to stop the PLC if something fails, so I can play with it more. It failed on the define lookhead command after adding the motor. The motor was correctly assigned, querying #12-> returns with &3#12->y, and LHSize was 0. If I try "&3 define lookahead 1500" in the terminal, it keeps returning 34. If I try "delete lookahead" and then "define lookahead 1500", the define command still returns 34. If I delete lookahead, assign &3#12->0, still nothing. The only way I got &3 to go through was to delete and define &2 lookahead first, then delete and define on &3.

 

 

Does this help diagnose, or is there anything else I can try? Not clear on what buffer is full or what exactly is failing.

 

Thanks for the help.

[steve.milici]

Issue the "lhpurge" from your motion programs before the PLC code make the CS changes.

[jtaseff]

Still no dice :(

 

I added a new motion program that only calls "lhpurge", and my testing PLC runs it for both coordinate systems before trying to change the axis assignment. There are .25 sec delays between it and each of the delete/assign/define commands. The define command still fails with -34. I'm not watching to see how soon it fails, but it sometimes runs fine for a few hundred assignments before failing. Also, for the test I'm running now, I'm not even running any motion programs that should put anything into the lookahead buffer. It's only the PLC trying to switch the motor back and forth between CS2 and CS3.

 

 

 

This last time it failed even after calling the lhpurge program. Trying to run "&3 define lookahead 1500" in the terminal keeps failing. Deleting and trying to define lookahead again still failed. Running the lhpurge program manually on both involved coordinate systems, then trying to &3 define lookahead still failed.

 

The only way I can get &3 define lookahead to go through after it failed once is to run &2 delete lookahead first. The other CS. This seems like a good clue but I don't know what it's telling us.

[jtaseff]

Hi guys,

 

I ran another test overnight - this time making both assignments in one step (&2 delete lookahead, &3 delete lookahead, &2#1->0, &3#1->X, &2 define lookahead, &3 define lookahead). I also removed all extra delays between commands, and the lhpurge. This completed 25000 times without failing.

 

Somehow, things start going wrong with the lookahead buffer when the delete / assign / define happens for each coordinate system independently.

 

The usual failures are -34 buffer full when it defines lookahead, which usually forces me to reset everything, and -20 illegal cmd when it tries to clear the motor back to ->0, which usually recovers if I try again right after.

 

I've reproduced on 2 different machines, both UMAC but different configurations. Could you guys try some testing at Delta Tau, or is there anything else I can do to try to narrow it down?

[steve.milici]

I believe your issue is making the changes to each CS independently. You should be doing this as described in the first paragraph of your last post.

[jtaseff]

Hi Steve,

The fun part is that we have to do them separately, at different times. The 2 coordinate systems need to be active about 98% of the time to meet the cycle times required, and there is not a predictable time in each cycle that they are both stationary at the same time. The way the scheduling works, the first CS drops the shared motor during a pause as soon as it is finished using it, then the second CS adds the shared motor during a different pause right before it will require it. They trade off continuously as the scheduling allows.

 

Is there a specific underlying reason why making the assignments separately would fail?

 

The weirdest part is that we have a machine that has been running with this same scheme and almost identical scheduling and assignment code for years and hasn't had the problem.

 

Thanks

[steve.milici]

I think this is more of a technical support issue and I need more details. Call me at 818-998-2095 have me paged.