Should i use a normal DC input or high speed?

Others have run the numbers and compared to PLC scan times, so I won't retread that. Suffice to say, I agree, HSC is realistically the way to go. I do have one thing to add, however, that I haven't seen mentioned yet.

Something to keep in mind as you think about this is that if you want to count the pulses you realistically need both a high signal and a low signal. Thus, if your PLC has a 1ms scan rate (1000hz), the fastest signal you can detect is 500hz.

When I was in school, this was referred to as the Nyquist Theorem. Feel free to google for more info/explanation.



The Nyquist Theorem I did find some info on last night when I googled what I am trying to setup. I still don’t fully understand it, but I’ll do some more reading thanks for the heads up.

The scan time of 1ms is the quickest a normal dc input will get on the ML1400, if I use the HSC’s built into the ML1400 the scan time will become a non issue, from what I understand.
 
I do something similar with my 1400's, but I chose to go the 1 input per revolution route as some have already suggested.

You mention awful resolution at low rpm as the reason not to do that. How are you calculating your rpms from the input? A running average should give you the same accuracy across your speed ranges.
 
i started off with a single bolt on a collar; a timer, say T4:0 , with a .PRE of 10 seconds,
then a CTU for the bolt in question, then just math after that. Once the timer runs out there would be logic that would execute so for example if the CTU had 4 in the .ACC, MUL CTU .ACC 4x6 and then would get you your RPM. you would have to mess with the timer .PRE to get it working well depending on the RPM you were trying to calculate. So the issues i see are say it could work well for a lower RPM, 10 or below, but once you got up in the RPM range it would not be as accurate, say 25RPM or above. could i have something setup in the logic so that it would use a different timer base depending on the CTU .ACC (since it would be higher if the shaft was going faster) im sure i could, but id like to just figure something out as i have been discussing in this thread. the last setup i did i used a trigger wheel with 20 teeth and a normal DC input in the ML1400 and it worked well when i needed to calculate max of 22rpm. im not sure how accurate it was in the lower RPM range though, i never tested it to be honest. the way i got 'more resolution' with that setup though was by using OSR and OSF in the logic so that it was actually counting the leading AND trailing edges of the 'teeth' on the trigger wheel. as for the shafts that spin at 1200rpm, currently i just use trigger wheel that i waterjet and bolt that to the end of the shaft and its cutout in a manner so its half 'on' and half 'off' when the sensor sees it and its cut in a way so that it still balanced at that higher speed. again, works well ONCE the machine gets up to speed, but for that time that the shaft is spinning up to speed its not very accurate. hence why i would like to attempt to go a different route all together with how i accomplish this for the machines i program for the OEM i work for.
 
i attached what i assume will work logic wise for what i would like to do.

T4:0 will last for a second, during that second the HSC.ACC value will constantly be moved to N7:0 and then divided by 30, the number of teeth on the trigger wheel, then placed in an F8 file. Once the timers .DN bit is set it will move the F8:0 value to F8:1 and reset the timer. The F8:1 value will be what i can display on the HMI for an RPM reading. I ordered an encoder simulator to hook up to the ML1400 i have here to test this out, hopefully all goes as planned.

HSCRPMSetup.jpg
 
Last edited:
Instead of counting inputs during a specified time period, record the elapsed time for 5 or 10 inputs. That should be more universal across all speed ranges and you would never have to alter any timers.

If your end goal is just a reliable rate counter you can get there without adding the use of function files or re-wiring anything. If you keep it to just logic without function files, it's generally easier for someone down the road to decipher or an end user doing troubleshooting
 
this is just how ive always done it, minus the use of a HSC. Im not totally following what you are suggesting, but im open to trying something different if youd like to explain.

i assume you mean count the amount of time it takes to get the HSC.ACC to 5, then just do the math to figure out what that would be over 60 seconds? If not, im totally lost with your suggested method.
 
If all you are doing is checking RPM, why not use a single flag for each revolution instead of 60? Why make it complicated when simple will do?

Using just a single flag gives awful resolution at low rpm.


It is what I do. I agree the rpm range for which you can accurately monitor is somewhat limited at the low end. Usually I do do not need to know the rpm's with surgical precision. Two digits precision is plenty good for my purposes.


If the shaft is turning too fast to detect a single bolt, then we use a nylon wheel with one half covered with a stainless steel strip (we call it a "half moon wheel"). Makes the ON pulse last just about as long as the OFF pulse.


Some PLC brands have special input cards for frequency measurement. These are designed to handle much higher frequencies, e.g. like the 30 or 60 tooth wheel on the 1200rpm shaft, with ample precision. The hardware is a lot more expensive than a regular digital input. Depends on the control problem at hand whether or not it is worth paying for the multi tooth wheel and input module.
 
