Dumb question on PLC program operation.

I'm looking at the 3.2.13 manual and it has this example on page 26:

checkOP3:
AND AIP1 AIP3 RAM1
TSTGT RAM1 1024
BNZ l1
TSTEQ IP4 1
BNZ l2
RET

Is the AND a misprint? It should be add? Anding these 2 will only yield a 0 or a 1 in Ram1?

This one should be:

ADD AIP1 AIP2 RAM1
TSTGT RAM1 1024
BNZ l1
TSTEQ IP4 1
BNZ l2
RET

There wre two typos in it, one was ADD typed as AND, and AIP2 typed as AIP3.

Thanks for pointing out!
 
I'm looking at the 3.2.13 manual and it has this example on page 26:

checkOP3:
AND AIP1 AIP3 RAM1
TSTGT RAM1 1024
BNZ l1
TSTEQ IP4 1
BNZ l2
RET

Is the AND a misprint? It should be add? Anding these 2 will only yield a 0 or a 1 in Ram1?
So the example from the manual is incorrect as I have pointed out?
I'd love to see the *B .

How soon can I send mine back for the new version with the ANDB, ORB, and XORB with 2000 lines of code realhug.gif
 
Should we consider adding bitwise AND? What would be best short name for bitwise AND? ANDB = Bitwise AND?

I asked for this several times, you guys shot me down in flames and said basically I was stupid for asking for it!
You need to listen to your users. Implementing instructions that are singularly USELESS and telling us we're stupid when we suggest something to make them actually USEFUL just alienates us and makes us look at alternative products with less irritating developers.
 
Ross,

Thanks for pointing out our problem. Surely we can make the change to add ANDB, ORB, XORB three commands.
We do appreciate your input very much!

CAI Support
 
There are very few companies that are willing to support their product in a forum and do it for free. They may have realized that more than 1 person has asked for it so maybe it does have some merit. As a side note, I see no other posts that clearly suggest the ANDB function.
Lets give them a break and thank them for their time instead of dragging them through the mud. I'm very impressed and thankful for their communication. I have an Allen Bradley PLC that costs several thousand dollars. It doesn't have analog or network. Those options are $1000's more. The software to program it is just as expensive. If I want to talk to anyone at the company, I need to purchase an expensive contract to do so. For the paltry $40 we paid for this board and the great support we get here, how can we justify bashing CAI?
I just bought another board today and will probably buy many more in the future for other projects.
Thank you CAI and keep up the good work.
 
They may have realized that more than 1 person has asked for it.....
I see no other posts that clearly suggest the ANDB function.

My discussion was via direct email, not in the forum. Perhaps that was my problem - nobody else saw my thoughts, so it was seen as "just one person asking".

Soooo.... one of my other suggestions was that sure, we have 32-bit registers, but FREQUENTLY I'd like to have more registers of smaller size.
Eg, various counters - often don't need to count beyond a hundred, so byte-wide counters would be fine.
Let me cut and paste from my email a couple of months ago:

Next, the board has 16, 32-bit registers we can use (ram1-8, var1-8)
This frequently isn't enough. Often I'd like more, lower-resolution variables. Is it possible or practical to "trade off"?

For example, the same actual 32-bits of storage known as "ram1" might be known as word1 and word2, or byte1, byte2, byte3 and
byte4.

set ram1 12345678 (hex BC614E)
or (word1 = 188, word2=24910)
or (byte1 = 0, byte2 = 188, byte3 = 97, byte4 = 78)

This would let us have (and use) a far more versatile range of variables with no more hardware resources.


To clarify, I'm not asking for MORE memory. I'm just asking to make the variables the C-equivalent of UNIONS
I currently "make do" using a complex, slow and obscure copy register, divide by (x), multiply by (x), subtract from copy - which works, but heck, it's a lot of work if we could just refer directly to the byte or word directly!

As for the bitwise commands, again, in my email I asked:

Finally, how about some BITWISE operators. AND/OR/XOR. You have logical, but they don't help much.

I have currently no way to "mask" a word. If I want to see if (for example) VAR1 has bit 2 set:
AND VAR1 4 does NOT give me the answer I want. It is true whenever VAR1 is not zero.

Logical tests are ok, but bitwise tests are of great value to us.
 
I have a beta with the bitwise functions. PM and I'll give you a link, username, and pwd and a few hours to try it. You get 2 temp sensors and that's all thats hooked up to it. You still can't directly address the bits but you can use ANDB, ORB, XORB with a mask.
 
How do you think directly address bit would be a good way to access it?

I frequently have code that needs to store flags. Have I reached end-of-travel? What direction did I last move? Am I in a "safe area"?
Most of the time, these conditions are not mutually exclusive so storing a single value does not help.
Bitwise AND is sufficient to do my job though, don't get too hung up on "single bit" access.
Unions so we can directly access two words, or 4 bytes - for a single 32-bit register would be FAR more useful.
 
I frequently have code that needs to store flags. Have I reached end-of-travel? What direction did I last move? Am I in a "safe area"?
Most of the time, these conditions are not mutually exclusive so storing a single value does not help.
Bitwise AND is sufficient to do my job though, don't get too hung up on "single bit" access.
Unions so we can directly access two words, or 4 bytes - for a single 32-bit register would be FAR more useful.
I agree. I just wanted the ability to assign bits to certain funtions. The ANDB is sufficient for this.
 
XORB would be useful for just turn on or off 1 bit.
Microchip C compiler for this chip does not support 64 bit operation.
Besides, VAR and RAM are actually signed 32 bit integers.
 
Microchip C compiler for this chip does not support 64 bit operation.
Besides, VAR and RAM are actually signed 32 bit integers.

I don't think anyone queried or disputed that? I know *I* said they were 32-bit registers.
And if it's a C compiler, surely it would be trivial to make the storage actually unions? And if they were unions, additional reference codes "word" and/or "byte" wouldn't be hard to do, and contextually consistent?

Code:
VARB1 (Upper 8 bits)   VARW1 (upper 16 bits) VAR1 (32 bits)
VARB2 (bits 17-24)
VARB3 (bits 9-16)	 VARW2 (lower 16 bits)
VARB4 (lower 8 bits)
 
XORB would be useful for just turn on or off 1 bit.
If I use XORB, how would I definatively turn off the bit if I am unsure of it's current state? I would have to create another step to test before I use the XORB wouldn't I? If I am using it as a safety then XOR would toggle the bit and might actually create the reverse of what I wanted?
 
I don't think anyone queried or disputed that? I know *I* said they were 32-bit registers.
And if it's a C compiler, surely it would be trivial to make the storage actually unions? And if they were unions, additional reference codes "word" and/or "byte" wouldn't be hard to do, and contextually consistent?

Code:
VARB1 (Upper 8 bits) VARW1 (upper 16 bits) VAR1 (32 bits)
VARB2 (bits 17-24)
VARB3 (bits 9-16)	 VARW2 (lower 16 bits)
VARB4 (lower 8 bits)

It is not easy or hard for C compiler to do. To the user, it is how easy to be present in PLC logic and how much trouble can be reduced for users.
I am trying to understand what you try to accomplish that new method you proposed would help. Sorry for being slow.
 
If I use XORB, how would I definatively turn off the bit if I am unsure of it's current state? I would have to create another step to test before I use the XORB wouldn't I? If I am using it as a safety then XOR would toggle the bit and might actually create the reverse of what I wanted?
Yes, you can use ANDB to check if certain flag position is set, then use XORB to toggle that bit.
 
Back
Top