EthernetI/P RPIs. Another Marketing/Engineering Question

[Peter Nachtwey]

We have added a new feature to our latest motion control product. Our new product can do EthernetI/P I/O or implicit messaging at 1 millisecond intervals. However, just because we can doesn't mean we should. Our experience with our older product showed us that most people used RPIs in the 10 to 20 millisecond range because the ENBT card couldn't go any faster and the Ethernet starts having too many collisions.

There is no need to change parameters that fast. Anything that needs to happen that fast can be done inside the motion controller faster and in a more deterministic way than in the PLC.

I say 5 millisecond RPI is a realistic minimum even if we can go faster. First, can the PLC maintain a scan rate faster than 5 milliseconds. Second, given the Ethernet scan is asynchronous to the PLC scan is the effective scan rate even longer? Third, will the networks be capable of these higher rates? Fourth, will the EN2T card be capable of servicing the motion controllers and the HMIs and I/O. Fifth, any position feedback data coming from the PLC will be asynchronous so it would not be directly useful without filtering.

Has anybody used a RPI less than 5 millisecond? For what?

Note, the controller doesn't really need except to tell the controller when to start. The controller has its own program, memory and I/O so this isn't like the M02AE or M02AS where coarse updates are required.

A second question. How many I/O connections do you normally have to a EthernetI/P device.

Experiences wanted. We find the forum to be a valuable resource. Thanks.

BTW, we are still going round and round on the pass word protection issue I asked about last month. It sounds simple but.... In true Delta fashion everything is over anal_yzed. I want to scream. Back in the dark ages I would just do it.

 

[kamenges]

I usually use an RPI in the range of 10 msec regardless of the fieldbus. I haven't needed to put together any huge systems so I haven't had to worry too much about low RPI values. The only reason I go as fast as I do is I want jogs and other operator triggered actions initiated by the plc to happen as quickly as possible. Outside of that I could go much slower yet.


A typical system for us would have a single motion controller, possibly 4 or 5 free-standing drives and another 5 or so remote I/O groups. Given the analog/digital mix we usually have and that we usually use AB components we will have a nominal 4 connections per rack. The drives and motion controller have a single input and output connection each.

I have yet to run into an issue with any of the Ethernet I/P systems we have done. To a large degree I have found that speed is your friend. In a plc system it can cover alot of ills. No matter how you look at it your system can only be as deterministic as the controller at the head of it all, regardless of what you use to get information to the controller. Your standard PLC is not at the cutting edge of determinism.

Keith

 

[hokie]

The the enet/ip servo drives and motion controls controls I have worked allow a min of 5ms RPI. In practice I could see data updating on both sides at that interval, so it is realistic. I did not try lower, since those product limited it.

 

[Peter Nachtwey]

The the enet/ip servo drives and motion controls controls I have worked allow a min of 5ms RPI. In practice I could see data updating on both sides at that interval, so it is realistic. I did not try lower, since those product limited it.

Do you need faster that 5 milliseconds? If so, why?

 

[Peter Nachtwey]

We decided on 2 millisecond RPI

Why, because we can, easily. Keith's 'speed is your friend' wins.
Its a marketing thing. My thing is faster than band x's thing.

 

[kamenges]

Originally posted by Peter Nachtwey:

My thing is faster than band x's thing.

You know, Freud would have something to say about that.

 

[Tom Jenkins]

Why, because we can, easily. Keith's 'speed is your friend' wins.
Its a marketing thing. My thing is faster than band x's thing.

I don't know squat about motion control, but I see the same thing in analog I/O resolution. There is no point in using a 16 bit resolution analog input (1 part out of 65,000) when the transmitters are only good to ±0.5% (1 part out of 2,000). But marketing wins, and unfortunately the less informed the customer the more wins marketing has.

 

[TimWilborne]

Hi Peter

One thing that hasn't been mentioned is the size of your input and output instance. That may make a difference

I would say make sure it performs at 5ms. If I create a generic module in RsLogix 5000 it defaults to 10ms. I would say other controllers would be about the same and most programmers would not change this value unless instructed to. Which brings up a good point. Specify the RPI in your instructions for creating a module

 

[Peter Nachtwey]

Off Topic but important

I don't know squat about motion control, but I see the same thing in analog I/O resolution. There is no point in using a 16 bit resolution analog input (1 part out of 65,000) when the transmitters are only good to ±0.5% (1 part out of 2,000). But marketing wins, and unfortunately the less informed the customer the more wins marketing has.

If you need to use the derivative gain then extra resolution makes a big difference. One of the biggest sources of 'noise' is quantizing errors. Actually this isn't noise but non-linearity due to the stair step feed back. As the feed back resolution increases the feed back looks less like stairs and more like a straight or almost straight line. Now would you rather have 16 bit or 12 bit resolution for feed back?

I think it is such a joke that PLC5's have 12 bit resolution and the sampling is asynchronous. How can one use the derivative gain on a PLC5? It is no wonder there are so many people that refuse to use the derivative gain and tell others the same no matter how good their feedback is.

TW, those times are for insntances of 120 reals or the largest transfer that can be made. This is limited by the size of the bus interface of the ENBT or EN2T's inteface chip.

 

[kamenges]

I'm not sure what Tom is trying to say. If he is saying that the sensor output or sensing resolution is only 0.5% the the added input resolution does you no good. Trying to get a reading on the vertical portion of the stair coming from the sensor won't help you. If the sensor has 16-bit resolution but only 0.5% accuracy or repeatability then I agree with Peter. The greater resolution is a plus.

I think thee effect of the asynchronous update on the PLC5 is dependent on the time constant of the system you are trying to control. A 5msec jitter in a 2 second loop closure won't make a whole lot of difference, even in a derivative calculation. Now if the loop closure is 20msec, then the difference will be significant.

Keith