BASIC IDE Delay Logic

Ewon Support Ewon Flexy
#22

Can I have each ONCHANGE pass a function a variable of either 1, 2, 3, or 4 so I can use conditional logic to check that value for whichever hopper triggers the function call to start the timer, etc.

So if Hopper1 ONCHANGE call Func(1), …, Hopper4 ONCHANGE call Func(4) and then in the conditional logic of that function it will take action accordingly?

To me this would be perfect in the “example for pj.txt” you provided to use for the delay_count@ variable where in that example it is incrementally going up by 1 per the ~= delay_count@+1 portion. In that example it seems whenever that multidelay() is called by any trigger it will just add one to the current variable. I think something like this but each ONCHANGE or specific tags passing the function an argument int and then check that.

I also like the logic idea about basing it off time but I think I need to have be able to set time1, …, time4 as separate variables per each hopper and then be able to have conditional logic take action for each if time greater than +3 seconds of that time or whatever otherwise loop and keep checking until that’s true (no more than 3 secs tho for example).

I’m not sure I’ll be available to work on this during normal hours anytime soon at the moment and tied up from 8 AM - 5 PM.

Is phone support ever available on the weekends or after 5 PM on the weekdays? In the meantime, I’m fine with this forum as nothing is urgent or broken.

I look forward to testing out some of this logic you provide and get something working for the need.

#23

Hi PJ,

Can you send me something like a block diagram showing what you’re trying to do?

#24

I don’t have a diagram but I’ll see if I get time if I can make something but essentially we have two hoppers, two receivers, and two transporters. Each hopper has a fill valve that once it [opens] starts filling we start the data collection with a deadband of 1 until that same fill valve closes (plus 3 seconds after).

The fill valve is a BOOL data type but that’s is what ONCHANGE needs to monitor for each hopper to “trigger” the conditional logic to set the deadband accordingly based on the fill valves opening and closing.

I only need to get the weight values from the “other” things (receiver, hopper, transporter) when the hopper file valve is opened and then 3 seconds after it closes. Each hopper (for example hopper1) has it’s own set of “other” things that are not shared with the other hopper (e.g. hopper2).

If hopper1 fill valve opens, I need to then collect the weight value by setting deadband to one for receiver1, transporter1, and hopper1 [weight] until hopper1 fill valve closes after 3 additional seconds. So hopper1 has it’s own set of “other” things that’s not shared with hopper2 and hopper2 will have it’s own set of “other” things.

Essentially I want to control the eWON to say, when this Hopper boolean tag goes X then turn deadband on for these three “other” tags until this same tag changes again but to X then wait an additional 3 seconds, and then turn deadband for these “other” tags to a negative value so data is not logged to the historical file for those tags.

So if I have two hoppers and two fill valves and think of it as if each hopper is not even related to the other at the plant level but each hopper has its own set of separate “other” tags that are correlate to the respective hopper only.

I need to only have Hopper1 and Hopper2 fill valves share the same logic or function to make each wait 3 seconds when the respective hopper fill valve closes to turn off logging for the respective “other” things without hogging up a bunch of TSET's since I use those for other logic too.

Maybe what you provided already will work for this scenario but if I can figure out a way to make a diagram or something I will—I won’t be able to share any diagrams from the actual plant though but I suppose I could draw up a generic sketch or something if i get some time.

#25

Ok thanks, I was just thinking something along the lines of like a block diagram where it would say something like Trigger 1 -> if time is X -> hopper 1, -> wait 3 seconds - Do X. I’d check if the code above works first but if it’s running into issues, it will be easier to debug with a block diagram I think

#26

Can you tell me “in general” during the “wait 3 seconds” per the above you wrote latest about, will during that wait time before it does the “Do X” will other running logic in the init still take action from taking action or is it executing the 3 second wait and not executing other logic during that time such as another ONCHANGE trigger?

With other programming code I’m able to emulate these sort of scenarios but I’ve never really been able to do that with the eWONs unless the PLC programmer is right there sending the tags data, etc. while I’m testing the BASIC code.

I could answer this question myself if I had a way to safely emulate changing tag data which the eWON collects. I think understanding this will help me understand what the best approach is I need to take on the 3 second delay logic.

#27

So in the code that I provided, it is based off of an ontimer. This means that it will execute the code each time that ontimer is reached. In this case it will be triggering on a counter that will count up every 3 seconds. So that means that once the timer hits 3 seconds and the counter increments, it will do the code that is specified in the onchange section. Or in this case since it’s based on some if statements, it will begin as soon as the counter changes to the specified number. To test it you could just try and have the ewon write to another internal tag if you want to make sure that the delay is working