Suggestion to RAM and VAR Change

[CAI_Support]

We seek input from users for making changes to RAM and VAR in our PLC firmware. 
Currently all RAM and VAR are signed 32bit numbers.  We plan to change some of them to unsigned 32 bit numbers, in that way, for some calculation requiring unsigned 32bit number, it would not treat top bit as sign bit.
 
Should we change them so that half of them are signed and half of them are unsigned, do you have any suggestion?
 

 

[rossw]

We seek input from users for making changes to RAM and VAR in our PLC firmware. 
Currently all RAM and VAR are signed 32bit numbers.  We plan to change some of them to unsigned 32 bit numbers, in that way, for some calculation requiring unsigned 32bit number, it would not treat top bit as sign bit.
 
Should we change them so that half of them are signed and half of them are unsigned, do you have any suggestion?

 
It is rare that numbers I typically handle are over 2^31 and more common that I want signed numbers.
In the situation we've been talking about in private, the numbers in question are all 16-bit signed or unsigned. Changing the WC behavior wouldn't fix this problem anyway, because to a signed 32-bit register, even "-1" (signed 16-bit) is only a small (positive) number.
 
I think the number of times an unsigned-32-bit register will prove "more useful" than an unsigned will be very few. You likely don't have enough spare bits, but a configuration bit for each to be signed or unsigned might be less problematic, that or introduce a couple of extra commands... there's really no such thing as a "signed 32-bit register", it's how the instructions use it - so equivalent "unsigned" commands (uadd, umul, udiv, usub) might make more sense?

 

[CAI_Support]

Okay, Ross.  Thanks for your input.  We will not make such change, then.  That will be easy for us.  For access 16bit of the 32bit number, we are using signed 16 bit internally for calculation, but stored as unsigned 16 bit, so that to be part of the 32bit signed number.  I want to make sure every details are discussed, so that we will not have problem during calculation.  Do you want any of those 16 bit access to be unsigned during calculation?
 
To be more clear, when PLC read a byte or 16bit number, like RAM10, or RAM1L, we will read that as unsigned byte or 16 bit and cast into 32bit signed number, all the calculations are in 32 bit signed number, then store the result back into original space by casting into signed 8 bit or signed 16bit into that section of RAM.  Should we cast the result into unsigned byte or 16bit number then store them? 

 

[az1324]

reading it as unsigned and writing it back as signed?  that doesn't sound right.

 

[CAI_Support]

Because its calculation in 32bit register as signed. If we don't cast as signed, it may not get sign bit in correctly, because sign bit is the 31st bit counting from 0th.
 
This basically is when access a 32bit numbers in bitwise, byte-wise, two-byte, or whole four bytes, 4 different ways.  We did testing when we first implemented and all working. But we do want to bring attention to everyone, when do calculations, if there is a better way to access those RAM space, please give us your opinion.
 
The reason we brought up this discussion is for some sensor, like BMP180, requiring calculation based on calibration data.  During calculation, many results need to be stored.  To use two bytes will double the number of storage. We want to make sure if access RAM in portion of it, the result is still correct.

 

[rossw]

You raise some valid points. Because I haven't had (until now!) the latest firmware, with RAMxH and RAMxL, I've been stuck in the "32-bit-register" mindset.
Of course, if we use H and L it DOES become an option!

So that brings me to two questions.  Since we can't "view" RAM values from the status page, (I haven't checked recently, but the status didn't return RAM values either - does it now?) - would it be possible to add the H/L and 0/1/2/3 access for VARs?
 
For signed/unsigned use, how about assuming the registers are all signed (as they are now, which preserves backwards compatibility), but introduce another prefix for "UNSIGNED" use? Eg,   RAM1 (RAM1L, RAM10) are all SIGNED values. (32, 16 and 8 bits respectively), but referring to them as  URAM1, URAM1L and URAM10 would cast them as unsigned?
 
Thus   
 
    MUL URAM1 RAM2 RAM3    would multiply (unsigned) RAM1 by (signed) RAM2 and store the result as a signed 32-bit answer in RAM3  ??

 

