Host Engineering Forum
General Category => CTRIO and CTRIO2 => Topic started by: rln401165 on February 20, 2014, 12:29:22 PM
-
I am using a H0-CTRIO module in timer mode to display line speed on a 6in micro thru the scaling wizard with
PLC=
C and D set to edge timer with free run and enable timeout selected. In the scaling wizard setting= interval mode with output format set to BCD(rounded).
Counts/units=1.4 and time base=minutes.
The scaling is working and seems to be accurate but the display is jumping around a bit too much.
The problem is when I attempt to use the data smoothing feature I lose output from the module to V memory at both the scaled units and timer data V memory locations. If I reset data smoothing to its lowest setting everything is back up and running.
Anyone have the same problem? Any ideas?
-
What frequency do you expect your timing events to occur at? What is the timeout value set to?
-
The max is 4-5 Hz and the time out is set at 5 seconds (in micro sec) but I get the same results with the time-out not enabled.
Would the free run cause this? I did not try without the free run.
-
Would the free run cause this? I did not try without the free run.
No. We're looking into it...
-
It's broke. Working on a fix.
If you set smoothing to max (36 samples) or min (1 sample) it will work fine. Anything else is busted...
-
Thanks BobO. I am not sure what broke means but I will keep checking back. I am using ladder logic filtering now but it seems to slow down response time considerably.
-
Interval smoothing is fundamentally broken for every setting except fully off (slider all the way left) and fully on (slider all the way right). We should have a firmware patch shortly.
-
Thanks BobO. I am not sure what broke means but I will keep checking back. I am using ladder logic filtering now but it seems to slow down response time considerably.
You don't have a surfeit of bandwidth which is the root of your smoothness / delay tradeoff.
At that frequency, you don't even need a CTRIO. Just time the duration between pulses, push the results into a queue, and use the total of the last five or ten in computing your display speed. Make sure to debounce the pulses both on and off, so you're not counting bounces. If that's the equivalent of what you're doing, I don't think you'll do any better without a higher resolution input. with most PLC's, you could probably count to maybe 50-75Hz without a counter module.
-
Hi Controls Guy
My problem with not using a ctrio is the timer resolution of the fastest timer in on DL06 is 1/100 of a second. @1/100 of a second the line speed difference at 250FPM is off 12-13 FPM with accuracy getting better on the down scale but still not correct.
If there is another way to do this with a 1/100 of second timer I would love to know it.
I could get reasonable accuracy with a millisecond timer but alas the 06 does not have one.
The inputs are fast enough for my use but as far as I can figure out the timer won’t work. Unless someone smarter than me can figure it out.
Here are numbers and may be you can tell me how.
Line movement per pulse=10.2 inches.
Pulses per revolution= 8
If you can figure it out I will be forever grateful.
Attached is my cals.
-
Hi Bobo
Could you possible let me know where and when I can get the firmware patch?
I have 6 lines running and 2 more I'm working on that are using this feature.
Thanks Ron
-
I've identified the problem, have corrected it, and in my testing it seems fine...however...on a different system running the fixed code we're still seeing something we don't completely understand. I need to understand whether it is really an issue or not, and as soon as I'm convinced, we'll post the new code for download.
-
Thanks BobO I'll checking back
-
@rln401165, the timer resolution actually doesn't matter (or doesn't have to), if you write your program so the resolution-related error is non accumulating.
For example, say I have a flow number in GPM, and I want to totalize flow over a period of time. I could use a 1 second recycling timer, and add the GPM/60 each time it expires. This method should work, but due to scan time, the time when I see the timer is elapsed isn't exactly one second after the previous time. If your scan time is 20ms, you might check (scan) the timer at 1.01s, add the value, and reset the timer. For this iteration, your total is 1% low, even if the GPM number is right on. You might even have another 20ms of delay if you can't expire the timer and restart it all in one scan and it takes till the following scan to restart.
One way to avoid that is to let the timer free run, don't have it recycle at a setpoint. Then each scan, check the ACC value. If greater than your desired sample period, totalize and subtract the sample interval from the ACC (DO NOT zero the ACC). Then the ACC will reach the sample interval earlier, you still won't catch it on time due to scan delay, but each sample will be much closer to the desired interval. Right on the sample interval in fact, if your scan time is consistent, but more importantly, a series of n samples will always add up to n x sample interval + ONE error - ONE error (the start and end errors may not be identical), even with a variable scan. You've made the error non-cumulative.
Then if keeping a rolling average of something (like your line speed), you keep a queue of the last 10 values. Most of the errors get compensated away and what's left isn't near as bad because it gets spread over 10 samples.
The other thing to watch for, especially in a case like yours (few events per unit time), is the difference between fixing sample time windows and counting events and using the time between events as your sample value. Picture a scope trace of your pulses with two seconds showing. At 5Hz, you'll show about 10 pulses at any given time. When one ages off screen, unless another one appears at exactly the same instant, the total count goes down by 10%. When one appears it goes up 10%. If you were displaying line speed based on the scope trace, it'd be jumping up and down 10% all the time. You could compensate with a longer window to make one pulse a smaller percentage of the total, but the response to a real speed change will be slower. If you could stop the line abruptly, the display wouldn't reach zero for 10 seconds or whatever. That's what I was saying, get more pulses per second and you'll get a more palatable degree of trade-off between smoothness and quick updates. The other method, timing between pulses, doesn't have the abrupt up and down issue, but you'll have to watch for the types of latency issues I was talking about with the analog example, and make sure your logic doesn't lead to cumulative error.
If you used the system clock or other single, non-resetting source as your timer, the sub-resolution increments take care of themselves, possibly shifting into an adjacent time window, but doing so at both ends and thus compensating.
IOW, bottom line, just make sure the error is non-cumulative and you should be fine. Get more pulses per foot, and you'll get a better trade-off between response and noise.
-
Hey Controls Guy
At first reading I think I understand your point. I am going to save your comment and study it through so I fully understand it. But that being said I have already purchased the modules and have six lines in operations with two more on the slab.
These lines are wire drawing lines and a few FPM can change the tempering of the wire, which if off could yield 4000lbs of scrap and once the operator commits to line run the line cannot be stopped without the same results.
I did at one point consider something along the lines of what I think you are talking about but I chose’s to go with the CTRIO because one will run two lines and one hundred dollars per line is insignificant compared to the potential loss. With the CTRIO I thought I would know, with high resolution, the true line speed at any point in time on one pulse intervals. I also plan on doubling the pulse.
Things being as they are I will have to stick with ctrio’s on this project but also I will try, as soon as I understand, what you are talking about.
As I said I am forever grateful for your time.
Ron
-
Ron,
OK, that makes sense. I was under the impression the number was only for display rather than control. Even so, with a pulse rate than can be handled in either ladder or CTRIO, I don't think CTRIO will do any better than ladder (maybe it will just because of the more precise timing). But the other point is valid -- get many many more pulses per ft and you can react more quickly to a disturbance. Not double, I'm talking about hundreds or thousands of pulses per ft. Stop trying to do the bolt / gear tooth thing and get an encoder. They're $100-200 and the CTRIO will have no problem digesting the pulse rate. You could go old-school and use an analog tach to measure line speed, which give a very high resolution signal instantly, but then you'll have to investigate filtering and acquisition time on the analog input you use.
Even so, if your speed control is critical in order not to create scrap, and if it has to respond to disturbances, you might need to put it outside the PLC. Get a vector drive that will accept encoder feedback, make sure the drive wheels are constant radius (not too squishy if soft coated), and let the drive regulate the speed. It'll do a much better job than either the CTRIO or ladder.
Steve
-
Oh, and you're welcome! ;D
-
Hey Steve
Your right of course, but when I first became involved in this project I was not aware of just how critical the line speed was.
I thought because of the low 4to5hz I could handle that easily through the 06 with a fast timer, and that the line speed was only needed for reference, which it is, in a indirect sort of way. But it turns out that the operator monitors and makes incremental changes through the touch screen due to die wear and other things like payoff drag etc.
In the old infamous saying on hindsight, I would have done things differently had I known what I know now. Just goes to show you, you can never know too much about the process you’re trying to control. At any rate I see and encoders run process in the future with VFDs keying on their input, but at least I already have the CTRIO’s.
The thing is I retired 8 years ago but they won’t let me go. But the tech is so much better now and changing so fast it’s hard to keep up. I will probably spend my last days trying to figure out why one damn thing or another won’t work like I want it to.
Ron
-
Just a follow up. We do have a fix which works great on Do-more, but for reasons we still don't understand, it seems to pick up one bad sample (of 0us, we suspect) on DL PLCs following a program to run transition, resulting in a single abnormally high value. It's obviously far, far better than before...since it wasn't working at all...but I would really like to understand and fix this issue before we release new bits into the wild.
-
Thanks BobO
I will keep checking back
-
Hey BobO
Downloaded and updated one of my ctrio2 mods with your firmware update dated march 10,2014 named v1.0.3. pop-up said already have this firmware but updated any way, I think. But data smoothing is still non-functional except min. and max. The fix said"Fixed a problem in data smoothing with interval scaling where smoothing would only function correctly when it was set to MIN or MAX values".
zip file contains two files;h0ctrio2_1_0_0.ga and h0ctrio2_1_0_0.os.
Is this the wrong update? Please advise.
Ron
-
OS version should be 1.0.3...which would be H0CTRIO2_1_0_3.OS. Not sure why the update didn't work. I'll email it to you.
-
Download the ZIP here --> http://www.hosteng.com/HW-Products/All_Hosteng_Firmware_Files.zip (http://www.hosteng.com/HW-Products/All_Hosteng_Firmware_Files.zip)
-
Thanks guys
I've got the update but they haven't had time to install them yet as all six lines are 24/7 since I sent them the correct version. But I'm in the process of building 2 more lines and will have some time to play with the ctrios.
I have every confidence the fix will work due to the great support I have received on this problem.
Thanks again Ron