Anyone Bored?

[arkansascontrols]

Simon,

Had a small disaster with a shipment of mislabeled actuators 110v devices don't like 230v for some reason. Anyway, I have had some time to step through the changes you made to the routine (by the way got it working very nicely now) many thanks to you. And I have a couple of questions for you. As you may have figured out my brain won't let me accept something just because it works, I have to know why. I didn't actually just load the routine you sent back, I implemented the changes individually and systematically until I found exactly what was broken in my original routine.

Please explain if you can the functional difference between

LAR1 #SomeVariable
and
L #SomVariable
LAR1

Also please explain why a KNOWN integer value stored in DINT variable type will not correctly translate unless you load it as 2 byte variable and convert it.

L W[AR1,P#0.0]
ITD
T #diDintVariable
and
L D[AR1,P#0.0]
T #diDintVariable

should both result in the same value of diDintVariable if the value of bytes 0 and 1 are both 0's

In other words an integer value stored in a DINT variable type will remain entirely with the two latter bytes so regardless of how you get the two bytes copied to the 4 byte variable the resulting value of the 4 byte variable should be same.

But what I found was that only these two changes (above) were necessary to my routine to make it work with the INT types I was testing (I had quite a lot wrong with the reals but had not begun testing them yet). Also, initializing the variables solved a problem I was having with random miscalculations, but I understood that one.

Thank you again for your guidance on this.

Eric

 

[kamenges]

It's been a while since I've done much Siemens stuff but I'll take a crack at this.

Originally posted by arkansascontrols:

Please explain if you can the functional difference between

LAR1 #SomeVariable
and
L #SomVariable
LAR1

I've never seen a reference like the upper one. I'm a bit surprised it even compiled that way. By definition LAR1 takes the contents of ACCU1 and copies it to AR1. I would guess with the upper example the processor would grab whatever happened to be in ACCU1 and send it to AR1 regardless of the value of #SomeVariable.

Originally posted by arkansascontrols:

Also please explain why a KNOWN integer value stored in DINT variable type will not correctly translate unless you load it as 2 byte variable and convert it.

L W[AR1,P#0.0]
ITD
T #diDintVariable
and
L D[AR1,P#0.0]
T #diDintVariable

I'm pretty sure the Siemens PLCs are big endian machines. This means the most signficant byte is lowest addressed byte. Let's assume for simplicity that the pointer above is starting at byte 0. In the first case you are referencing the first two bytes of the double (bytes 0 and 1) as a word. This happens to be the MOST SIGNIFICANT BYTES of the double. The ITD moves these two bytes to bytes 2 and 3 of ACCU1 and clears bytes 0 and 1 (or loads them with ones if the number is a ngative number).

I think you would have gotten what you expected if you would have coded:

L W[AR1,P#2.0]
ITD
T #diDintVariable

Keith

 

[arkansascontrols]

Keith,

Thanks for the reply. Regarding LAR1, that makes sense now that you say it, although I could swear I've seen it done the way I asked about, I've resigned myself to the fact that I imagined it.

As for byte 0 and 1 being the most significant bytes of a 4 byte data type, I'm certainly not well versed enough with Siemens to argue that point, but have a look at this; this is some data I retrieved during some Pointer format testing I conducted, notice in the table I conducted byte reads of all 10 bytes, then word reads of the first 6 bytes and a dword read of the last 4 bytes. Word 0 is not a good example because byte 0 always contains 10(hex), but look at the value of word 1 versus the value of byte 3 (word 1 is byte 2 and 3), in the table (other than the first entry)

TYPE# of ItemsDB NumberMemory Location10|typeqtyDBMemory Loc PointerByte 0Byte 1Byte 2Byte 3Byte 4Byte 5Byte 6Byte 7Byte 8Byte 9Word 0Word 1Word 2Dword 0DB100101901000006410191064db100.boolarray1020206484000100226484000000db100.boolarray[0]1010106484000100116484000000db100.boolarray[9]1010106484009100116484000009db100.bytearray1020A0648400101002A6484000010db100.bytearray[0]10201064840010100216484000010db100.bytearray[9]10201094840058100216484000058
Word 1 value is consistent with the value of Byte 3, which would be the least significant byte of that 2 byte datatype.

I'm really scratching my head over this one, but thanks again for the reply.

Eric

 

[arkansascontrols]

WOW, that didn't format right at all, let me retry that this way:


in .csv format (but with .txt extension) attached

 

[arkansascontrols]

Keith,

To reiterate though, my data collection doesn't confirm or deny how 4 byte data types are handled, and you may be right about how which are the LSB and MSB, I'll have to test that today. I'll post the results for anyone else who may be following the thread.

Also I have a pretty nice spreadsheet developed with a whole lot of data presented, some simulated SLD functions and data conversion macros all based on a data collection function I wrote to help me better understand the pointer formats and ANY variables. If anyone would find it of interest I'd be happy to post it.

 

[RMA]

The addressing in Step7 is Byte oriented and as Keith said, it is Big Endian, i.e. the MSB is the least significant Byte. This would be best represented by a picture, but I can't get it to format correctly, so words will have to do!

Let's take MB10 as our basic Byte. MB 10 is no problem , a Byte is a Byte is a Byte!

MW10 is a word of which the MSB is MB10 and the LSB is MB11.

MD10 is a DWORD with MSB = MB10 and LSB = MB13.

Just to add to the problems and confusion, although most people use the convention of starting WORDs and DWORDs on an even address boundary the interpreter and the hardware do not force you to, so you could address MW11 and would access a WORD having MSB = MB11 and LSB = MB12.

As you can see this means you can't mix and match INT/DINT or WORD/DWORD addressing when handling parts of a four Byte data set!

To go back to your problem with debugging, this is one that hits virtually everyone, because, as far as I'm aware, it's either not documented, or stuck somewhere insignificant in the Megabytes of Siemens' help info.

You have to select the "Online" view in Simatic Manager and then open the block you want to test. Opening it Offline in Simatic Manager and then using the "Online" View facility is not the same! Having got the debugger working, there is a further trap waiting for you, particularly when testing loops. If you set a Breakpoint in a loop, the CPU will stop the first time round at the Breakpoint as expected. However, if you now click on the arrow to make it run the next time, instead of stopping at the Breakpoint, the program will run continuously. You must move the Breakpoint to a new position in order to get it to stop again!

This isn't as big a pain as it sounds - once you got used to it, it cost me a few days wasted time before I sussed it out! - because you only need to move the Breakpoint one up or down and normally you can do that and still observe the data that you need.

 

[L D[AR2P#0.0]]

AR1 question:

LAR1 dwPtr

will load AR1 directly from dwPtr without affecting the accumulators

L dwPtr
LAR1

will load AR1 from dwPtr but the accumulators will be affected.

e.g.

 

[L D[AR2P#0.0]]

L W[AR1,P#0.0]
ITD
T #diDintVariable
and
L D[AR1,P#0.0]
T #diDintVariable

My assumption here is that the code in bold above was from the original code section that was reading and summing integer values from your array. It is just simply wrong to read a double integer from an integer array as you would actually be reading two consecutive integers into the double integer resulting in garbage!

You are using a double integer to sum the integers so the ITD is required to sign extend the integer to a doulble integer in preparation for the +D

Hope this helps.