libnodave - Siemens 315 slow ethernet packets

[tkamrath]

I am reading data from a Siemens 315 2PN/DP using libnodave. I am using the built in ethernet port. When I read a small block of data (less than a packet) from the PLC something is happening so that I get the same data for 3 or four reads in a row. Then it gets an update. So I have 4 or 5 sucessive reads that are the same when they should be different. This happens over and over again so my data has a stair step in it. I am reading this block of data every 50 msec. When I do this with a Siemens 1200 I don't see this problem. Anyone have any ideas as to what could be causing this? I have narrowed it down to either libnodave or the PLC. Either the PLC is not updating the data to me at a rate faster than 50 msec or something is happening in the libnodave layers that is causing the buffer to not be updated so I get the same data on each read. Any ideas would be a big help. thanks.

 

[L D[AR2P#0.0]]

What size blocks of data are you fetching and what happens with larger blocks of data?

Does libnodave execute different code depending on the connected PLC type - if not then it points to the 315 internal update rate.

 

[tkamrath]

I keep all of my communications below the size of one packet. So the worst I am doing in this case is reading a block of 114 bytes.
The code is exactly the same as for the 1200 with a different slot value.
It really seems unlikely that the 315 is this slow. I am seeing 150 to 200 msec intervals. Maybe I have my PLC setup wrong?
This one really baffles me.
And I should also state that the time interval for my block read is around 10 msec. So it is like the read performs correctly but the data buffer has not been updated.

 

[KalleOlsen]

I am reading this block of data every 50 msec. /quote]

How often are the values changed in the PLC? Did you add a cyclic counter value to check? And what is the cycle time?

Kalle

 

[tkamrath]

my scan in the PLC runs in less than 5 msec.
I have a 4-20 milliamp device putting out new data every 20 msec. So the data is changing pretty fast. When I monitor the data in the PLC it is changing as I would expect it to.

 

[KalleOlsen]

Have you tried to manipulate the values for the communication load in HWmanager?

Kalle

 

[tkamrath]

If you mean the communication load percentage that defaults to 20%, I have. I changed it from 20% to 50%. I saw the block read time change. So at 20% it is about 10-15 msec for the block read. At 50% it drops to below 10 msec. But this has no affect on the duplicate data problem. I still get repetative data over a 150 to 200 msec timer interval. e.g.
2.343 sec, 34.5
2.393 sec, 34.5
3.445, 34.5
3.496, 39.6
3.545, 39.6
3.597, 39.6
3.645, 39.6
3.694, 41.9
etc.

 

[JRW]

How do you know the analog processing is putting the data
In your data block at those intervals?
Because unless your using the "fast" analog card (I forget what part number that is) the processing will not be 20ms
Check out the specs for your card.

Anyway- might be something to look at

 

[tkamrath]

I have made the assumption that the 300 series equipment is better than the 1200 series equipment. Are you saying that the 1200 analog module is faster than the 300 analog module? Remember, the 1200 seems to work OK.

 

[KalleOlsen]

Tell us what type of 300-AI card you use.
The 1200 had probably onbord AI?

Btw, did you try to increase a DW in OB1? Should give you readings with +10 every time (5ms /50ms).

Kalle

 

[L D[AR2P#0.0]]

echoing Kalle's comment - but do the increment in the timed interrupt block OB35 configured for 10ms. The 315's I have used slow down OB1 when you monitor the program for example.

 

[tkamrath]

The 300 is using a 8 X 16 bit 7NF00. The 1200 is also using an external AI, SM-1231.

I think you are saying to increment a double word value in the OB1? I have not tried that. I have relied on the scan cycle time that is reported by Step7. The scan time is always below 10 ms. I also assume that this value includes time used for interrupts to the scan. I have a PID that runs every 100 msec in OB35.

OR are you saying to get the system time in OB1 to see what the interval is that way?

Remember we are talking about 100s of msec here. The PLC is taking 100+ msec to update a data value from the AI to a memory location. I really thought this gear was faster than that, for what it costs.

 

[KalleOlsen]

I'll try to explain again, English is not my first language.

- Take one of the spare datawords within your telegram, say f.x. DB10.DBW20.
- In OB1, write this:
L DB10.DBW20
+ 1
T DB10.DBW20

Now this value will increase with 1 appx every 5 millisec.

If you fetch the telegram datablock every 50ms, you will now read this value, and it will bounce with appx 10 for every reading. Then you'll know if the slowness comes from the AI card or from the comm interface. See?

Kalle

 

[KalleOlsen]

I found this in the 7nf00 manual. I have read it half a dozen times, but am still not sure what is meant. If no one can explain it, I'll look up the German mother of this document.

http://support.automation.siemens.com/WW/view/en/8859629


High-speed update of measured values

A high-speed update of measured values at two channels of a channel group is three times compared to the activation of several channel groups.
Example: When channels 0 and 1 are active with 2.5 ms filtering, both channels return new measured values to the PLC at intervals of 10 ms. (with other settings, the refresh rate is equivalent to the filter setting.)
High-speed update of measured values is only possible if both channels of channel group 0 and 1 are active, that is, the "measuring method" parameter is set. However, only one of the two channel groups 0 or 1 may be active (not concurrently active.)


Kalle

 

[TurpoUrpo]

This is what it means. Oops, wrong module.