setting zerobit in the PLC code

[CAI_Support]

We made certain changes in the PLC logic in 3.02.17e firmware, only the operators in the following list set zerobit:
 
TSTEQ
TSTLT
TSTGT
TSTNE
TSTGE
TSTLE
ANDT
ORT
XORT
ANDBT
ORBT
XORBT
TSTB
 
If your program was depending on other operator to set zerobit, please be aware this change.

 

[TJF1960]

Thanks for the update. So if I have 1 board running 3.02.17d  and one board running 3.02.17e and both are using:
 
ANDB RAM1 512
CZ LOAD
 
Are you saying that board with .17d will update the zero bit and will CZ if 0, whereas board with .17e will not CZ?
In order to correct in .17e do I just change it to:
 
ANDBT RAM1 512
CZ LOAD
 
Thanks,
Tim

 

[CAI_Support]

You are correct, AND and ANDB, as well as OR and ORB no longer set zero bit in 3.02.17e firmware.  ANDBT is a good choice for that purpose.

 

[TJF1960]

Ok, Thank you! I will make the changes.
 
Also just to let you know that the .17e owners manual still lists ANDB etc as updating the zero bit. That is where my confus

 

[rossw]

If your program was depending on other operator to set zerobit, please be aware this change.

 
While it doesn't affect me (yet) I'd just like to say that unilateral changes to the engine that renders old, working code inoperative, is a really bad thing, and (in my view) the correct answer would be to introduce the modified behavior in the new commands.
 
(Different if the original commands were not working per the specification, in which case it would be a bug-fix - but a deliberate change in operation of existing and well understood commands is IMHO a very bad design decision)

 

[CAI_Support]

Thanks for your suggestion.  One of our really good customers think we should not let certain operator to change the zero bit, when those operation could result in zero or non-zero, but not for intended setting zero bit purpose. We think that suggestion made sense. For example, you had a test for certain condition, then in the process, you did an addition for two numbers, which wiped out the zerobit state in previous checking.  But the condition that caused zerobit set did not change or recheck.
 
Based on that suggestion and a list of operators that should set zero bit, we made such change in the 3.02.17e release and documented in the user guide.  If you have suggestion that other operator should be included in the setting zerobit list, we can discuss and make change.  With the bootloader implemented, it is easy to get new firmware updated, if so desired.

 

[rossw]

Thanks for your suggestion.  One of our really good customers think we should not let certain operator to change the zero bit, when those operation could result in zero or non-zero, but not for intended setting zero bit purpose. We think that suggestion made sense. For example, you had a test for certain condition, then in the process, you did an addition for two numbers, which wiped out the zerobit state in previous checking.  But the condition that caused zerobit set did not change or recheck.
 
Based on that suggestion and a list of operators that should set zero bit, we made such change in the 3.02.17e release and documented in the user guide.  If you have suggestion that other operator should be included in the setting zerobit list, we can discuss and make change.  With the bootloader implemented, it is easy to get new firmware updated, if so desired.

 
I'm not arguing the merit of setting or not setting the zerobit.
 
