Hi everyone,
Kindly assist. I am moving a DBW to QW with a move block in my I/O mapping logic. Is there any system function in Siemens that allows you to explode the QW (Output word) into Output Bits like its done on ABB with CONV_IB blocks.
Thank you.

 

I'm not familiar with the ABB system, but you can address the output bits individually in your logic. If your outputs are in word QW0, your bits will be Q0.0 through Q0.7 and Q1.0 through Q1.7. If you're using DB5.DBW2 to store your values, the value of Q0.0 would be stored in DB5.DBX2.0.

 

I'm not familiar with the ABB system, but you can address the output bits individually in your logic. If your outputs are in word QW0, your bits will be Q0.0 through Q0.7 and Q1.0 through Q1.7. If you're using DB5.DBW2 to store your values, the value of Q0.0 would be stored in DB5.DBX2.0.

Hi Joseph_e2,
Thanks for the reply. Yes I can do that but actually, with example DB you used DB5.DBX2.0, assuming a function block is writing to DB5.DBX2.0 which is moved by MOV block to Q0.0 in the output mapping. In my modification I am doing, I introduce a push button on the HMI which is linked to a normally close contact to bypass output but Q0.0 in other network. My fear is that in the next scan cycle the output mapping can write a bit into the Q0.0 even when the push button has been pressed. I hope you understand this description.
Thank you once again.

 

I think I see what you're saying. You have an FB somewhere that writes to bit DB5.DBX2.0. That bit then gets moved into Q0.0. You want to add a button to the HMI that will block operation of Q0.0. Is that right?

You're right to be concerned. You need to account for the output mapping overwriting what you do. Do you have access to the FB that controls DB5.DBX2.0? If so, you can modify the network that writes that address to also consider the bit controlled by the HMI. If you want the HMI button to make sure that Q0.0 is always off, you can just introduce your normally closed (AN) instruction in front of the coil (=) of DB5.DBX2.0.

If you don't have access to that FB, your job is more complicated, but it's not impossible. If you have access to the code that writes DB5.DBW0 to QW0, you can introduce an intermediate word, say DB105.DBW0.

Kind of like this:
A DB5.DBX0.0
= DB105.DBX0.0

A DB5.DBX0.1
= DB105.DBX0.1
//...and so on for all of the relevant bits

You can then introduce your blocking bit there:
A DB5.DBX0.0
A {whatever your HMI bit is}
= DB105.DBX0.0

You would then modify the output mapping code to write DB105.DBW0 into QW0 instead of using DB5 as its source.

If you don't have access to the mapping code either....{sigh...I REALLY dislike locked code}
It's a kludge, and I don't even want to suggest it because I would be REALLY grumpy if I encountered it in a machine, but...
You can introduce a single network between the call to the FB that writes the DB5 bits and the call to the FC/FB that does the mapping:
A {whatever your HMI bit is}
R DB5.DBX0.0

That's definitely NOT the best way to do it. The best way to do it is to modify the network that controls DB5.DBX0.0 to consider the status of your HMI bit at the same time it considers all of the other logic that's meant to control Q0.0. That way you can monitor that one network and see why the output is off when you might otherwise expect it to be on.

 

I think I see what you're saying. You have an FB somewhere that writes to bit DB5.DBX2.0. That bit then gets moved into Q0.0. You want to add a button to the HMI that will block operation of Q0.0. Is that right?

You're right to be concerned. You need to account for the output mapping overwriting what you do. Do you have access to the FB that controls DB5.DBX2.0? If so, you can modify the network that writes that address to also consider the bit controlled by the HMI. If you want the HMI button to make sure that Q0.0 is always off, you can just introduce your normally closed (AN) instruction in front of the coil (=) of DB5.DBX2.0.

If you don't have access to that FB, your job is more complicated, but it's not impossible. If you have access to the code that writes DB5.DBW0 to QW0, you can introduce an intermediate word, say DB105.DBW0.

Kind of like this:
A DB5.DBX0.0
= DB105.DBX0.0

A DB5.DBX0.1
= DB105.DBX0.1
//...and so on for all of the relevant bits

You can then introduce your blocking bit there:
A DB5.DBX0.0
A {whatever your HMI bit is}
= DB105.DBX0.0

You would then modify the output mapping code to write DB105.DBW0 into QW0 instead of using DB5 as its source.

If you don't have access to the mapping code either....{sigh...I REALLY dislike locked code}
It's a kludge, and I don't even want to suggest it because I would be REALLY grumpy if I encountered it in a machine, but...
You can introduce a single network between the call to the FB that writes the DB5 bits and the call to the FC/FB that does the mapping:
A {whatever your HMI bit is}
R DB5.DBX0.0

That's definitely NOT the best way to do it. The best way to do it is to modify the network that controls DB5.DBX0.0 to consider the status of your HMI bit at the same time it considers all of the other logic that's meant to control Q0.0. That way you can monitor that one network and see why the output is off when you might otherwise expect it to be on.

Great Joseph_e2, that was a great idea. You really helped me. I am very grateful.
I introduced an intermediary DB which worked perfectly for what I wanted to do.
Thank you.