Fun with Profibus

What I have is a S7-300 PLC talking to a Rice Lake Controller thru ProfibusDP. My problem is The S7 talks faster than the Rice Lake can respond. So somtimes I get my value from my first request as data on my second request. With what I am trying to do this is not a good thing.

What I need to do is delay my requests so that I get the right responce. To the right Comand. I need to create some sort of pause between my message sending.

My other problem. I suck at programing Siemens. I know I need to build a time controlled sequencer but the how eludes me.

I can not get my mind around how IEC Timers work in Siemens. My tought is to create a pulse timer that triggers a counter and then use the counter accumlator valve to send my various messages.


I have 8 unique recipe messages, 6 modes, 2 product data blocks, and I need to read batch modes from the Rice Lake so I can control some feed valves.

Note: you can only send 8 bytes of data to the rice lake in a message

The First word is your comand what you want the Rice Lake to do the Second word is the parameter you want to use and the last is you value which is always a float.
If anybody has any ideas I would appriciate the help.

Right now I am kind of stuck

Clay B. said:

What I have is a S7-300 PLC talking to a Rice Lake Controller thru ProfibusDP. My problem is The S7 talks faster than the Rice Lake can respond. So somtimes I get my value from my first request as data on my second request. With what I am trying to do this is not a good thing.

What I need to do is delay my requests so that I get the right responce. To the right Comand. I need to create some sort of pause between my message sending.

Click to expand...

You know what to do. Are there any status bits in the return bits that you can use for handshaking? The slave device is poorly designed if doesn't provide some means of handshaking.

What data comes back?

Normally one of the input registers echos the command when the input data is valid. Other techniques use a bit that is toggled on the output and when the corresponding bit in the input goes to the same state the message is ready.

Another technique is to compare all the input registers each scan. If the input registers don't change after two scans then the data coming back in complete.

We have used both the toggle bit and acknowledge bit and the command echo technique. I like the toggle bit technique because it doesn't use as much space.

Hi Clay,

I know what you go trough, ricelake is not that easy if it comes to communicate over profibus.
A few weeks ago I had to communicate with one of their scales, and I must say that the support from rice lake is poor to non existing, however with some input from other people I managed to get the bloody thing going.
As you where saying, the rice lake unit correspond indeed extremely slow on the bus, sometimes it takes up to 3 seconds to get a response.
Give me an hour or so to find that FB back that used.

To be honest, I don't agree with using timers into you comms,

The best is to wait until you get a response from the rice lake, however you can use a timer as watchdog and/or auto reset of comms in case it hangs.

What you send to the ricelake (command, for example if 19 is reading and 20 is writing, and let say I want to read parameter 315, which is for example 567.8)

[19] [315] [----]
CMD ID VALUE

What you get back (status), should look like this

[19] [315] [567.8]
CMD ID VALUE

Only when the CMD and the ID are the same on status side, you know the rice lake is giving you the right info.

Hopefully this helps...

Peter Nachtwey said:

You know what to do. Are there any status bits in the return bits that you can use for handshaking? The slave device is poorly designed if doesn't provide some means of handshaking.

What data comes back?

Normally one of the input registers echos the command when the input data is valid. Other techniques use a bit that is toggled on the output and when the corresponding bit in the input goes to the same state the message is ready.

Another technique is to compare all the input registers each scan. If the input registers don't change after two scans then the data coming back in complete.

We have used both the toggle bit and acknowledge bit and the command echo technique. I like the toggle bit technique because it doesn't use as much space.

Click to expand...

Correct Poor Design. You do get an echo. The problem is when you go from Write to Read. The value of the echo may be the Write value instead of the Read. I noticed it when we first started building the system.

I did not get to concerned about it. I figured I would do something that I have done on AB PLC's before and just use a Sequencer with a time delay between data comands.

Well this is an S7 and I know it can do that. It is the how that is giving me fits.

Clay,

Can you give me the type of your ricelake device?

Clay B. said:

Correct Poor Design. You do get an echo.

Click to expand...

The wait for the echo before assuming the input data is good.

Clay,

Can you give me the type of your ricelake device?

Click to expand...

It is a 920i. The message for is 4 words consistant.

First word is Comand
Second word is Parameter
Third and fouth word is value

3rd and 4th word create a float.

What you get back is Comand
Second word is supposed to be status but I have yet to decifer what the values of it mean

3rd and 4th are value as a float.


I am using a SFC14 DPRD_DAT and a SF15 DPWR_DAT to send and recieve data to the Rice Lake. That part works great. I just need to figure out a way to space out my sends.

Clay B. said:

It is a 920i. The message for is 4 words consistant.

First word is Comand
Second word is Parameter
Third and fouth word is value

3rd and 4th word create a float.

What you get back is Comand
Second word is supposed to be status but I have yet to decifer what the values of it mean

Click to expand...

This is good. Send the command and wait for it to be echoed. Now there will only be a problem if the same command is issued twice. So send a command, wait for it to be echoed, read the data and then send a do nothing or no op command.

Found a Solution

Not sure if it is the best answer but it works.

I used a S_ODT Timer and used the output to one shot an add instruction. Based on the value of the add I load my data to be sent to the RiceLake. I then have multiple moves that take the counter to zero depending on the number of messages I want to send. IE if I want to send 3 messages I reset at 6. This gives me the dwell between messages I was looking for.

Thanks to everyone who helped me get past this hurdle on this project