I'm arguing the change in established behavior (which is not abberant, and is per the published documentation at the time).
There will be a lot of code out there (I have a lot of lines of code in a bunch of devices "out there" - much of which does specifically use the zerobit test - that code will need audited and changed (some of it is over a year old) - in order for it to be deployed in a "like for like change" of hardware!
 
True, there is an argument that the later code has many additional features and the code could be made more efficient using them - but that's not the point.
EXISTING CODE on an older board will FAIL TO WORK - and may fail in non-obvious ways - POTENTIALLY in ways that could injure people or damage equipment.
 
Someone who has an existing board, wishes for (whatever reason) to replace it with another of the same type from the same manufacturer with exactly the same external appearance will undo the screws, swap boards, re-do the screws, drop the same code in it and REASONABLY expect it to work the same, without having to sit and read all the fine print in the manual (which they won't!)
 
If the original operation was inconsistent or WRONG, then this would be a bugfix and I have no problem with it.
But completely changing the operation of the same instruction is (in my mind) a really bad move. The changed behavior SHOULD have been on the NEW instruction, not the original one, as that would maintain backwards code compatability.

 

[az1324]

They can release the older firmware version as an "update" so you can roll back all new boards with the bootloader and not have to change any code. Maybe put a warning label or insert with the boards, on the product page, on the PLC web entry itself, etc...

To deny progress because of a presumed lack of awareness would be worse.

 

[rossw]

To deny progress because of a presumed lack of awareness would be worse.

 
I'm not trying to deny progress.
I'm trying to promote "best practice" of maintaining backwards compatability.
By all means, introduce new functions. I'm 100% in support of that. But if there is a change in BEHAVIOR then it should be the newly introduced command/function that has the different behavior.
 
It would be like changing the function of "div" to add, and adding a new function called "diva" that does the original operation.
"upgrade" to an earlier version of the code is stupid. Surely bugfixes etc in later code makes the later code beneficial.
Apart from which, expecting people to somehow "know" that their brand new board won't work as the docs for every previous version did, and that they have to (a) change their code or (b) downgrade to an old version (will they even be available?) is idiotic and counterintuitive.
 
The only LOGICAL thing, from a best-practice point of view is to retain the existing behavior for the existing instructions, and add the DIFFERENT behavior to the NEW commands.

 

[bgriffith]

I strongly agree with Ross; an update should not break existing working code.  I've only started playing around with this board, and in fact I just got mine back yesterday from being updated to 3.2.17e.  I have a ~250 line program that I loaded up for the first time last night, and it relies pretty heavily on the zero bit being set as described in the documentation.  (As pointed out above, it is still described that way in the latest manual.)  Now that I've read this thread this morning I know what is to blame for probably most of my issues. 
 
 
From the 3.02.17e user's guide

ANDT a[] b[] (d[])
Logical AND's a with b and optionally puts Boolean result into d. Zero bit updated. Skip next line if zero.
 
 
So does this mean that where I might have previously done:

ANDB VAR1 0x00800000
BZ loop

I should now change the first operator to ANDBT and either keep the BZ or (to make it more clear) change it to a GOTO?
 
 
What if I had previously done "BNZ loop"?  Am I correct in thinking the following would not work because the BNZ line would be skipped?

ANDBT VAR1 0x00800000
BNZ loop

 
 
 
It's not a big deal for me, a hobby user, to go in and change a program that I've only just run for the first time, and is still quite fresh in my head, but I can see this being a major hassle for someone who has a lot of these deployed and wants to expand their operations and add more.
 
Thanks,
Ben

 

[CAI_Support]

We do have 3.02.17d version that has bootloader allowing upgrade easily to later version. That version is being tested by many users as bug free version, too.
For running any firmware that needs backward compatible, Let us know, we can ship board with that version firmware.  If anyone has the need to downgrade from 3.02.17e to 3.02.17d, please contact us to get downgrade images.
 
We bring up this significant change to discussion, because we want to make sure this is acceptable to everyone. If not, how to change it will be good for the best.
When people approached us saying "I am in a subroutine doing ANDB VAR1 0xABC VAR2, I don't want the zerobit being wiped out by this operation". I think he has a point.  However, if someone does want to change the zerobit by above operation, we come up a compromise to added ANDBT.
 
Maybe the better way is to keep AND, OR, XOR, ANDB, ORB, XORB the same way like before, introduce another set of commands that do not change the zerobit.   It  may be too verbose, if we say instead of ANDBT, we change to ANDBNT, etc?
 
But not all operators will set zerobit, would that be something acceptable?  If so, please contribute your suggestion on which one should and which one should not set zerobit?

 

[TJF1960]

For what its worth I feel the same as rossw and bgriffith. What happens if tomorrow you add a feature I would really like to have but I don't what to re-write my entire code because of the zerobit operator change? Or tomorrow you discover a bug for which you fix in xx.17f. I think leaving it as it was and making the addition of ANDBT or ANDBNT not update zerobit would have been the way to go.
 
Thanks,
Tim

 

[az1324]

I think that is ok if the following are restored to original behavior:

ANDB
ORB
XORB
AND
OR
XOR

Then add the following new versions that do not set zero bit

ANDBNT
ORBNT
XORBNT
ANDNT
ORTNT
XORNT

But I don't think the following should set the zero bit, whether or not they did before:

SET
ADD
SUB
MUL
DIV
INC
DEC

 

[bgriffith]

The new "T" instructions, in addition to updating the zero bit also act like the TST instructions in that they skip the next line if the zero bit is set.  What if the old instructions retained the updating of the zero bit, and the new ones did not touch the zero bit but still act like TST instructions (skipping next line if result is 0)?  If you don't want the zero bit updated but you also don't want to skip the next line you just use a NOP.  And more importantly, if you have code that works in 3.02.17d or earlier you don't have to re-write it. 
For that matter, with the new optional parameter for the branch and call instructions, why do we even need the new "T" instructions to act like TST instructions?
 
That wouldn't help in the arithmetic instructions which now apparently no longer update the zero bit either but have no new counterparts which do.
 
Speaking of optional parameters, could the updating of the zero bit be disabled by using an optional parameter?  Something like:
ADD a[] b[] d[] (NZ)
If you include NZ at the end of the line then the zero bit will be untouched.  Would that be difficult to implement?  It seems like that has the potential to make everyone happy. 
 
If adding a fourth parameter isn't a simple matter it could just be implemented as separate instructions but documented like this:
ADD(NZ) a[] b[] d[]
 
So ADD would work as it always has and ADDNZ would not update the zero bit.   ORB-ORBNZ, AND-ANDNZ, MUL-MULNZ, etc.

 

[CAI_Support]

I think we will restore the AND, OR, XOR, ANDB, ORB, XORB with original behavior, adding other command doing same function but not change zerobit.
 
ADD will never set zerobit to true, unless you ADD 0 0.
The question is should ADD/SUB/DIV/MUL/MOD/DEC/INC/SIND/COSD/TAND/ROTL/ROTR set zerobit?
In previous version, all operators set zerobit.  That may not be the correct behavior.