"Invalid Instruction" on download

[plcnut]

Here is a portion of the log file:

"S1356, Wed Feb 06 10:27:42 2013, System content changed by Default User (Program/Documentation)
S1357, Wed Feb 06 10:27:44 2013, Invalid instruction 0x83024709 at 5447.
S1358, Wed Feb 06 10:27:44 2013, Program validation failed! Reverted to old program"

I get the error when I try to download but not when I accept the program. I don't know which instruction is the problem nor how to find it, because I cannot find where to do a search by address.

[BobO]

That's a bug. You should never see that...ever.

It's apparently in a MEMCOPY instruction, and it is likely that Designer is allowing you to do something that the controller thinks is invalid. Please send us your program.

[plcnut]

I just re-did  series of 24 memcopy instructions (I added a pointer for indirect addressing for the source).
I will see if I can use a mover instead...

[plcnut]

It looks like the MOVER will work for me... now to finish re-writing...

[BobO]

I'm very sorry. We are still finding a few small bugs...and for some strange reason you have found roughly half of them.

[plcnut]

My current memory configuration is over 226,000 bytes, and there is still a ways to go. This system is very data intensive. I think my brain is getting a lot more of a workout than the Domore is though

[BobO]

Looking at the instruction validation, the only way it might have failed is if one parameter was bit and the other was not. I was not able to get it to let me create something wrong. I would really love to know how you did so...we'd really like to fix this.

[plcnut]

I'm working on replicating it...

[plcnut]

Here is an example that will do it:

FYI: I had this rung in a working TASK, but all of the source fields were a fixed address, when I went though and added the indirect addressing to the source field is when the error showed up.
I noticed though, that I can leave them all static, and change just the first one to an indirect, and it will download.

[plcnut]

I've been able to narrow it down to the MEMCOPY with the indirect bits as the source and the C bits as the output,
All you need to make it happen is this:

MEMCOPY:
source: C[V1]
number: 10
destination: C10

[Controls Guy]

I've been able to narrow it down to the MEMCOPY with the indirect bits as the source and the C bits as the output,
All you need to make it happen is this:

MEMCOPY:
source: C[V1]
number: 10
destination: C10

Does MEMCOPY allow the source and destination ranges to overlap?  I would think that it should.  If it doesn't like that, though, and if V1 is assumed to == 0 for the purposes of checking it (can't really check when the address is indirect, so maybe it just assumes 0), then it would view it as an overlap.

[plcnut]

I've been able to narrow it down to the MEMCOPY with the indirect bits as the source and the C bits as the output,
All you need to make it happen is this:

MEMCOPY:
source: C[V1]
number: 10
destination: C10

Does MEMCOPY allow the source and destination ranges to overlap?  I would think that it should.  If it doesn't like that, though, and if V1 is assumed to == 0 for the purposes of checking it (can't really check when the address is indirect, so maybe it just assumes 0), then it would view it as an overlap.

In the actual program I'm using 2 separate memory areas of the controller, Going from a user bit array to C bits.

[BobO]

It's definitely a problem with the controller's instruction validation. What you did should be legal and the test to verify whether both source and destination are bits or not bits if failing. Haven't looked into it yet, but I'm sure it is super simple.

This is obviously a test case that slipped through the cracks. We'll fix the test case and well as the controller, and make sure this particular one doesn't happen again. That's not to say that their aren't 10 more waiting in the wings though...