RMC70 Profibus Message Mode

How about a Profibus message mode for RMC70 like you have for the RMC100. Move more data at a time.

Good question at the right time! We will very soon be working on adding PROFIBUS support to the RMC150, and we have been considering making a new mode for it. This means we may also add the same mode to the RMC75P. Peter would like a mode with less restictions on it; he just wants a bunch of registers that go back and forth, with no command area, or read/write bits or anything. He would like it more like our EtherNet/IP I/O (notice that our EtherNet/IP I/O does have a SyncIn/SyncOut register). We have also had comments from some customers that they want an easier mode.

If the new mode were to work like our EtherNet/IP I/O, we could for example use part of the the Indirect Data for the Input and another part of it for the Output. Then the user could access anything he wants.

A very efficient method of communicating with the RMC is to use a Variable to trigger user programs from the PreScan Table. For example, if the variable is 1, the PreScan Table would start a certain user progoram. If it is 2, the PreScan Table could start a different program. Each user program should then reset the variable to 0, so the same user program could be triggered repeatedly. With a PROFIBUS mode like I mentioned, you could easily do this. Also, if the user program uses some variable that needs to be updated before each run, all you need to do is write to the variable table, and it will update those variables and start the user program at the same time.

It sounds like your request has more to do with the amount of data rather than how we structure it. I understand that not all PROFIBUS masters - at least in the past - support large amounts of data. Is this still true? What size data blocks would you like? How should we structure it?

Now is your chance to influence the design of a soon-to-come PROFIBUS mode! Tell us what you would like!

Jacob Paso

I know we have talked about this in the past. There is a greater need for reading data than writing data. I think you need at least 32 reads. I agree with Peter it just needs to be a read/write area not a command area. While the machines are running you are just reading and writing the same data each time. When setting up the paramters then a list of variables need to be sent. This can be done in loops using the same read/write area. So as long as you have a large enough read/write area you will have no problem.

How would you do the writing in loops? For example, if you need to write to 40 registers, and have a write area of 32, I suppose you could send the first 31 registers, then have a user program grab the data and put it where it’s supposed to go, then write the rest of the registers and run another user program that grabs that data and puts it where it should go. Is this what you envision? How about the SyncIn/Sync Out registers? Is it acceptable to have them, or would you prefer none? With these registers, the RMC does nothing with the data coming from the PLC to the RMC until the Sync register has been changed. When it changes, the data is applied to the RMC.

Thats how I do it now. I will send you a sample. You don’t have to change all 32 you can do them 2 or 3 at a time however many are left over after you read the standard items you want to read.

I don’t think they are needed. The control variable that you use to start the programs in the prescan table is used as the index. To send data down I set it to 3000. Then in the prescan table when the variable is >= 3000 then I call the program. Look at the index and set the value where it needs to be then set a varible back = to 3000. When the plc see’s the return value change to 3000 then it increases, etc etc etc.
I don’t want to post my program here for everyone but I will send it to you.

How much data are you moving? What kind of data are you moving?
You are right about the S7 not needing synch registers but other Profibus DP masters need them.

Profibus DP has a limitation of being able to read or write only 64 INTs or 32 DINTs at a time and keep data consistency. Data consistency is important because problems will occur of parts of two different commands get downloaded at the same time. This is not enough data to write commands to all 8 axes at the same time. However, the RMC can be programmed to execute commands in the user program triggered by a command and 31 32 bit registers. This would be the easiest thing to do. The command defines the data. The RMC then writes a 0 back to indicate it is done. This is what a lot of our Ethernet/IP users do. However, the Ethernet/IP users also have a MSG block that is very good at copying many thousands of registers with just one command if the need arises. Profibus DP can’t do that without imposing a real protocol like we did with the message mode but that would use 5 DINTs out of the 32. It is possible to combine some of the registers but then that would require more screwing around in the master computer to get all the fields right. Let alone the problems caused by the big and little endian formats.

CharlesM, what would be best for you? The complete message mode with the 5 DINT registers for specifying read address, read length, write address , write length and command bits or the simpler the command defines the data mode?
I am pushing for the command defines the data mode for starters. This is easy for us and easy for the users because they define the protocol but this also forces them to use user programs to respond to the commands. Message mode requires programming on the master side. Most people have a hard time indexing through data tables on a S7 so the message mode is hard to implement. What is a pain is that everyone want an example program for their obscure PLC or Profibus DP card.

I think that would work best for me.

I think 32 dints at a time would be fine. Most everything is Dints/reals. If anything else is needed it can be put into one of these without any trouble.

This is some what related. When you send a command over Profibus you have command paramters 1-5. Where do these go into the RMC? I’m not sending commands over but I may be able to use the command data to send more data.

On the RMC100 the data goes to mapped memory. That is data you can read and write. The problem is that it two devices are sending commands they will write over each other.

The RMC75 and RMC100 have a queue that is accessed by writing the commands. This way commands from two different sources will not write over each other. The down side is that this data can’t be read because it isn’t at a fixed memory address.

I think it would be better to tell us what you really want to do. How much data needs to be read or written from where in how much time? We had a meeting last Wednesday and agreed the 32-32 bit registers in and 32-32 bit registers out is the way to go. This conforms with your ideas in your previous post. If necessary one can implement a message mode using 32 registers. The first register would be the command, the second would be the address and the third the length. That would allow transferring 29-32 bit registers per scan.

The command would be a DINT and a new command would be issued by toggling the most significant bit. I suggest making the command the same as the program number. The RMC would see the change is the most significant bit or command and strip off the bit and use the command to execute a program the does the desired function. The RMC would then echo the command in the area that the master reads. When the master sees the command and the echo are the same it knows the command is done and a new one can be issued.

Great that answers all my questions.

Thanks Peter