Action performed once per week

[Ausman]

OK, progress report. 

It's late, I've been spending far far too much time on this but it's my usual dog with a bone type thing.  I've got the main basis of how it works running perfectly.  It only needs a little finishing off/tidying up and I'll post it as a sub.  But I have to get some attempt at nods right now, and tomorrow is a full day again.  So it might be > 24 hours but........it will work great.

 

Please wait........please wait............please wait.............!

[Ausman]

edit, minor changes....please read a few posts down after reading this one.

OK, I wanted to get this out of the way and it's done.  It was written and tested on a 130.  Attached is the version as a sub so that it can be easily imported into whatever.  Remember to import this as a NEW project, otherwise the operands will stomp on existing things and perhaps go completely astray.

Don't forget to either make it the main routine, or do a call.  Indeed, in the final implementation, the call itself could maybe be run by SB2 (or SB13 or none at all).

As far as I can tell, this works fine.  You can wander through the logic and find that it extrapolates the UTC that will exist at the next desired time, does nothing until the RTC goes past that, which then initiates the cycle again. Have fun figuring out the formula....that's your schooling for the day.   I played/tested with this all the time by simply rolling SI37 over to a new week, along with doing different times. Variations in the trigger calculation timings are easily done.

I initially started on the count method but ran into stumbling blocks.  Realised the best way was UTC based.

For ease of watching/checking what goes on, rung 5 needs some things put into your display:

Place MI1 on screen as a number to check the counts.  It should remain at 1 until the trigger time is passed, where it should add 1 to the count. 
Place MI30 on screen as a UTC set to show the default DD/MM/YY    HH:MM:SS.   It shows the next derived trigger time.

I did not use seconds in the formula as I considered it unnecessary.  Indeed, it would probably be ok without minutes...but hey, I was in the mood...sort of...by then it was making me very grumpy!  I love/hate this sort of thing.

One curious thing that happened during development was that initially all the RTC SIs would NOT function correctly in the formulas I was developing.  I needed to convert them to MIs and even then things went astray.  It sent me nuts.  In the end I did it all as separate maths.  In finishing it all off, I again tried things using direct SI reads in the formula, and it all worked fine.   Huh?  I truly don't know why this happened, but perhaps it was combinations of MIs and DWs in my initial workings that the firmware doesn't like.  It is also possible, but unlikely, that repeated Init and Resets helped cure this.  So I'd do a few of them on the new project if it plays up....but it shouldn't.

I can now get back to what I need to do!  I'd like to think we might call this Ladderart.  But if you find something wrong, let me know.

Cheers, Aus

 

 

 

 

UTC_OnceSub2.vlx

[kratmel]

Thanks for the work done, I liked the formula and the minimum amount of code.

I analyzed the subroutine and came to the conclusion that it will not work if the PLC is simply turned on constantly (the subroutine starts with SB2, which probably should not be there). Flex mentioned this in the first post.

 

[Ausman]

Ahh, I had forgotten that bit.......

On 5/4/2022 at 11:19 PM, Flex727 said:

if the PLC remains powered on continuously.

I was focussing on on and off varying times all week.  Anyway, because the solution generates a definite time in the future I don't think it's going to be too hard to change.  I agree that perhaps SB2 is not needed, but I'll go over things again when I can, keeping in mind the extra rule, and post the solution.  I always try to do my code so that the PLC is doing as little as possible all the time...hence SB2 in the first place.

cheers, Aus

[Ausman]

So I've slightly changed things.  The change did not get rid of SB2 but simply changed it to SB13.  Agreed you could leave it out completely if wanted, but I did it along the lines of my "save the plc doing unnecessary stuff" mentality.

I've altered the sub above accordingly.  I'll send Flex the bill.  🙂

cheers, Aus

[Flex727]

4 hours ago, Ausman said:

I always try to do my code so that the PLC is doing as little as possible all the time

You know, I do that often myself, even though we have to realize that the PLC doesn't care in the least.

[kratmel]

8 hours ago, Ausman said:

"save the plc doing unnecessary stuff"

This is a general trend towards energy saving. By turning off the extra light bulb, we are sure that somewhere it becomes easier for the electric generator and less emissions are released into the air

Probably simplifying the code to the required minimum, we unexpectedly do something similar

[Flex727]

4 hours ago, kratmel said:

Probably simplifying the code to the required minimum, we unexpectedly do something similar

Hmm, I question whether simplifying code reduces energy consumption in the PLC. It can definitely reduce scan time, which might be important for programming reasons, but I don't think it would detectibly reduce energy requirements.

[kratmel]

1 hour ago, Flex727 said:

I don't think it would detectibly reduce energy requirements.

Test result on table with V130-33-TA24. No input and output active. Backlight =100%

Downloaded blank project and no info on display ------ PS +24V Ips=76.8mA

Downloaded real project with 10 subrouting and floating point calculation, no info on display   ------ PS +24V Ips=92.3mA

Reduce backlight from 100% to 0 %  = approx -13mA in both tested project.

Then downloaded code add approx 0.36W of consumption.

 

[Flex727]

1 hour ago, kratmel said:

Test result on table with V130-33-TA24. No input and output active. Backlight =100%

Downloaded blank project and no info on display ------ PS +24V Ips=76.8mA

Downloaded real project with 10 subrouting and floating point calculation, no info on display   ------ PS +24V Ips=92.3mA

Reduce backlight from 100% to 0 %  = approx -13mA in both tested project.

Then downloaded code add approx 0.36W of consumption.

I love this! Nothing like experimental data.

Try again with small, but useful program compared with larger program.

[Ausman]

20 hours ago, Flex727 said:

Try again with small, but useful program compared with larger program.

I'd be intrigued to see if subs on and off make a difference.  Also the sort of thing I was talking about......my main reason is to always try to keep scan times to a minimum.

cheers, Aus

[Flex727]

On 5/10/2022 at 6:01 PM, Ausman said:

So I've slightly changed things.  The change did not get rid of SB2 but simply changed it to SB13.  Agreed you could leave it out completely if wanted, but I did it along the lines of my "save the plc doing unnecessary stuff" mentality.

Finally got a chance to look into this in detail. I am quite delighted with its simplicity and elegance. @Ausman, you are definitely one of the greats.

By the way, I deleted SB 13. Maybe I'm all wet, but it seems like some kind of aliasing could be possible causing it to lose a second here and there. Probably negligible anyway, but saw no need to save the PLC this little bit of work.

I also added a routine to "DoTheSDStuff" on first boot (first ever boot) because there would be no file created until the next Sunday even though data would be collected before then.

 

Thanks again, Aus.