Allen Bradley SLC 5/03, M0/M1 data file

Hello guys,

I am new to allen bradley systems, and I have question about access to M0 and M1 data file.

I have SLC 5/03 processor, with prosoft MVI46-DFNT Ethernet module.

From my understanding, the client request to MVI46-DFNT, the SLC 5/03 transfer data from internal database to M1 file and MVI46-DFNT reponse to client. I believe data flow is using serial DF1 through Ethernet TCP/IP interface.

However, I am not clearly understand:
1. At the client side, what kind of data type I should expect to receive? Would it be M file or regular registers(like B and N type)?

2. If that is M type, is RSLinx the only software can process the M file?

Because I read a post said the prosoft MVI46-DFNT is not able to communicate with wonderware. However, as long as both client and server driver can read DF1 through TCP/IP, should it be fine?

Unless the server is responding the M file, and the client can not read the M file. This situation will cause a problem?

Is there any Allen Bradley expert could give me some advices or correct some of my statement? Because I am not sure I am in the right directions.

Thank you so much for stopping by!

"Module files" are a little different from ordinary integer and binary data files in the SLC-500 operating system.

M-files can only be accessed by ladder logic instructions. Most Prosoft modules make use of COP and MOV instructions to read and write the M-files, which are then handled by backplane communication routines that are part of the operating system and not accessible to the user.

RSLinx cannot access M-files. Wonderware cannot access M-files.

From the perspective of client software, the Prosoft MVI46-DFNT module emulates Integer (N data file type) data files.

The Prosoft module is NOT transparent. It does not provide direct access to the actual data tables inside the SLC-500 controller memory, but instead emulates that data type to provide access to its own internal database.

I found a Prosoft knowledgebase document from 2010 that suggests that Wonderware can't communicate with these modules, but it provides no details about why. It's been a few years, so it's reasonable to ask that question again to Prosoft.

Ken, thank you for your help!

I asked prosoft regarding to the reason wonderware and prosoft not able to communicate.
Although wonderware and prosoft both are using DF1 protocol, they have different DF1 commands in the driver. Seems the best way to talk to the DFNT card is using RSlinx.