Step7 - Can someone tell me what's wrong with this!

[RMA]

This is the simple program I wrote to save the maximum values of some analog signals.

Initially everything seemed to work OK - the carrier tray number, date and time were saved in the first few Bytes of the target DB, but I had forgotten to copy the actual maximum value to the Target DB. I then added the last four lines in NW2 to do this and the CPU promptly went into STOP, complaining that I wasn't accessing a word boundary.

I can't see what's wrong with it - I hope someone else can!

Cheers

Roy

Oops, forgot to rename the file to .txt!

 

[L D[AR2P#0.0]]

You forgot to attach the code but my guess is you haven't multiplied by (8*no of bytes) to convert to pointer format !

 

[RMA]

No, it may be something equally primitive, but it's not that (I don't think!).

 

[L D[AR2P#0.0]]

What resets #cntr to zero - is this done outside of this block because when I run it the indirect accesses soon fall off the end of the data block I created (1800 bytes long)

 

[10BaseT.]

can you post the UDT ?

 

[RMA]

Simon, at this stage I hadn't implemented the reset of Cntr, I now check after loading it in NW1 that it doesn't exceed 511 and the DB has 512 UDT entries. If it does, I reset to zero and overwrite the old data. 512 entries is enough for about 4 hours of production.

10BaseT., I'll post the UDT in a few minutes, that will probably be my last opportunity to post today, though.

Cheers

Roy

 

[RMA]

OK, here's the UDT.

 

[L D[AR2P#0.0]]

If the number of entries will exceed 255 then you want to use the + 1 instruction instead of the INC 1 instruction as the latter only affects the lower 8 bits of the accumulator.

What about the calls to "DT_DATE" and "DT_TOD" are these your blocks or SFC's or what - I've had to comment them out.

 

[Polle]

just a guess:

L #Pntr; //Get base pointer to Target_DB
LAR1 ; //back into AR1
AUF #Target_DB; //reopen Target DB
L #Analog_Alt; // <-- this line i should add
T DBW [AR1,P#8.0]; //and transfer ...


Polle

 

[L D[AR2P#0.0]]

Well spotted Polle - this is a coding error that will result in the incorrect data being stored for the max analogue value - however, it does not explain the reported fault of an area write not on a word boundary.

Roy - can you post the exact event id from the diagnostic buffer please.

 

[L D[AR2P#0.0]]

OK - found FC6 and FC8 for "DT_DATE" and "DT_TOD".

For cases like this I don't load OB121 so the plc stops at the relevant point and you can then open the block at the offending intruction. You can also examine the I Stack to see the contents of the accumulators and address registers at the point of the error. (I almost always do this in the simulator though)

 

[RMA]

Polle, thanks for that, somehow I had convinced myself the value was still in AKKU1 although I had just loaded the pointer!


Simon, I knew that INC only operated on the byte, but didn't bother to check how many that was, I just guessed it was 512, oops!


Here is the diagnostic text and the stack. By the way, if you could briefly explain how to interpret the stack data, I would be more than grateful, I haven't a clue what to make of it!

Hey, I even remembered to switch to English!!!

 

[dchartier]

Hello RMA;

I don't know if this info adds anything to what you already know, but just in case:

Hope this helps,
Daniel Chartier

 

[L D[AR2P#0.0]]

Event id 2529 help as follows:

Cause:
A bit address (bits 0 to 2) was specified for byte, word, or double word access.

 

[RMA]

That's what puzzles me, because I've already used the value in "Pntr" - the base address of the UDT in the DB - successfully to store the WT-number and the date and time. When I go to use it again with Offset P#8.0 I get the above mentioned error - weird!