setting zerobit in the PLC code

[rossw]

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

 
 
I *STRONGLY* disagree.
I have extensive use of counters with "DEC" and "SUB" that use the BNZ condition to terminate loops.
I again say, there are a series of well known, established instructions, that have been "stable" and "well understood" for many versions of the code.
YOU MUST NOT CHANGE THEIR BEHAVIOR EXCEPT FOR BUGFIXES.
If you wish to introduce a DIFFERENT behavior, introduce a NEW instruction to do so.
 
CAI - it is NOT ACCEPTABLE under ANY circumstances to change the way standard instructions work, but offer a "downgrade" to an earlier version of code as a "work-around". Please think about this in a professional manner.
 
If you need a final argument to convince you, just imagine the scenario - one of your PLCs being used to control machinery or equipment. *SOMETHING* happens and the board is damaged (or suspected to be damaged). Someone - quite likely not even the original user or manufacturer opens it up, sees your board. Finds it's only $50 and thinks this is by far the "easiest and cheapest" part to replace. Gets a new board, extracts the code from the existing board, loads it into the new board and turns it on. Due to the change in behavior of the instructions, the machine goes bonkers. Many thousands of dollars damage, or worse, SOMEONE IS INJURED. WHEN it goes to court and somoene demonstrates you failed in your "duty of care", who do you think is going to be in trouble?
(A court awarded a massive amount against a company because they changed the electrical configuration of a board but retained the same connectors - it was POSSIBLE to plug the new board in to the old equipment and injure people, the court determined that they SHOULD have changed the connector so such a mistake was not possible. What makes you think your situation is different??)

 

[az1324]

That is a lot of what if's and a user assuming that a non-matching revision code will work the same and applying user generated code to it. I don't think there is liability there.

I think the old way is just bad design from the start. If you are using counters then you just pass the counter to the branch instruction.

But if it must be preserved then I would suggest to add a second zero bit and then we can decide how that one is going to work differently.

 

[CAI_Support]

Hi Ross,
 
Thanks for your suggestions. Both parties that suggested to change and suggested not to change need to settle an agreement. We are not pushing for change or not change.  We did the change, simply because customers asked for it. We can change it back, because other customers want them back. Not a problem at all.
 
In the 3.02.17e, we did add "protected" keyword. If that keyword is in the line after "start", the PLC code will not display.  So that end user will have no chance to copy the PLC code and paste into another board.
 
I suggested to provide a downgrade firmware does not mean we want to keep the way forever. Rather is before the dust is settled, we provide an interim solutions for customers.  Once your guys decided what we should do, we will incorporate that decision into a new firmware. We are easy and flexible.
 
I started this thread just for prompting user awareness. I think it is better to let people know and let us know what everyone thinks than any bad surprises on user end (as you described case).   I hope this thread not promote unhappiness rather suggestions to make it better.
 
I hear you want to keep original behavior on all operators. 

 

[bgriffith]

I just used ADD as an example.  Perhaps one of the others would have been a better choice for that. 
I assume ADD -3 3 would set the zero bit though.
 
I happen to have an Intel i486 reference manual here so I looked up which instructions set the zero bit. 
The ones which are comparable to PLC instructions and update the zero bit are ADD, AND, DEC, INC, OR, ROL, ROR, SUB, TEST, XOR.
DIV, MUL have undefined effect on zero bit.  There are no i486 instructions comparable to MOD, SIND, COSD or TAND. 
 
The trig functions, according to the manual, did not update the zero bit.  If in fact they did update it that would be an undocumented feature that ideally nobody should be relying upon, so removing it might not present an issue.  The others all did (and still do!) have updating the zero bit as a documented behavior though.
 
Regarding the new PROTECTED keyword, that won't help someone who has older boards and is upgrading to newer boards, which is the issue here.

 

[rossw]

Hi Ross,
 
