• ### Member Statistics

5,752
Total Members
501
Most Online

Joined

• ### Posts

• Ever since it started raining, all my wife has done is look through the window. If it gets any worse, I'll have to let her in. ...ouch!     🙂 🤛
• The timing period has to be exact, whatever you decide on.  That is the entire basis of the concept.  Basing it on scan time is not sufficient. This is why it uses the interrupt in Vision, as it is exact and interrupts the scan, if necessary, at the exact time interval. Someone else can perhaps comment on your logic, as I don't use Unistream.  But your deviation observations match what will happen with the basic timing error, as it will increase proportionally the quicker the shaft spins. cheers, Aus
• Hello Flex, Thanx fot the quick answer. MB146, end of the day desperate try to change something... The program is attached. Steinemann070820 - V001.2.vlp
• I did something similar in Unilogic but I am not getting accurate results.  Attached is the program itself. On the first rung I am stacking up an MI that I am assuming   its increasing at a rate of 1ms based on the scanning time. On the second rung my proximity pulse clrears the first MI and stores its value to a second MI. Then I am converting my stacked up MI into milliseconds to get the period and converting them to seconds for the final RPM calculation. (RPM = 60/T) My test rig is a motor at steady speed rotating a shaft that I get proximity pulses from. Testing with various instruments I know I have 31 rpms but my program outputs 40 rpm. And I also noticed that at higher speeds the deviation is larger whereas at lower speeds the deviation is smaller.
• Not necessarily.  That was just to cater for the slower interrupt on older Visions.  Enhanced ones can also do 1.25ms.  The principle is what I was showing you.  The smaller the time the better, you just tailor your maths to suit.  But at something doing a maximum of only 120rpm you don't need to be going overboard. cheers, Aus

×