Quantum equivalent to Siemens S7-300 or S7-400?

interesting the highest end 300 series processor the 319 is faster than the high end 400 series 417.

so far the extra expense of having one PLC per unit isn't justified by the cost of downtime for all units instead of only 1 unit due to a PLC failure, which is a low likelihood event. our average plant is less than 10MW.

we only have the one PLC, although remote IO racks can be the same for each unit. governor control in past designs has been hardwired back to the main rack and not over communications bus, although I'm considering moving to remote IO for the HPU control as well.

Remote IO with quantum is over modbus, with IO scan time of 10ms. IEEE 125 deadtime is 200ms. say 50ms to sense the change in speed, 50ms to calculate the desired change in control variable, 50ms to operate the output and 50ms delay in the action of the hydraulics and the deadtime requirement for IEEE 125 is met.

100ms is allocated to PLC time there. Say the scan time was as high as 20ms, the PLC would still be fast enough to process the input and make the change in output to have the governor respond within 200ms.

In practice scan times on quantum PLC I see are much less than 20ms, so I don't see PLC processing power as being a limiting factor (with Quantum, and assuming S7-319 is just as fast). But please elaborate on any experiences which indicate otherwise, I haven't found many people I can discuss implementations that meet IEEE 125 with.

Meeting the 200ms deadtime in IEEE 125 doesn't guarantee good performance or meeting the speed stability index specification either, so perhaps scan time plays a part in that, although I would have thought it would be mostly determined by resolution of speed sensing and precision of the control of the torque applied to the turbine. Perhaps we should start a new thread for IEEE 125 if you are keen to talk more in detail about the requirements?

thanks for your thoughts
 
You need to factor in as much as 125 ms for the response of your hydraulic system. IEEE says that you need to begin moving the gates in 200 ms after a disturbance. If you have a distributing valve with a pilot proportional valve, the delay can be as much as 125 ms especially if it is an old valve with alot of leakage. This leaves you with 75 ms program time.
We typically run our governor timed interrupt in a 10 ms cycle. So, one interrupt to id the grid change and one to react to it. This leaves you 55 ms of float. We also do our valve control loop in a 10 ms loop which takes up another 20 ms leaving you with 35 ms remaining.

Yes, the 319 is faster and the limitation is more in the number of I/O points that you can handle. Which is what my original suggestion was based on considering that you have 3 units worth of I/O.

This of course gets easier in terms of PLC overhead if you have an external valve position controller, but it still needs to be factored in to your overall response time.
 
interesting stuff. I haven't been counting on 125ms for the proportional valve, although I've only been using new equipment.

Here is a typical proportional valve that might be supplied
http://www.hongta-group.com.tw/html/parker/valves/PDF/Direct-Operated_d1fp_s.pdf
which specifies a 3.5ms step response time, and 400 ml / minute leakage with zero-lap spool. Perhaps the volume of the cylinder is 2 or 3 litres. I assume 3.5ms is the response time of the spool, and the delay in actually moving the actuator would depend on how far it is from the HPU, if it connected with pipe or hose, slop in any linkage, etc.

and poppet valves would be similar to
http://www.parker.com/literature/Literature Files/IHD/SVsection.pdf
which shows 40ms response time for Series GS02 85/86, and then as above the response of the mechanical system on top of that.

thanks for your thoughts
 
125 is typical when you have a proportional valve as a pilot to a distributing valve. Of course if you can drive the gates directly from a prop valve than you take out a whole lot of time in the equation.

The important thing is that you need to utilize interrupts in Rockwell land or use the fastest OB in Siemens-ville...(I forget which one as I am a lead engineer, not a programmer) The point is that you need a deterministic scan time for your governor time so you can guarantee IEEE 125 performance.
 
Ah yes, haven't run in to any proportional valves driving other valves yet. Must be something you get in to on different size or type of units.

I can see how running the speed control in an interrupt also helps cut down on variability and processing time.

Any plant I've worked on in north america that did run islanded had a stand alone governor so meeting IEEE 125 was in someone else's court. grid-tie plants larger than 10MVA undergo model validation testing. It will be interesting to go back over the data and see how closely IEEE 125 is met.
 

Similar Topics

Hello All, Was hoping I could get a little help with Modicon ladder logic. This is the first time I have seen Modicon logic and currently trying...
Replies
6
Views
273
Hi There, I have a Modicon Quantum PLC, there is a alarm on display "noConfig" its happened after power failure, I have gone through manuals...
Replies
3
Views
655
Hey guys. Mostly new to this stuff so I apologize if I'm not following proper format. I have 3 working CPU133 /3s. There is a desktop with a...
Replies
2
Views
894
When i read the specification of 140CPU43412A i observe that as remembered in specification 1. Local i/o : Maximum i/p and o/p words are 64 in...
Replies
0
Views
501
Main rack contained power supply 140cps52400 and 140cpu43412A and RIO HEAD 140CRP93100 in addition to another I/o cards . Another remote rack...
Replies
8
Views
1,867
Back
Top Bottom