Is there a simple way to add an off-delay to a digital input without pausing/slowing down the chart?
Is there a simple way to add an off-delay to a digital input without pausing/slowing down the chart?
Hey nickvnlr,
Just a couple of crazy off the top of my head ideas…
Like I said, little crazy.
If it were me (and aint you glad it’s not???)… I would want to understand the scan rate required and how often the current chart is scanning before I made a decision.
The eyes themselves actually have an adjustable delay-off, I was just hoping for something in the program that would give me finer control that could be easily changed. Come on Opto! Give me input delay-on, delay-off functions.
You could do this at the brain level with a Digital Event. Not sure if that would qualify as “simple” but it would not pause/slow down the chart. You can see/play with these in PAC Manager under Inspect > Events > Digital Events - Extended…
FYI - I notice with these Digital Events I can configure a fake output and have the Digital Event trigger based on your real input, Delay before the reaction which writes to a fake output you could look at in your chart. How does that sound?
Interesting. Can you expand on this? How do I know which events to work with? Is there documentation for this?
Thanks!
Nick
Yes! Form 1465 is what you need here. Just search for “digital events.”
But to give you an idea, here’s the quick test I ran to make sure the “fake output” idea would work.
I configured a Digital Event to trigger off of input 0 in slot 0 (the “emergency” switch on my Learning Center hardware):
Then I configured a fake module in my strategy, so I can look at this with my logic, see how all the XVALs came on (half a second after my input did):
Of course you’d also need some logic to turn off that fake output. But hopefully this gives you the basic idea?
What about seeding a timer while the point is in the opposite state you are looking for? When the state changes the timer expires…use “timer expired?” in the condition block.
[B]Just to clarify, I want a delay-off. ie. I want the program to act like the eye stays on an additional 0.5 sec. after it physically turns off.
To be honest, I thought delay-on, delay-off were basic automation functions… [/B]
Here is a basic diagram of what I am working on. Boxes of varying sizes come from 2 lines and merge into 1 line, traveling at ~118-120 ft/min. They come at irregular intervals and if boxes from the different lines come into the merger too close together, they get jammed up. So, there is an eye for each side that enables the computer to see the boxes/gaps and decide which brake to activate and when to activate it in order to create larger gaps between the two lines as needed. The boxes don’t need to alternate, they just need to not crash into each other. So if a brake backs up 10 or so boxes, no big deal. I want to be able to fine-tune the timing to increase box thorough-put and work in all scenarios. Does this make sense? Does this help?
120 ft/sec!!?? I think I may have received some packages from that conveyor once or twice 
Ha! oops. 118-120 ft./min. :rolleyes: These are fruit boxes BTW.
At 80 mph you could be playing real life fruit ninja!
If you need to delay the input, I’m thinking Ben’s option 4 / Robertson’s method would be simplest. No built in way to delay on/delay off on an input, only outputs.
I think there may be some issues in your chart that you posted. The blocks I circled in yellow have already been checked by previous conditions, so unless the inputs changed in the brief amount of time the block was running, I think you have some blocks that will rarely be reached:
I found one other option that I kind of like for this that takes advantage of the brain hardware:
If you configure the eye as an off time totalizer, then you can check that value if it has been off long enough. If the eye is “on” then reset the totalizer, if the eye is “off”, then check the totalizer if it has reached your setpoint.
Flow chart showing timer method and totalizer method:
If you follow the logic playing “what if” it will make sense. If one lane is empty, i don’t need to activate a brake, but depending on when/where the gaps are I need to decide which brake to activate. I need the ability to skip the first eye and go to the second eye and then check for the first eye to be made. Remember, the boxes don’t come at regular intervals (completely random).
Basically I need to “fake” the eye being on longer to cover small gaps where the boxes would (and actually do) run into each other because the snap pac processes the chart so quickly it sees the split second gaps. This is a good thing, but I want to control what size gap is OK. I can’t really slow the chart down because it does more than this little section. It actually does an identical section to this for another area in the shed and some additional traffic cop stuff that needs to run (basically) at the same time to catch split second timings in different areas. The processor is more than capable, it/I/both just don’t have the programming chops to make some of it happen easily I guess.
The eyes themselves have built in delay settings and for now they work, it’s just not ideal. The old ladder logic had some sort of delay-off function. I think Opto needs to add some input delays functions.
These might work. No matter how I look at it, I need to add a few more variables and read those as the switches instead of the physical switches.
My approach would be:
Seed a timer (dt_Photo_Eye_Lane_1_Blocked) with 0.5 seconds whenever the eye is blocked.
Instead of looking at the digital input point (Photo_Eye_Lane_1) in your logic to make decisions, look at the timer (dt_Photo_Eye_Lane_1_Blocked). If it has time in it, you consider the eye blocked.
Adjust the the timer seed to fine tune the timing.
Since we’re talking fruit-ninja speeds here and you mentioned “split-second” timing… I’d REALLY like you to address Ben’s concern:
I would want to understand the scan rate required and how often the current chart is scanning before I made a decision.
…since the rate your chart runs can vary due to a number of factors. You mention 0.5 seconds but what’s the range on that? Is 0.5 +/- 0.5 okay? (Like 1.0 - 0 seconds?) Or are we talking 0.50 +/- 0.01?
What logic to you currently have in your chart to make sure you’re in that range and will stay in that range if you add more logic in the future?
I just thought of this: Use the eye to trigger a on-pulse to a dummy output and have the logic check the dummy output status.
(not verified if this will work.)
I would say timing-wise, 0.1 sec. resolution. How do I get the scan rate of a chart? Before I turned on the eye delays, the chart was easily catching gaps at 0.01 sec. by my estimate.
Entire Strategy loop time is =<60 mSec. (for whatever that is worth)
No matter what, I think you are going to be creating something “extra”. I think a timer would be easier to understand than a dummy output.
If you want to minimize created variables here is some optoscript* that will only require your setpoint variables (unless you wanted to hard code them - I wouldn’t). This can be converted to blocks, but will require a holding variable for the off time totalizers.
if(IsOn(diEye1)) then
GetRestartOffTimeTotalizer(diEye1); //Or use a timer variable here
endif
if(IsOn(diEye2)) then
GetRestartOffTimeTotalizer(diEye2);
endif
//Must start strategy with one or both brakes on
if (IsOn(doLane1Brake)) then //Lane 1 is stopped, Lane 2 has the green light
if(IsOn(diEye1) and GetOffTimeTotalizer(diEye2) > fMinEyeOffTime) then
//Lane 1 has product, and nothing coming down Lane 2
TurnOn(doLane2Brake);
StartOnPulse(fBrakeSwitchDelay, doLane1Brake); //This will turn off the brake after the delay
endif
elseif (IsOn(doLane2Brake)) then
if(IsOn(diEye2) and GetOffTimeTotalizer(diEye1) > fMinEyeOffTime) then
//Lane 2 has product, time to switch lanes
TurnOn(doLane1Brake);
StartOnPulse(fBrakeSwitchDelay, doLane2Brake); //This will turn off the brake after the delay
endif
endif
*Not responsible for fruit flying through the air.
At 120 fpm, the product is moving at 24 inches / second - so I would want at least 100 msec resolution (2.4 inches of movement). As far as the controller catching .01 second gaps, I would guess that was inconsistent.