I do not understand intended behavior

[milldrone]

The copy and paste function seems to give "unwanted" results under certain conditions.

1. Copy a rung that has permissives before an out, say X0---------------OUT C1

2. Create a stage that has     ------------------------OUT Y0 as the first rung in the stage.

3. Place the cursor on the  --------------OUT Y0 rung (anywhere along it's length), paste and it merges the content of both rungs.

4. The new rung is now  X0----------------OUT C1
                                            l---OUT Y0   


If I do the paste anywhere other than the first rung in a stage with an unconditional out, I get two separate rungs. This is the behavior I was expecting.

[milldrone]

Never mind I figured it out

thanks

[BobO]

Side effect of a stack-based contact implementation. We've actually talked about adding a warning when code is pasted that will result in rungs being merged. Might be good to revisit that.

[milldrone]

Here is an interesting behavior I just discovered

As I'm creating a rung I used the browse (magnifying glass) to give a timer a nickname SequentialTimer Then as I'm further along I use that timer's address (T0) in a contact, no problem and it names the contact SequentialTimer.Done later on I'm using the browser to select a timer contact (It does not matter which done, timing, Zero, reset) and I get an error too many characters! But I can type in T0.reset (I then get SequentialTimer.Reset) without using the browser and it works!

[BobO]

Yeah...I see what's happening. The element browser is showing the valid (implied) nickname for the field 'SequentialTimer.Done', and is then doing a normal nickname validation on the full text...which is over 16 characters. That is a side-effect of us trying to do too dang much with the element browser...showing ranges, listing nicknames, selecting elements, as well as documenting...

That is a bug.

Thanks for pointing it out.

[BobO]

Since we added auto-complete, I honestly don't use the element browser very much any more...which is probably how this one sneaked by us. We obviously need to spend a bit more time in it.

[milldrone]

I'm looking for an instruction that I can use an indexed bit of word and write to an indexed bit. The MOVEBIT will let me write to an indexed bit, from an indexed bit (not documented by the way) but I cannot get the value from an indexed bit of word.

[BobO]

Indexed bit of word...as in N[V0]:0? Not at a computer to check. Will MOVER not do it?

[milldrone]

Indexed bit of word...as in N[V0]:0?

More like N0:[V0], I think. If I have my syntax correct

[BobO]

That's not valid.

[milldrone]

Ok, I'll look for another way

[BobO]

Move it to bit memory and index the bit memory.

[franji1]

If you start off with the data in a bit memory data block (e.g. C), you can array index at the bit level.  THEN use casting to give you BYTE, WORD, DWORD sized elements (formats too).  Note, however, that the bit address casts to BYTE must be BYTE aligned (e.g. C0:UB, C8:UB, C16:UB), casts to WORD must be WORD aligned (C0:UW, C16:UW, C32:UW), casts to DWORD must be DWORD aligned (C0:SD, C32:SD, C64:SD).  Note that you can even do C[V10]:UW and V10 index value will be "aligned" (e.g. 0..15 resolve to 0, 16..31 resolve to 16, 32..47 resolve to 32) for WORD alignment (BYTE and DWORD casts with V array index "align" the index values accordingly).