It is what I do. I agree the rpm range for which you can accurately monitor is somewhat limited at the low end. Usually I do do not need to know the rpm's with surgical precision. Two digits precision is plenty good for my purposes.


If the shaft is turning too fast to detect a single bolt, then we use a nylon wheel with one half covered with a stainless steel strip (we call it a "half moon wheel"). Makes the ON pulse last just about as long as the OFF pulse.


Some PLC brands have special input cards for frequency measurement. These are designed to handle much higher frequencies, e.g. like the 30 or 60 tooth wheel on the 1200rpm shaft, with ample precision. The hardware is a lot more expensive than a regular digital input. Depends on the control problem at hand whether or not it is worth paying for the multi tooth wheel and input module.

We currently do that for the 1200rpm max shaft that I need the rpm from, but if I can get this to work with the HSC that’s built into the PLC we are already paying for, then I see that as a win win.
 
this is just how ive always done it, minus the use of a HSC. Im not totally following what you are suggesting, but im open to trying something different if youd like to explain.

i assume you mean count the amount of time it takes to get the HSC.ACC to 5, then just do the math to figure out what that would be over 60 seconds? If not, im totally lost with your suggested method.

Yeah that's pretty much what I was suggesting - HSC or not should work at that lower rate. The key is using the input to determine when to start/stop the calculation rather than a default timer. With a default timer you could miss an input right before it starts or right after it ends, so having a slower rpm rate miss a few samples obviously throws off the accuracy.

On an event like machine running start your rate counting process, which would clear a counter (preset of 5 for example).
Shaft input turns on initially, start a timer with a max preset and millisecond base.
Shaft input turns on again, increment counter, and keep incrementing every input until the preset of 5 is reached.
At the counter done/5, take the accumulated value from the timer. Then it's just the same ol math to see how much time per input (revolution) to get your rpms.

After the calculation you can reset the rate counting process, timer, and counter/hsc value.
 
As I look back on the last machine I did I actually used the OUTPUT of the motor on an XIC to turn the timer on. Versus what I posted above with the timer DN XIO being the initial trigger for the timer.

I’ll put your idea to screen tomorrow and see which I like best. Cases like this I normally have a few other people in the shop who don’t program look at the logic and see if they can follow it, figure if they can hopefully a tech at the end user can too, lol.

Also I normally make sure that the timer PRE is something easily multiplied up to 60. So the math works out. Don’t want to be counting how many pulses happen in 9 seconds then try and interpolate from there.
 
Last edited:
Yeah that's pretty much what I was suggesting - HSC or not should work at that lower rate. The key is using the input to determine when to start/stop the calculation rather than a default timer. With a default timer you could miss an input right before it starts or right after it ends, so having a slower rpm rate miss a few samples obviously throws off the accuracy.

On an event like machine running start your rate counting process, which would clear a counter (preset of 5 for example).
Shaft input turns on initially, start a timer with a max preset and millisecond base.
Shaft input turns on again, increment counter, and keep incrementing every input until the preset of 5 is reached.
At the counter done/5, take the accumulated value from the timer. Then it's just the same ol math to see how much time per input (revolution) to get your rpms.

After the calculation you can reset the rate counting process, timer, and counter/hsc value.


This works fine until the shaft stops. It will then take forever to count to 5 pulses once more and the last value for frequency remains in effect while this does not properly reflect the true shaft rpm anymore (which is now zero).



That is why in addition to this basic idea I include an additional timer for "time-out": if it takes longer than this timer's preset time to get my 5 pulses, then frequency (and thus rpm) is assumed to be zero - in other words: I assume that the shaft has stopped rotating.
 
i noticed once i got my encoder simulator today and setup my logic that i missed a step. i attached the photo of what i ended up doing that works, didnt want anyone else coming along one day and attempting to use what i posted and have it not work.

HSCRPMSetup.jpg
 

Similar Topics

Hi, I am working on automating an industrial fabric shrinkage tester to replace its outdated electronics with a PLC. To get the tank's water level...
Replies
14
Views
502
In a control System, I need to move 3 motors attached to roller in stages with speed of 1 to 2 RPM and the torque of motor should be 8-10 Nm...
Replies
0
Views
816
Hi, I want to build a production line project using a PLC. This is the project page...
Replies
14
Views
2,058
See picture. I want to add a rung (magenta) into the existing code. Can't figure out how to do this. I select a -||- , right? When I drag/drop...
Replies
21
Views
1,697
Sorry for the basic question: On my HMI, I've created a button labelled SAVE to save the current values (distances in mm). It's not linked to any...
Replies
22
Views
2,132
Back
Top Bottom