CCW the COP instruction and 0xF860 error

[technolog]

We're converting a machine's control from CompactLogix to Micro800.

It was originally going to be on a Micro850. However, because we've ended up using hundreds of COP instructions to handle the part program management (recipes, basically), the program will no longer fit in an 850 and we had to upgrade to an 870.

I've just made a raft of edits to get the part program copying and deleting functionality working. It only involved removing DINT array variable array element subscripts, e.g. changing program_1[0] to program_1. These are used on the source and destination inputs to the COP instructions. I've also edited some length inputs to the COP instructions from 82 to 1.

Since downloading these edits, we've been experiencing random faulting of the controller (2080-LC70-24QWBK). The error code is 0xF860 which appears to be an overflow error caused by a divide by zero error. I guess I could have made a typo but the only edits were on the COP instructions' source, destination and length inputs.

I'm not at work now but I'll have to check for typos tomorrow. I just wondered if anybody had any experience of 0xF860 faults when using the COP command. Are there any diagnostic tools in CCW that point you to the location of the error?

 

[5618]

This doesn't answer your fault question, but tonight I did a bunch of COPs in Micro820's and I wonder if you're burning memory by creating a separate COP tag for each instance of use. The help file shows an example with tag COP_1 as data type COP. That COP_1 can be used multiple times within the program or controller level where it's created.

Tonight's stuff looked something like this:
COP_1 (True, RealValue1, 0, CLXReadDINTArray[2], 0, 1, False);
COP_1 (True, RealValue2, 0, CLXReadDINTArray[3], 0, 1, False);
...and so on with one COP_1 defined for many actions. Ladder will work the same.

 

[technolog]

Thanks for the response.

I finally tracked down the divide by zero error. It wasn't in my edits. The fact that my edits worked exposed a divide by zero error elsewhere in the code.

I didn't mention it in my original post but, since adding the code to get the part program functionality working, I've been battling with CCW being really, really, REALLY slow. I mean locking up for 10 minutes plus. It only seems to be while connected to the PLC that there are issues. My CCW laptop is somewhat underpowered but it's never given my problems before on any other program. But I borrowed my colleague's high performance laptop (24GB of RAM and a good processor), installed CCW on it and it was just as bad, if not worse. I'm thinking it must be down to the size of the PLC program with the hundreds of COPs.

If I'd have had more time, I'd have tried incorporating all the part programs into one array and used the OFFSET parameter of the COP instruction to point to the correct part program rather than use a separate array for each of the 50 part programs, which entails using 5 or 6 COP instructions for each part program.

I think I'll open a case with Rockwell and get their comments on the code.

But for now, it's beer o'clock