[az1324]

32 bit values always signed sounds fine
16 bit values always signed can probably live with that
8 bit values would prefer to be always unsigned or user choice (RAM10 or RAM10U, putting the U in front confuses with UROM)

 

[rossw]

32 bit values always signed sounds fine
16 bit values always signed can probably live with that
8 bit values would prefer to be always unsigned or user choice (RAM10 or RAM10U, putting the U in front confuses with UROM)

 
Don't agree with the 16-bit. If we're going to permit signed/unsigned 8 bit, we should do 16.  Can live with signed 32, but again - for consistency, why wouldn't we?
 
As for "putting the U in front confuses with UROM" - I disagree.... RAM, VAR and ROM are all quite different and serve different functions. Personally, I don't mind if the signed/unsigned flag is before or after - those of us used to C coding are already familiar with explicit casts    (unsigned)RAM1 for example, and I thought URAM1 just reads in my mind like that

 

[CAI_Support]

Maybe we can do this, the 16bit high portion is signed, 16bit lower portion is unsigned?
Ross, those boards we sent to you a month ago with bootloader already have these in it.  The feature that RAM access can be bitwise, byte-wire, double-byte-wise, and 32bit are in the firmware for a long time.  I think AZ1324's firmware has them in it, too.
 
You can set RAM1L RAM1H or RAM10 to VAR and see what the value is on web browser.  Then if you think anything not right, please let me know, we can change them to the way you guys like.

 

[Efried]

We seek input from users for making changes to RAM and VAR in our PLC firmware. 
Currently all RAM and VAR are signed 32bit numbers.  We plan to change some of them to unsigned 32 bit numbers, in that way, for some calculation requiring unsigned 32bit number, it would not treat top bit as sign bit.
 
Should we change them so that half of them are signed and half of them are unsigned, do you have any suggestion?

 
could make sense- I would opt for a user selection, where he/she enters name and type of the variable...

 

[CAI_Support]

Efried,  thanks for your input.  What most do you use, bitwise, bytewise, two-byte, or whole 32 bit?  What restriction or problem have you encountered when using them?  We want to improve the way access them in different part of RAMs, any real case would be helpful for our engineers to understand.

 

[Efried]

thanks, my biggest problem is lack of variables and naming. A lot of them are bits or bytes,  so may be you could introduce subdivision of variables,  like VAR1A for lower bits an VAR1B for upper.  Just my idea

Efried,  thanks for your input.  What most do you use, bitwise, bytewise, two-byte, or whole 32 bit?  What restriction or problem have you encountered when using them?  We want to improve the way access them in different part of RAMs, any real case would be helpful for our engineers to understand.

 

[CAI_Support]

Hi Efried,
 
There are already have RAMxH and RAMxL on all RAMs, what is the reason for have VAR to duplicate what RAM already do?  We designed with VAR and RAM, which VAR has special function that delaying reading value, if user so specified in PLC.  RAM is for calculating, so that no such delay feature.  There is no need to have all RAMs and VARs to be accessed in portion. 
 
In addition, VAR's delay function can not be accessed by anything other than 32 bit.

 

[Efried]

Hi Efried,
 
There are already have RAMxH and RAMxL on all RAMs, what is the reason for have VAR to duplicate what RAM already do?  We designed with VAR and RAM, which VAR has special function that delaying reading value, if user so specified in PLC.  RAM is for calculating, so that no such delay feature.  There is no need to have all RAMs and VARs to be accessed in portion. 
 
In addition, VAR's delay function can not be accessed by anything other than 32 bit.

 
ok I understand.But I'm using VARs first, because of their visibility, and this is especially useful for status variables. So only very few are 32 bit. For me the possibility having a list of status VARs having names would be helpful.

 

[CAI_Support]

If you are using VAR as status, it makes more sense NOT have VAR accessed in different way for calculation storing temporary values.  You can always SET VARx to show finished calculation result. 
 
AS I said,. VAR has special function that only work in 32bit.  It is different than RAM.  So please use RAM for your calculation, and VAR for displaying result.