New features wanted!! Apply here!

[plcnut]

I have had the identical issue as Controls Guy: when someone shuts the power off to the system overnight, then it never performs the reset.
One option is to

Code: [Select]

MOVE $Now.Date to d_DateOfShutdown in $tLastScan,

and then

Code: [Select]

$NOW.Date != d_dDateOfShutdown---------PerformWorkHere  in $tFirstScan.

[Controls Guy]

Here's what felt the cleanest to me:

Code: [Select]

STRNE $Now.Day V100
MEMCLEAR MHR40 10
MOVE $Now.Day V100
That covers both midnight and power up on a new day cases.

[Controls Guy]

Here's an example of a case where I'd like some formatting in MATH box expressions:

Code: [Select]

((Drum[V0] | IF(MHR7:0 & C201, RelayWDCfg0:SD, 0)) & IF(C103, -1, RelayPanicCfg0:SD) &
 IF(ST4, ~RelayFlashCfg0:SD, -1) & ~RelayTypeTOD0:SD) | (RelayTypeTOD0:SD & TODOutputs0:SD)
Actually doesn't look too bad on screen but hard to follow scrunched up in a little MATH edit box or at runtime.

[Controls Guy]

Few more feature requests:

(1a) Optional and adjustable fuzz factor for matching in COUNTIFEQ.

(1b) New COUNTIFLIM function that allows specification of upper and lower limit and returns the count of values falling between.

As you can see, (1a) and (1b) are somewhat interchangeable, but they excel in slightly different cases, so consider this a strong request for one or the other and a mild request for both.

(2) A SEARCHR or FINDR function that finds a value (presumably with selectable fuzz match factor), and returns the INDEX of the value in the table rather than the VALUE.  Could be used not just for finding foreknown values, but also for example finding the index of the MIN by doing FINDR(MINR()).

(3) BCD conversion functions that can be used in a MATH box.

[LWgreys]

Have a new idea. I was looking at one of my old C++ programs and thought "It would be something if there was a PLC that used C++ syntax for the programing". Just think of the power the programmer would have! Yes I do C++, PASCAL, BASIC and the dreaded Assembly language also.

[Controls Guy]

I think plans are to eventually support Structured Text, which in most platforms comes out kinda like a PLC-itized version of BASIC. (Also a cleaner more industry-standard implementation of SFC than Stage).

[Controls Guy]

Feature request:  My original request was going to be to allow indexed variables in a Data View (MyArray[V100] for example), which I would like.  Then that of course suggests the more general solution, which would be to allow expressions in general in a Data View.

[franji1]

Feature request:  My original request was going to be to allow indexed variables in a Data View (MyArray[V100] for example), which I would like.

That's already in there.

Then that of course suggests the more general solution, which would be to allow expressions in general in a Data View.

That may take a while.

[Controls Guy]

It is?   I thought I tried it today and DMD wouldn't allow it.   Have to check again tomorrow.

[franji1]

It is?   I thought I tried it today and DMD wouldn't allow it.   Have to check again tomorrow.

Rel 1.3 even supports offset arrays in Data View/Ladder status, e.g. R[V0+2].  See the attached screen shot.

[Controls Guy]

Very good to know - thank you!

Update:  Have been happily using indexed arrays in Data Views since I learned about the capability in this thread.  Very, very cool!  Manual?   What is this "manual" you speak of?   

[Controls Guy]

Feature idea (haven't given this adequate thought to really call it a "request"):

Each code-block has some yielding configuration, from never yield, to always yield, to time-slice.  It occurs to me that it would be helpful to be able to delineate a "no-yield zone" in the code, within which the program/task will not yield based on instruction type or time interval (concept obviously doesn't apply to code-blocks configured to never yield).  So new NOYIELD and NOYIELDE left rail instructions or something.

[Controls Guy]

Feature request:  functionally defined breakpoint in Debug mode.  IOW the breakpoint is "When N0 is changed to -1", and the last line executed is recorded.

[BobO]

Feature idea (haven't given this adequate thought to really call it a "request"):

Each code-block has some yielding configuration, from never yield, to always yield, to time-slice.  It occurs to me that it would be helpful to be able to delineate a "no-yield zone" in the code, within which the program/task will not yield based on instruction type or time interval (concept obviously doesn't apply to code-blocks configured to never yield).  So new NOYIELD and NOYIELDE left rail instructions or something.

You kind of don't need it, but can really already do it. First, the only instructions that actually yield are looping/goto that go backward...the time slice is only evaluated by 4 or 5 instructions. Second, you can change the .Timeslice member any time you want. So if you did have a loop that needed to not yield, it is a simple matter of setting the time slice to 65535 and restoring it at the end of the loop. It might be nice for documentation purposes to have an instruction like you described, but the implementation would be exactly what I described.

[BobO]

Feature request:  functionally defined breakpoint in Debug mode.  IOW the breakpoint is "When N0 is changed to -1", and the last line executed is recorded.

As long as it was a simple data compare, that wouldn't be that hard.