Binary Representation of Words in Memory View

[RBPLC]

Is there a technical reason why Words can't be viewed in their binary representation in Memory View? If not, I would like to request the ability to view/edit Words in their binary representation with each bit in its own cell.

[franji1]

Is there a technical reason why Words can't be viewed in their binary representation in Memory View? If not, I would like to request the ability to view/edit Words in their binary representation with each bit in its own cell.

If is truly binary memory, I recommend you create a block of bits instead of forcing words to be bits.  Then use casts to reference the bit memory as "numeric" - or even better - create a nickname for the cast that is well named
MyBits0:UW Flags0
MyBits16:UW Flags1 (or Flags16?)
MyBits32:UW Flags2 (or Flags32?)

Then use Flags0, Flags1, etc. when you need to see them as "words".  Arrays even work, e.g. MyBits[V0]:UW when V0 is 0..15, then it references that first "word"; when V0 is 16..31, it references the 2nd "word" of memory, etc.  Your array index calculations are a little different.  They are bit indexed instead of word indexed, but it sounds like that what they actually are anyway?

How are you actually using this "bit" memory?  Is it truly numeric (i.e. value 1234 means something, but you just like to think in binary), or is it truly bit memory?

The other benefit you get is that you can truly edit the "bits" when writing to the PLC from Memory View.

[Controls Guy]

Arrays even work, e.g. MyBits[V0]:UW when V0 is 0..15, then it references that first "word";

Cereal?  You can use a pointer not equal to a cast boundary?   I did not know that!   

[RBPLC]

I guess there are multiple things here:

1) This issue initially came up when trying to use RX and WX. To start with I was going to try to send bits back and forth but ran into the "bits are not byte aligned" limitation. I got aggravated with this (not particularly keen on trying to keep track of boundaries) and just decided to use Words as these can be sent one at a time. Why try to align something on a byte boundary when you can just use a Word that already does that?

2) This issue comes up when dealing with devices that use control words (think VFD's). These devices might have (say three) control Words with the first Word controlling start/stop and fwd/rev which is controlled by pairs of bits in the control Word. If you're sending a control Word, why not initially just think in terms of a Word as ultimately this will have to be sent as a Word to the device anyway.

3) It would be nice to cast pairs of bits or pairs of bits within a word. This way Start = CW1:0-1 = 10, Stop = CW1:0-1 = 01 etc. This would allow for the pair of bits to be named something meaningful.

4) Allowing Words to be viewed as Binary with the bits to be in individual cells allows easier testing/debugging (IMO) than trying to do this through the data window.

So, to answer the question, the need was for pairs of bits with the ability to send them through RX and WX which can't be done because those pairs don't lie on byte boundaries.

[BobO]

Arrays even work, e.g. MyBits[V0]:UW when V0 is 0..15, then it references that first "word";

Cereal?  You can use a pointer not equal to a cast boundary?   I did not know that!   

It kinda sorta works by lopping off the bits. It really isn't recommended though.

[franji1]

I guess you want to use Memory View as literal memory, not typed at all, not bound by bit/byte/word, i.e. it's all just bytes (or technically bits).  That is truly a "memory" editor.

You may, instead, want to look at the power of "unions" within UDTs (User Data Type, i.e. user defined structures).  You can lay out UDT members on top of the same memory area.  This is VERY common in C type "device" level programming, where a C structure has multiple union members that lays "on top of" memory.  Do-mores UDT mechanism has this capability.

For a quick example, look at the built-in type for date/time structure.  It has 2 DWORD fields, one called .Date and one called .Time.  These "members" actually just lay "on top of" the Year/Month/Day of the (.)Date, and DayOfWeek, Hour, Minute, Second lay on top of the (.)Time

I've attached 2 screen shots.  The first screen shot shows the Structure Member Field Details dialog of the DateTime structure.  Note the Layout column.  It shows the specific memory layout description, which DWORD it exists (since structures are always DWORD aligned), along with which bit, byte, or word within that DWORD (if it's not just a signed 32 or float).  Note how the .Date and .Time fields occupy the whole DWORD where the other "smaller" structure members exist.

The second screen shot is the Memory Layout dialog of the same structure - a visual representation of the memory layout.  Again, note how the .Date and .Time members occupy the same DWORD offsets as the other sub-Date and sub-Time members.

You can easily describe the "control structure" into a UDT, with bits being precisely layed out like they are in the source control device, but then laying a "byte" or "word" or "dword" member on top of those bits, being able to reference the same UDT members multiple ways (like $Now.Date and $Now.Time).

It's a buried feature, but it's there.  Very powerful.  MEMCOPY is what you would use to bring in raw bytes/words on top of a heap item or block element of the DriveCtrlStruct UDT (or whatever you call it).  You would need utilize a Data View, not a Memory View for editing.

[RBPLC]

I guess you want to use Memory View as literal memory, not typed at all, not bound by bit/byte/word, i.e. it's all just bytes (or technically bits).  That is truly a "memory" editor.

I guess what I'm actually asking for is ability to view memory as literal memory.