New features wanted!! Apply here!

[Controls Guy]

My thinking was either you get to set the time via a dialog somewhere, or it's non-configurable and runs at midnight for dailies, 12:00:00.001 Sunday morning for weeklies, 12:00:00.001 on the first for monthlies, etc.

Another thing I take into account when I do dailies is what happens if the PLC is off at the designated time (typically midnight).  It may be something you still want to run as soon as the PLC is up, so if it's one of those things, I track the date of last execution, and do the task on power up even if not at midnight.  So, how (or if) to handle that issue is something you'd have to decide.

[Garyhlucas]

I would like to see $daily, $weekly, $monthly functions with a selectable start time. I've had to do this for billing customers based on peak daily flows and monthly total flows.

[ADC Product Engineer]

It would be handy for pipelines and other utility services as well as for certain data logging applications.  I could have certainly used it at my last job which required EPA record keeping.

[franji1]

I would like to see $daily, $weekly, $monthly functions with a selectable start time. I've had to do this for billing customers based on peak daily flows and monthly total flows.

It's not that hard to do.

For daily:
STRE $Now.Hour == DesiredDailyHour
RUN DailyProg

For Weekly:
STRE $Now.DayOfWeek == DesiredWeekDay
ANDE $Now.Hour == DesiredWeeklyHour
RUN WeeklyProg

For Monthly:
STRE $Now.Day == DesiredDay
ANDE $Now.Hour == DesiredMonthlyHour
RUN MonthlyProg

Just make sure you stick EXIT instructions inside each of the Programs when they are done doing whatever it is they need to do.

The Desired* values can be a V location (for a configurable desired time), or a Symbolic Constant or just a constant (for a fixed time).

[Controls Guy]

True, but the existing system tasks aren't hard to write from scratch either.  The only advantages I see to systems tasks are two: that they do save you a LITTLE work, plus they  promote an organized program.  Same logic applies to all of these, pro or con, as to the existing system tasks.

[plcnut]

I can see both sides of this. But I prefer to write it myself if I need the functionality. I do like the idea of "code snipets" though. If there was a way to build an internal library for DMD that could store custom snipets as well as downloadable snipets of common tasks, this would keep the internals of DMD clean, but make it easy to get anything you wanted.

[BobO]

I think the best answer is to not do these things as built-ins, but to invest time in developing reuse mechanisms. Having a template or macro system would allow you to create your own reuseable objects to exactly your specifications. If those objects happened to show up in the project tree the same way as the system tasks, the two would be virtually indistinguishable in practice.

[Controls Guy]

Siemens calls that a "library", saving custom boxes for reuse.  You can protect them or not, as desired.

I agree that having that is more valuable than some specific new system tasks.

[ADC Product Engineer]

I dreamed of having a library back when I was actively developing code.  Shoot, I still dream of having one just to store code snippets to send to customers.   

[Controls Guy]

Or,  the entire library typically becomes one file, so just put the whole thing on the website and let people download it and browse the snippets.   They might find one they didn't even know they needed.  Just add functions to it when you come across good ones.   Or keep library files by types of functions.

[deep6ixed]

Or,  the entire library typically becomes one file, so just put the whole thing on the website and let people download it and browse the snippets.   They might find one they didn't even know they needed.  Just add functions to it when you come across good ones.   Or keep library files by types of functions.

I love the idea of having a code library file up for easy download.  They say that experience is the greatest teacher, but no one ever said it had to be personal experience.  I'd be happy to see how other people do things.

[franji1]

We've always planned to (eventually) support a code library.  But I also like the idea here of multiple libraries, where there is a local one, and then a COMMUNITY one that EVERYONE can access via the INTERNET.  That would be cool.

We are looking to add FUNCTIONs and SUBROUTINEs in a future release (think user defined MATH functions and user defined BOX INSTRUCTIONs, aka Function Blocks).  Functions and Subroutines would make the library concept even MORE POWERFUL.  We will do Functions and Subroutines before we implement Library functionality.

[Controls Guy]

What I'm picturing IS a library of custom functions and subroutines.  That's what Siemens' libraries are; just more groups of functions you can open like the native ones in the same spot you open the native ones, not a management tool for bulk code snippets.  That wouldn't be a absolutely terrible idea, but far, far less important than function block libraries.

[davidbgtx]

How about a "rung monitoring window" that you could copy rungs into (not necessarily sequential rungs, or even from the same task or program). Don't get me wrong data view is great, but it would be great to see the "status" of multiple rungs from different areas at once for troubleshooting.

[BobO]

How about a "rung monitoring window" that you could copy rungs into (not necessarily sequential rungs, or even from the same task or program). Don't get me wrong data view is great, but it would be great to see the "status" of multiple rungs from different areas at once for troubleshooting.

Good idea. These things may also be helpful:
1. Under the Window menu choose Cascade to put the ladder views into old-style MDI mode. This allows you to view multiple ladder views at once.
2. Dragging the little bar at the very top of a ladder view scroll bar will split each view into two panes, allowing you to view different areas of the same code block.
3. Right click on a rung and select Monitor Values, and there are options for automatically loading rung/instruction contents into a Data View.