PLC speed limit or which PLC to choose?


Thread Starter

Waldemar Lederer

Our company develope and produce liquid dispensing and metering equipment. To manage motor,2 pumps and a few sensors we use Schneider Twido PLC.

Now we have a bigger project. 6 motors will be used at the same time, 5 of them will need accurate speed control. Previously i had a problem with catching signals from sensors. This problem was solved by reducing the motor speed. The speed is now about 100 rev/min. The pulses from sensors are about 10 msec, will be shorter if the speed increases. The customer wants more speed, but there are another speed limiting issues as well, except PLC.

Untill now, I don't know, was it my mistake as a programmer, or the PLC was not quick enough. When I tried to count siglals after logical operations inside PLC it did not work at all. To get the machine running the logical operations were executed outside PLC and all logical operation from PLC input and counter input were removed.

The power input of one sensor (proximity switch) was connected to the logical output of another sensor. So the logical AND function was made.

Now question, should we continue to use TWIDO PLC for the new project (if the problem is because of my mistake), or migrate to another platform? Which one?

Electrical Engineer
100 revs per minute is 1.67 revs per second, or one rev every 600 msec. You should have no problems sensing that. I think the problem is likely the flag the sensors are detecting is too narrow. What is the target the sensor is detecting? Why can't you just make this wider? That should give you a wider pulse.

If the problem isn't the sensor target, then the sensors themselves are too slow and are taking too long to turn on. Have a look at the sensor specs to see how fast they are.

From your description, the PLC you have right now should work fine.

Waldemar Lederer


thank You for the answer. The target is to detect position of moving part inside the machine. The smaller the moving parts and the bigger the speed allowable, the better is the machine. But, in the same time, it makes the pulses short.

The sensors are quick enough. The pulses can be clearly seen on an oscilloscope and on their datasheet frequency is allowed up to 3kHz.

Ken Emmons Jr.


A lot of PLCs come with (at least) 10ms filters built into the input circuit or through digital filtering. This is the most likely culprit.

If you want a simple low cost PLC with fast inputs I can recommend Keyence. I've used them with fast signals before with no problem. You have to make sure to set a special register in them to switch the input circuits to high speed operation. I don't recall offhand what it is, but talk to your keyence rep before buying it to make sure you get the right thing.

I don't know anything about the Twido, but I would dig into their documentation to see what the input response is. If it is not advertised contact your rep.

I don't know what your budget is and if this system would be appropriate, but the Mitsubishi Q series has a general purpose input card that can respond down to something like 100us. I've used these and measured the response and it is truly just limited by the PLC scan rate which is normally about 0.5ms for a decent fast processor without a lot of code in it. I have a fairly loaded machine that gets up to about 0.8ms. Don't know if their smaller PLCs (FX) have fast IO, but this might be a good option if they do.


William Sturm

The high speed input is probably a wise idea.  Keep in mind that the filters are there to reduce the possibility of false triggering from noise spikes or AC line induction.  For high speed inputs, you should consider a shielded cable properly grounded and routed away from noisy power sources.

Bill Sturm
Abbeytronics LLC

Waldemar Lederer

Hi Ken,

thank You very much for the valuable information. Build in filter, that is , probably, an explanation for the failure to work on the high speed. But, why it did not work on the relatively low speed, when some logical operations ("Logical And", I had to cut off wrong signals) were applied to the input pulses before counting?

Regards, Wal
If the pulses are short followed by a long off period perhaps you can extend them with some sort of RC network (I assume they are DC pulses). Another option is to Divide by Two using a CMOS chip, that way you will get a nice even 50:50 square wave.

This is a common problem in screw and rivet feeding through blow tubes. The usual solution there is to use a "pulse stretcher". This is an off delay timer which "stretches" the pulse out so the PLC will see it. This feature is usually built into ring sensors for this reason. I don't recall seeing it in other types of sensors though. However, some people do this with conventional off delay timing relays.

Some small PLCs have "pulse capture" high speed inputs which do the same thing (they stay on for one scan after being triggered). Some also have high speed counter inputs which do something similar. I don't know of any that have this for half a dozen inputs (usually just 2 to 4), but it is something you can investigate.

The fastest small PLCs that I know of are the ones made by Keyance. You may want to look at what you could do with those.

Goran Vuckovic

Depending of model, Twido has up to two very fast counters, and has also reflex output, so it would be solution. It is explained in Twido help files.

However, it is small PLC, and it is intended for simple solutions. Maybe you should consider to put price aside (if it is possible), and buy some stronger PLC, for example Schneider M340 (much stronger, but stil affordable).

Waldemar Lederer

Hi Roy,

This is an interesting idea. But as far as I remember, CMOS chips work from 3 to 15 VDC power supply. How to interface signals to PLC, which usually work with 24 VDC?

Ken Emmons Jr.

I am not sure why your AND did not work. Sometimes it is better to do logic outside the PLC, but if you can get fast inputs you have all the logic available inside the PLC with no circuit headaches (I am an EE and I have seen the simplest circuit intentions end up into a full blown project...) :eek:)

What I do in these situations is to get the PLC set up for high speed inputs (by changing the digital filter value) and put an oscilloscope or logic analyzer on the input. Then you write some code to "mirror" the input signal to an unused output (We also have fast outputs on our PLCs). Keep in mind that you need a transistor output, and if it is sinking (NPN) you need a pullup resistor (1k ohm would do) to 24VDC. You should see your output signal mirrored but by time shift of one scan time.

You could probably have a look at your two logical AND signals with a scope as well. I'd be a little leary of the AND in the way you are doing it, but I honestly can't say why it would be a problem because I have no experience doing that. I'd worry about the first signals output impedance and curent capability. In other words you could be supplying "bad" power to the second sensor. This is just a guess though.

Dear Sir

Insted of using PLC's you can go for motion controller. It will give you more efficency and faster too. Baldor motion controllers can handle upto 220 axis at a time and they can communicate using ethernet so there you will not face any problems like speed and all. PLC's having speed limits, by using controller and drives it will be more economical and efficient than PLC's

with thanks and regards
Denson k o
Baldor Electric India

Robert Trask, PE

Using EtherCAT and the XFC concept by Beckhoff all you need is two pulses. These pulses can be time stamped with less than 1 microsecond resolution. And this is off the shelf hardware.

Then, with a little math, a comparison can be made in a controller, even a low cost one for a very accurate speed determination which can be used for motion control.

Peruse for details:

Contact Beckhoff for more information. It does not involve high priced components.

- Bob Trask -

Waldemar Lederer

Measured response on a mirrored output of TWIDO. A written program inside the PLC had about 100 rungs. Sent pulses 20ms long with 70ms period, from a similar another PLC. The delay on the positive front was about 12mS and 14ms on the negative one.

Ideally period should be 50ms (I used timer), but two scans were probably added, and general period was about 70ms.

Schneider representative advised to migrate to M340 and promised 5 times delay reduction with standard CPU (8.4 times with advansed one).

Waldemar Lederer

What about general cost to migrate to EtherCAT?

Is it better than using fast PLC like: Omron CJ1H, or Mitsubishi Q?

Regards, Wal