S7-1500 IOLink messaging... am I just mishandling the result ?

[Ken Roach]

I hope somebody might be able to help me who has done some IO-Link messaging using an S7-1500 (TIA Portal 17) and the CMx8 IOLink module for the ordinary S7-1500 platform (6ES7 547-1JF00-0AB0).

My goal is to send a series of three asynchronous messages to verify that a particular device has been configured correct. It's a Baumer DAB10-AL load cell signal conditioner.

All the ordinary IOLink functions work. The Process Variable happily comes through in the Input image and I scale it and it's fine.

But when I try to use the IOLink messaging library, the data payload always comes back as all zeroes.

I've tried numerous index and sub-index values. If I try a port that isn't occupied, or an index/subindex that doesn't exist, I properly get an error.

But when I try the correct index and subindex, I get a Done bit and a 0 = No Errors result code and... all zeroes in the target array.

Am I just handling the target array wrong ? The function block only allows the target to be a local temporary tag of type Array of Byte[0-231].

Is the MOVE_BLK the wrong instruction to use ? I've tried both an ordinary XIC, as well as a positive edge detection instruction.

I have looked at the Siemens example code for this function but they only invoke it as part of a much more complex example. And of course, theirs would work fine.

I admit I'm a Siemens novice on this, so if I'm mis-using the Temp memory or the array DB I'd be happy for suggestions.

 

[Ken Roach]

This looks like I just misunderstand this Siemens-provided function block and/or the Positive transition bit instruction.

If I add a Reset --(R)-- to set the IOLink_Read_1_Trigger to false after the instruction completes, the data arrives in the destination as desired.

Evidently because the Execute input stayed true for more than one scan, the Record output was written over with zeroes.

 

[bkottaras]

I believe most of their blocks need a trigger, (positive) transition detection to execute.
The trigger does need need to be maintained.
You keep an eye out on the right side of the block (outputs) in order to re-initiate, catch errors and such.

Of course I may be wrong, someone can chime in with more info.

 

[Ken Roach]

You're correct that this function block, like most, requires a positive transition on the .execute input pin, where I am examining the Boolean tag "IOLink_Read_1_Trigger". That bit does not have to remain True for the function to execute.

When the .execute Input goes true, the .busy Output comes on for a few hundred milliseconds, then the .done Output comes on, and a value of 16#0000 shows in the .error code output indicating success. The .readLen value goes to the correct number of bytes that correspond to the desired IOLink parameter (Index 86, Sub-Index 1).

If I leave the .execute Input true (as shown above) all of those values stay in those states. When the .execute Input goes false, they all reset to their default values.

That is all very reasonable and good, even if it's a little different from some other instructions and function blocks that I am familiar with.

What I find unusual and did not expect is that the data in the #Temp_1 byte array hold the result of the IOLink asynchronous parameter read only for one scan of the LAD program.

I think that is because it's a Siemens "Temporary" variable, whose scope is local to this Organization Block / subroutine, and whose "retentiveness" is just one scan of the program.

What made this more difficult for me is that I'm a complete novice with Seimens, despite having literally decades of PLC experience. I expected the --|P|-- positive edge bit detect instruction to work similar to the --[ONS]-- instruction in Rockwell, where the rung conditions to the right are true only for one scan of the program.

Instead, those rung conditions become true only on a false-to-true transition and stay that way until the bit goes false again.

 

[cardosocea]

Not totally related, but I believe Siemens maintains that standard behavior in many if not all their blocks.

I can't find the document now, but there was a manual for user communication with I believe TSND and TRCV that had a comms scheduler that looked at this. If I remember correctly, they used the error bit to copy across the error code into an array for you to track further down the line.

 

[L D[AR2P#0.0]]

This highlights the issue of diagnosing problems from screenshots rather than the code itself.

 

[L D[AR2P#0.0]]

I think that is because it's a Siemens "Temporary" variable, whose scope is local to this Organization Block / subroutine, and whose "retentiveness" is just one scan of the program.

Temporary variables will behave in different ways depending on the code block's 'Optimised' attribute.


For Optimised blocks, the temp data area is set to zero each time the block is called.


For non-optimised blocks the temp data area is not modified at the start of the call and the temp data values when the block is called will depend on how the local data stack has been modified by other blocks. For a trivial program e.g. OB1 calls FC1, the temp data in FC1 will be retained because there is no other block being called to modify the temp data area stack. There are numerous posts where users have 'used' this behaviour believing the temp data is retained between calls, only for it to come crashing down when the program structure is modified.

 

[JesperMP]

Is the #Local_oneshot_1 a STAT or a TEMP ?
If TEMP, then that oneshot will also work erratically.

 

[mk42]

For Optimised blocks, the temp data area is set to zero each time the block is called.

My understanding is that it is also initialized when the block ends.

 

[Ken Roach]

Thank you so much for your input and expertise, guys !

This function block came from a Siemens library for IOLink communications.

https://support.industry.siemens.com/cs/ww/en/view/82981502

Siemens also provides an example application that illustrates the use of a few of their product-specific function blocks that wrap up the ordinary LIOLinkDevice function block a couple of layers deep. But they don't use it in LAD or give an example of using it in an ordinary user application.

https://support.industry.siemens.com/cs/ww/en/view/90529409


I especially appreciate the insight that it may be a conventional Siemens approach to make the status bits and error codes persistent while the .Execute input remains true, but that the actual data payload will be present in the Temporary type tags only for one scan of the program.

When I click down inside the LIOLink_Device (FB50004) general attributes, the checkbox for "Optimized block access" is checked.

But the tag #Temp_1 is part of the routine I'm running this LAD network in, which happens to be OB128. It shows up in the upper local data definitions window with all the other Temporary tags. OB128 itself also has Optimized block access checked.

Clearly I've got some learning to do about how Optimized block access and Temporary tags work in the S7 environment.

I will surely be back with more Siemens questions, and will do my best not to phrase them as "why doesn't this work the same as in an Allen-Bradley controller" !

 

[kamenges]

Originally posted by JesperMP:

Is the #Local_oneshot_1 a STAT or a TEMP ?
If TEMP, then that oneshot will also work erratically.

That's a really good question and my personal odds-on favorite for the basis of the issue. The oneshot is "triggering" on many scans because the storage bit is quite often 0 even though one would expect it to be a 1.

Keith

 

[Ken Roach]

I think it was a little of both !

Originally I had just an ordinary --| |-- contact addressed to #IOLink_Read_Complete_1 on the rung that copies the data to another tag for examination.

But that didn't make the data visible in monitor mode because the data is only present for one scan after the .done Output goes true. The .done Output, and therefore the Temporary tag #IOLink_Read_Complete_1 stayed true because the .enable Input stayed true, but the Temporary array tag with the data payload was only populated with the result for one scan.

>The oneshot is "triggering" on many scans because the storage bit is quite often 0 even though one would expect it to be a 1.

Oh, this is a really good learning experience. I'm only a little embarrassed that I haven't learned all this stuff in a fundamentals class.

When I use a Global tag that's actually tied to M-memory as the storage bit below a --|P|-- rising edge instruction, it works like I expect. One false-to-true transition causes the subsequent rung conditions to be true for only one scan.

If I use a Temporary tag, it doesn't "store" the value, and the false-to-true transition is detected again on the next scan, so the rung conditions are true again.

Again, thanks so much for your perspective and input on this.