Nikolay

AB Micrologix atomic memory read

6 posts in this topic

I am reading memory from Micrologix 1400 PLC with an external library. The documentation for the library says:

Quote

It uses SLC 5/00 Protected Typed Reads and Writes for messaging directly to a PLC’s EtherNet/IP interface slot

For example, let's say my program reads memory location N20 which consists of 4 words.

Before the read operation begins, all words in N20 are set to "0".

While read operation is in progress, the PLC writes value "10" to memory location N20:3.

Based on the data from manual (that it uses SLC 5/00 Protected Typed Reads), what will be the result of read operation? Will it include the value "10" that was written by PLC in the middle of read operation or it will be "0" as it was when the read operation begun?

In other words, are "SLC 5/00 Protected Typed Reads and Writes" atomic operations on PLC Micrologix 1400?

Edited by Nikolay

Share this post


Link to post
Share on other sites

The MicroLogix and SLC-500 operating systems are functionally single-threaded, so they service communication requests based on the data table values in between execution cycles of the control program.    There's no way that I am aware of for an element of a data table to change during the reading of an array of elements, even if it is changed by a Routine that is executed by a Periodic or Event interrupt.

Strictly speaking the data tables are "atomic" down to the Element level;   if you read N20:0 through N20:3, that's four elements, not one.

This is different in the ControlLogix family, which has a task scheduler and communications services in the background.   You can encounter (and I have) circumstances where data in an array changed during a communication operation.  I use the Copy Synchronous (CPS) instruction in ControlLogix to lock the source and destination tags when I need to assure integrity of an array of data.

1 person likes this

Share this post


Link to post
Share on other sites
Quote

The MicroLogix and SLC-500 operating systems are functionally single-threaded

In this case it seems that the tables should be "atomic" not only down to Element level, but fully "atomic".

Quote

if you read N20:0 through N20:3, that's four elements, not one.

Yes, and this is how I arrived to this question. The library I am using can't read 32 bit "L" files, but it can read N files. So, my idea is to store 32 bit integers as two 16-bit words in an N file. Then read N file and assemble 32-bit integers using bitwise operations. And I do not want to end up in a situation when a 32 bit integer stored as N20:0 and N20:1 arrives corrupted because word N20:1 was updated while the program was reading the table.

Share this post


Link to post
Share on other sites

Might I suggest that you store the "Status" in another N file, say N21?  There fore no data corruption can occur, unless that N20 File is bi-directional and requires status in the N20:3 position.

If the same file is required for bi-directional communications and data flow, then Mr. Roach is dead on and the the best authority.  Your code would have to reflect the sequence of events he describes.

Edited by pcmccartney1

Share this post


Link to post
Share on other sites

I found solution that satisfies my needs. I had to ask the original question because I thought that it will require two separate bitwise instructions to copy a 32-bit integer from an "L" file to two words in a "N" file.

I discovered the CPW (Copy Word) instruction, which copies blocks of data from one location to another. Since this is done in a single step, this solves my problem.

Share this post


Link to post
Share on other sites

Thanks for the clarifications and follow-up !

A MicroLogix or SLC-500 does not service communications during the program execution (with the exception of explicit SVC instruction interrupts), so there is no risk of having your loop or COP instruction be in between the instructions that assemble your data into the Integer data table when the data is read by the external program.

There is definitely that risk in ControlLogix.

CPW was added to the instruction set for the MicroLogix 1500, and then moved forward into the 1100 and 1400 controllers.    It was built to accept operands of differing data types, in part because of the addition of Modbus RTU to those controllers and the need to pack 32-bit Floating Point data into Modbus Holding Registers.   As you have found, it's also useful for manipulation of Long Integer data tables.

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now