recently we are adding some new screens in existing project of the HMI. we want to have pump on/off controls from HMI. we have 20 pumps and I want to make a common program
Ignition is linked with KEP and S7-400 PLC
from the PLC I assign one word each for one pump (so total 20 words)
Each bit of the word will carry signals. For ex - bit 0 is pump select, bit 1 is pump ON, bit 2 is pump OFF and so on
If I link the DB word of PLC into KEP OPC and then bring it to Ignition, how can I use the each bit of this word
I mean, I want to link the bit 1 to the button click in the screen
please explain the procedure
sdahigaonkar
Its probably easier to do this in Kepware. just add “.*” to the end of the address to extract the bit
so for bit 4 from variable memory address of V12 would be V12.4
If you want to do it in Ignition then read the address as an OPC tag and then make separate expression tags such as “getBit({[~]V12},4)”, if you put this all in a UDT with all the bools from the variable then its easy to repeat.
Hi,
thanks for reply,
I could not understand it properly. Can you please explain me in detail. I am beginner for Ignition/KEP
Suppose example - DB900.DBW0 is the word I have in PLC
DB900.DBX0.2 is the pump ON bit I want to receive from Ignition button click on the screen to the PLC
DB900.DBX1.0 is the pump running feedback bit, I want to send from PLC to Ignition for display
Like this all the bits will be used for pump-1 for various purpose.
Same way I have 20 pumps and so I will have 20 words of DB900 in the PLC
How I will make tag for this word in KEP
How the KEP tag will go to Ignition and how tag to be made
How I can use bit 1
Thanks for guiding me
Watch this video to see how to get a bit from a tag:
inductiveuniversity.com/video/e … -functions
Best,
hello,
Thanks for giving link for how to use getbit function. I understand.
This is for reading individual bit of a word received from PLC.
Same way can you please suggest me how to write to a bit of a word and sending to PLC
To write individual bits you will need to address them individually. Consider not reading entire words–just read individual bits. Use a UDT with a string parameter to supply the common part of the OPC path, then an integer parameter for the ‘n’ in the first DBXn.0 address. Everything else would be generated in the UDT from those. There would be no getBit() expressions at all.
As an example, say the string is {base} = “[S7]DB900.DBX” and the integer is {start} = 0. Then within the boolean elements of the UDT, use OPC items paths like “{base}{start}.0” for the first bit, then “{base}{start}.1”, …, “{base}{start+1}.0”, et cetera. Each boolean can be separately designated read-only versus read/write.
I’ve attached a simple UDT export as a sample/starting point. Just import it into your data types folder.
SiemensSimplePumpUDT.xml (1.44 KB)
2 Likes
thanks for giving solution. I will try to implement
with OPC UA the “.*” is not working anymore. NOw no choice but to do hoops and tricks with getbit() and other suffering
The ability to append .N to specify the bit to an OPC Item Path has always depended on the OPC server you are connected to supporting that syntax.
What server are you connected to? What changed since "anymore"?
ecostruxure OPC UA server expert
see link:
It used to work but not anymore. NOt create error on OPC server instead of working properly
Ok, so Schneider changed the behavior of their OPC UA server.
That's definitely a bummer if you were relying on that behavior. You should probably open an issue with their support.
OPC UA does not allow the user to access a bit of a word directly. The OPC UA specification (OPC 10000-3 - UA Specification Part 3 - Address Space Model 1.05.01) does not specify this as a standard data type.
This is true in the sense that yes, there is no dedicated service or parameter for the Read service that can specify a bit within the word, but there is nothing preventing a server from modelling bits as Boolean Nodes underneath other Integer-type Nodes, and/or making them accessible at a NodeId like $NodeId$.BitNumber, just as Ignition and Kepware and practically every other OPC server have been doing for years.
It's a modelling choice that is up to the server vendor.
What makes me afraid is the explanation: The OPC UA specification (OPC 10000-3 - UA Specification Part 3 - Address Space Model 1.05.01).
I hope the others OPC server wont do the same...
There is no reason to make that change. If somebody at Schneider read whatever part of the OPC UA spec they are quoting and thought the take away was "we can't expose bits of words in the address space any more" they're just plainly wrong
DO you have a good example of a derived tag to read and write bit in a word?
1 Like
thanks Ill try that, I guess it will work better than what I was trying to do right now:
PLc word tag - ecostruxure OPC UA - opc tag - refernce tag - igntion opc ua - tag.bit number
getting errors lol
FWIW…
I ran into this while converting from Concept > Unity/Control Expert. Concept UDTs/blocks “built” the word from internal bits and exposed the word as an output parameter.
I modified the UDT parameter configuration to expose the underlying bits of the word as “public” variables which are picked up nicely by OPC UA Expert via native OFS protocol and exposed as children of the UDT in ignition OPC UA client.
I even removed the word output parameters from the UDTs since they only existed for legacy modbus HMI communication . I also marked the internal/public HMI bits as “Application” tags and configured the PLC/UA Expert to only publish/subscribe to “Application” tags instead of every tag, drastically simplifying the OPC browse tree for clients/Ignition.