New features wanted!! Apply here!

[Controls Guy]

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.

Oh yeah, I forgot you could dynamically write to .TimeSlice members from ladder.  Perfect.  What I was thinking was that there might be some operations you wanted to protect, and having rung-level definition of non-yielding zones lets you loosen up the config for the code-block as a whole rather than having to make the whole thing no-yield.  Perfect solution.  Thanks!

[Controls Guy]

Feature request:  a conditional (right rail) version of YIELD.  Or can I already do that similarly to the previous case by manipulating .TimeSlice?

[franji1]

Feature request:  a conditional (right rail) version of YIELD.  Or can I already do that similarly to the previous case by manipulating .TimeSlice?

YIELD instruction is unconditional, and it ALWAYS yields, regardless of .TimeSlice.  Not sure of a better way to do a CONDITIONAL YIELD.  It would need to be a new instruction YIELDC.

[Controls Guy]

Right.  I was thinking not in terms of having a YIELD but of making .TimeSlice small and them doing something that would trigger a yield.  Or maybe using a conditional backwards GOTO or something (making sure to clear the jump condition).  Nevertheless, a YIELDC would be cleaner, so give some thought to whether you think it would be worthwhile.

[franji1]

Right.  I was thinking not in terms of having a YIELD but of making .TimeSlice small and them doing something that would trigger a yield.  Or maybe using a conditional backwards GOTO or something (making sure to clear the jump condition).  Nevertheless, a YIELDC would be cleaner, so give some thought to whether you think it would be worthwhile.

Those would work.

[BobO]

Being as we don't actually use PLCs for a living, we've been known to miss a thing or two. If there is a good application reason to add it, we are happy to do so.

[Controls Guy]

For me, it essentially comes down to the same issue that led to the previous post -- having fine grained control over where exactly in the ladder a given code block may yield.  One example case for this latest request would be within a loop.   Let's say I don't want to complete all the loop iterations without yielding.  I can't configure to Yield-at-every-yielding-instruction, nor put a explicit YIELD within the loop because then it will yield every iteration, which may be too much.

I may not want to use timed yielding because then the yield will occur at an unpredictable point in the loop logic.  So say if I want to yield after every 10 or hundred iterations, but only at the end of the loop, there's no clean way to do that now.

All three of the current options are quite valid and will see many cases in which they're perfect, but there are some odd cases where none of the three is exactly right, and a YIELDC would allow the user to precisely define yielding conditions.

I ran into a case where one program would push a number into a queue and another was scanning the queue for matching numbers and if it found one, it would act on it and clear that queue position.  The acting program would sometimes clear the queue slot prematurely when the packing program had barely had time to enter it, and then it was missing when really needed, and I couldn't seem to get it to interlock using MyOtherProgram.Running and so on.  I inserted my own flags for comms between the two and that seemed to take care of it, but it got me thinking along this line of fine-grained execution control and coordination.

[Controls Guy]

One way to do that now would be two nest two loops with the inside one iterating n times between yields, and the outer loop yielding on every iteration.  Less clean in general, plus making the index math more complex in the inside loop.  You see my point.

[plcnut]

A conditional YIELD would be wonderful. Very handy for troubleshooting as well.

[Controls Guy]

Feature request:  Indexable bit-of-word, as in MHR[V101+1]:[V102+2].  Might not ever need the fixed "+2" offset in the bit index, but included it for consistency with normal DM indexing.

Example:  I'm setting or clearing a single bit in a register addressed indirectly, so

Code: [Select]

MATH Mask (1<<RelayIdx)
MATH Drum[DrumIdx] Drum[DrumIdx] | Mask
to set, or

Code: [Select]

MATH Mask ~(1<<RelayIdx)
MATH Drum[DrumIdx] Drum[DrumIdx] & Mask
to clear.   This would be cleaner if in one rung I could unconditionally do:

Code: [Select]

MATH Drum[DrumIdx]:[RelayIdx] SetClearFlag   

[franji1]

Feature request:  Indexable bit-of-word, as in MHR[V101+1]:[V102+2].  Might not ever need the fixed "+2" offset in the bit index, but included it for consistency with normal DM indexing.

Just stick your mask into bit memory, and use CASTS for DWORD reference, otherwise you have complete control of bit level and mask level indirection.

Since you need to also look at your bits as DWORDs, you will need to start your mask on a 32-bit boundary, e.g. C0 or C32, etc.

When indexing the MASK as a DWORD, make sure your index is on a 32 bit boundary, e.g. V0 = 0, 32, 64, etc.:
C[V0]:SD

When indexing the MASK as a BIT, well, it's just the native bit offset:
C[V0]

Basically, whenever you need indirect addressing, make sure you make your base data-block's native data type be the resolution of your indirect addressing needs.  You can always use casts to look at the higher level resolution at a lower numeric resolution, making sure you start the array on BYTE, WORD or DWORD boundary.

Bits and DWORDS/REALs: Start on 0, 32, 64, 96, etc.
Bits and WORD: Start on 0, 16, 32, 48, etc.
Bits and BYTE: Start on 0, 8, 16, 24, etc.

BYTEs and DWORD/REAL: Start on 0, 4, 8, 12, etc.
BYTES and WORD: Start on 0, 2, 4, 6

WORDs and DWORD/REAL: Start on 0, 2, 4, 6, 8

[Controls Guy]

Right, I was aware of all of that, and if you use a native bit type, then you can index either the bit position OR the register location indirectly, but not both at the same time in the same expression.  One or the other must be literal.  What I can do with what you listed is roughly equivalent to the "before" version in my original post, unless I'm missing something.

[Controls Guy]

IOW what I'm saying is that I have a register which already must be addressed indirectly (Drum[DrumIdx]).  I want to address a bit indirectly within that register, and I don't believe there is any way to do so any more explicitly than what I posted.  Is that incorrect?

In other words, the mask word is only necessary at all because I can't simultaneously indirectly address a register and a bit within it.  (Plus the duplicate rungs decision whether to use OR or AND would go away too).

[franji1]

IOW what I'm saying is that I have a register which already must be addressed indirectly (Drum[DrumIdx]).  I want to address a bit indirectly within that register, and I don't believe there is any way to do so any more explicitly than what I posted.  Is that incorrect?

In other words, the mask word is only necessary at all because I can't simultaneously indirectly address a register and a bit within it.  (Plus the duplicate rungs decision whether to use OR or AND would go away too).

You are correct.  You cannot do two levels of indirection, i.e. an indirect cast and indirect block/array index.  Indirect casting, e.g. varying the bit cast or varying a byte cast or varying a word cast at runtime, is not supported.  But you CAN do what you are trying to do by just using a base block data type of bits, and then you CAN do what you are trying to do, indirectly access a DWORD and a BIT whenever you want (not just in logic, but also in a Data View or Ladder View!).

Just use a bit block, and you CAN get the same result as indirect cast AND indirect block/array index.

[Controls Guy]

Since it still by definition has to be at least as many separate steps as the current method, I'll call that a wash.  May consider using it on a new project before it's so committed to this method.

That was an idea I hadn't thought of, thanks!

Anyway, the bit-of-word indirection post started out as a feature request, and so it shall remain!