Thanks for your suggestions. Both parties that suggested to change and suggested not to change need to settle an agreement. We are not pushing for change or not change.  We did the change, simply because customers asked for it. We can change it back, because other customers want them back. Not a problem at all.
 
In the 3.02.17e, we did add "protected" keyword. If that keyword is in the line after "start", the PLC code will not display.  So that end user will have no chance to copy the PLC code and paste into another board.
 
I suggested to provide a downgrade firmware does not mean we want to keep the way forever. Rather is before the dust is settled, we provide an interim solutions for customers.  Once your guys decided what we should do, we will incorporate that decision into a new firmware. We are easy and flexible.
 
I started this thread just for prompting user awareness. I think it is better to let people know and let us know what everyone thinks than any bad surprises on user end (as you described case).   I hope this thread not promote unhappiness rather suggestions to make it better.
 
I hear you want to keep original behavior on all operators. 

 
Fine on all counts. I don't have any animosity over this issue, but as someone who has worked in the field of industrial electronics for over 35 years, I have experienced the problems changes as those being proposed cause. Not immediately. But sooner or later. They may seem trivial and insignificant now, but I urge you to stop thinking like a backyard tinkerer and start thinking like a professional organization. Once you have a published feature set and have code actually deployed in the real world, you MUST NOT break it by making it operate differently. It's different if it's a bugfix. But this isn't. Even by its very definition - someone writing new code NOW to have the code changed to make their (flawed) code work properly is wrong. If there is a need to have instructions that operate differently to what every other platform does, introduce NEW commands with the abberant different behavior and let the NEW code use the NEW instructions that operate in a NEW AND DIFFERENT WAY. Maintain COMPATIBILITY with running code. To contemplate otherwise is a REALLY bad decision both technically and to your reputation.

 

[az1324]

So the proposal is to return the function of zero bit to the original implementation.  Basically that means every operator will update it, including SET. 
 
I then also propose that a new variable be created which is a boolean result variable.  Then the output of any command can be assigned to this variable and it is converted internally to a boolean. 
 
This way it is possible for the user to manage a zero bit on his own.  Really, this is only necessary when a user runs low on RAM since a 32-bit value could be used otherwise.
 
I also recommend freezing changes to the standard firmware and making it the only shipping version and then create experimental branches where things can be played around with and users are instructed to install at their own risk.

 

[CAI_Support]

Thanks, AZ1324 for your suggestion.  Could you please elaborate more in details about that variable, how should that work?
We value any suggestions from all customers.  Sometimes there are conflict requirements, then we want to hear all sides to get things working out for everyone.
 
We can easily change the zerobit operating the original way, so that all operators will affect zerobit. User will understand the zerobit is from the result of last operation, does not matter what that was.  Once we have this changed back and your suggested new variable implemented, we will make another version for future formal release.

 

[CAI_Support]

We have 3.02.17f pre-release firmware for customers to try. If your board has bootloader and you are interested in testing this one out, please send us private message.  In this version we restored the zerobit handling to the same as 3.02.17d and earlier.  In addition, we make RAM1 can be accessed by bit, as RAM1B1 to RAM1B32.  Although we already have TSTB, SETB, GETB, CLRB operators to work on any variable in the 3.02.17e, we added this per AZ1324's request.  Data type zbit is still connected to the zerobit's value and is read only.
 
As AZ1324 suggested, we intend to make this to be frozen version, if there is no bug reported.

 

[TJF1960]

Great to hear and thank you for the update. I will send you a pm.
Question, in the .17e manual the ALLINS and ALLOUTS function, is that only available on rev .17a as the manual suggests or is it available from .17a forward? If it is .17a and forward can you describe the proper way to use them please?
 
Thanks,
Tim

 

[CAI_Support]

ALLINS and ALLOUTS are available on all .17a forward firmware versions.  You can treat them like VAR or RAM, except for ALLINS, you can not change it, so do not assign any value to it.

 

[TJF1960]

Very nice, Thank you!