TIAPortal HMI how to have a button change functions when a value is changed

[thewalkerist]

Hello,

I am currently trying to control a motor in my plc. I've made a simple on/off button logic. And it works pretty well, when i press the button it changes the speed of the motor to 100 and when i press it again it changes it to 0. This is nice. I also created a text list for my button so whenever the Motor speed is at 0 my button says "Start" and whenever it is between 1 and 100 it says "Stop"

And i wanted to put a I/O field in there so if i dont want to just start and stop i can just change my motor speed to a specific value. Now this works as well but the two of them doesnt work well together.

Remeber those "Start", "Stop" texts? yeah it seems they are just for show. So if i open up the programme i see START because currently my motor speed is 0. So i just change the value from my I/O field to lets say 50. And my button now is saying STOP. That is nice aswell. If i press STOP what happens? it sets the speed to 100. Not ideal at all. But if i press STOP again it works. Because of my code. I've tried putting some comparators but it didnt work out. Instead made things worse

[drbitboy]

[Update: or is the HMI button a momentary i.e. it sends a 1 when you press it, then it sends a 0 when you release it?]

So when you press and release your HMI button, it sends a 1 to HMI_PMotor_Start_Button?

And the next time it sends a 0?

And the time after that it sends a 1 again?

And when you enter a speed (e.g. 50) on the HMI, that number is passed to the PLC, and somehow the PLC turns on the motor to run at that speed? I don't see where you have that logic. How does HMI_PMotor_On set the speed to 100 when it becomes 1? How does HMI_PMotor_On set the speed to 0 when it becomes 0?

What do you want to happen if you enter a 0 speed in the I/O field?

[thewalkerist]

So when you press and release your HMI button, it sends a 1 to HMI_PMotor_Start_Button?

Yes but it sends 1 while the button is is released. Not while im pushing it down. So i press it with my hand and take my hand back it becomes a 1.

And the next time it sends a 0?

Yes that is correct.

And the time after that it sends a 1 again?

Yep.

And when you enter a speed (e.g. 50) on the HMI, that number is passed to the PLC, and somehow the PLC turns on the motor to run at that speed? I don't see where you have that logic. How does HMI_PMotor_On set the speed to 100 when it becomes 1? How does HMI_PMotor_On set the speed to 0 when it becomes 0?

Well i didnt show you that logic. I will post a screenshot with this post. As you can see when the HMI_PMotor_On is energized it sets the speed of my motor to 100(dont worry about that retentive data stuff, i did it so that i wouldnt have to enter 100 everytime i go through with the programme ) and if the HMI_PMotor_On is not energized then motor speed becomes 0

What do you want to happen if you enter a 0 speed in the I/O field?

Lets say i press the START button and speed is now 100. After that If i enter 0 in the I/O field i want the Button to say START again and if i press that START i want to speed to become 100 again. To be fair button shows START when the motor speed is 0 but it only writes that way. If i click that START button it Stops because of my logic and i have to click again to make it 100(reverse is a worse situation, i didnt press start or stop and instantly changed the value to 50. After that button shows STOP but if i press it the speed becomes 100 instead of 0). Because my logic is like a latch of somekind. So if i click HMI_PMotor_Start_Button once it always turns the speed to 100 first and after that i can press that button again and now it will become a 0 and this will repeat. But if i enter a value manually through my I/O field this messes up the logic.

[thewalkerist]

or is the HMI button a momentary i.e. it sends a 1 when you press it, then it sends a 0 when you release it?

No its not, when i push it and keep my finger on it it doesnt become active, i need to release my finger to make it a 1. Repeat the same to make it a 0 again

[moggie]

You need to "turn off" M12.0 if your i/o field is changed to 0.
Use a comparator to check i/o filed = zero to create a pulse (eg. M12.3).
Then use M12.3 to turn off M12.0

[drbitboy]

HMI-PLC interactions are more reliable if they are "(HMI) set and forget:"

• That means the HMI only ever sends a 1 on any and every button release (or on press, if you prefer), and
• the HMI does not ever send a 0 i.e. on alternating button events, as it does now.
• "Set and forget" also means it is the PLC's job to assign 0 to (i.e. Reset) the Boolean HMI_PMotor_Start_Button_ONS,
  • which is more aptly named HMI_PMotor_Toggle_Run_Button_ONS.
  • The "_ONS" suffix is to highlight that this boolean will be 1 for one scan only (Vasilyzzz.png).

See the attached image; it's ugly, and could probably be cleaned up, but it does the job you specified; I would have preferred a proper flip-flop circuit, but the interaction with PMotor_Speed_Perct complicates that.

Caveats

• I assume the HMI analog I/O field can write to, and does read from, the PMotor_Speed_Perct tag in the PLC.
• The logic for the Start/Stop text on the button should not change, as it is dependent on the value in the analog I/O field, whether read from the PLC or entered via the HMI.

[drbitboy]

Same approach and functionality, still ugly, but fewer instructions.

xxx.png

[Steve Bailey]

Sometimes logic you create to do one thing gets in the way when you try to enhance it to do additional things. When that happens your best strategy may be to start over rather than modify. That may be the case here.
You have two commands, one to tell the motor to start, the other to tell it how fast to go. Most, if not all VFDs have two parameters for that purpose, one to specify the source of the run command (keypad, hard-wired terminals, network interface, etc), the other to specify the source of the speed command (keypad, hard-wired current or voltage, network interface, etc).
Your logic should control the run command and the speed command separately, and include any interlocks between the two you feel are necessary. You may want to prevent setting a run command unless the speed command is greater than zero or cancel a run command already in place if the speed command is changed to zero.

[thewalkerist]

Originally Posted by moggie

You need to "turn off" M12.0 if your i/o field is changed to 0.
Use a comparator to check i/o filed = zero to create a pulse (eg. M12.3).
Then use M12.3 to turn off M12.0

That didnt work out, If i do it the way you told me then this doesnt solve the problem instead made things kinda worse . I tried a similar thing to that with a P_Trig before and it didnt work out as well.

[thewalkerist]

Originally Posted by drbitboy

See the attached image; it's ugly, and could probably be cleaned up, but it does the job you specified; I would have preferred a proper flip-flop circuit, but the interaction with PMotor_Speed_Perct complicates that.

This one worked out. I was trying to make my set-up work out. But as Steve said...

Originally Posted by Steve Bailey

Sometimes logic you create to do one thing gets in the way when you try to enhance it to do additional things. When that happens your best strategy may be to start over rather than modify. That may be the case here.

And i wasted quite a lot of time with my current set-up . If i just scrapped my first idea and tried something new maybe then i wouldnt need your help . But to be honest i am glad. I saw a way to make a quick ONS without the need for a P_Trig. For that and your unending help, i would like to thank all of you again sirs

[thewalkerist]

Originally Posted by drbitboy

Same approach and functionality, still ugly, but fewer instructions.

Oh and btw 1s debounce time is really long. Is there a specific reason for making it 1 second? I currently changed it to 1ms and it works without a problem. 1 second is already long and with the 100ms latency of the button press it feels like the programme is lagging.

[drbitboy]

[QUOTE=Steve Bailey;905071]Sometimes logic you create to do one thing gets in the way when you try to enhance it to do additional things. ...
Your logic should control the run command and the speed command separately,.../QUOTE]

+1 Well said!

I found it easier to write the code to fix the problem than putting the problem into words.

[drbitboy]

Originally Posted by thewalkerist

Oh and btw 1s debounce time is really long. Is there a specific reason for making it 1 second? I currently changed it to 1ms and it works without a problem. 1 second is already long and with the 100ms latency of the button press it feels like the programme is lagging.

• My actual concern was that with HMIs,
  • I think I have seen synergy with the non-determinacy of Ethernet cause a "phantom" command, which re-assigns the value of a boolean, to be sent more than once for a single button event*,
  • so I wanted to ensure any such stray followup commands within the .Preset time are ignored,
  • because if the HMI did actually sent two or more commands to change the target boolean, but did so after only one button press, then the PLC logic would cause every other command to cancel the previous one.
• The 1s was arbitrary to ensure it was possible to confirm, with my slow eyes, that it was working as intended
  • I didn't implement an HMI, so I was using TIA Portal in [Online] mode both
    • to toggle the bit to 1 from TIA Portal i.e. with Alt-F2,
    • and to manually change the HMI analog I/O field-driven speed with Right-click-[Modify operand...],
  • The only things the TOF "_Debounce" delay implements are
    • preventing my perceived phantom commands (see previous item) from toggling the motor run state
    • preventing the operator from toggling the motor run state again within 1s after the last time they did it.
• 1ms is more or less the same as no timer at all;
  • in that case remove the [NO .Q] and [TOF] instructions entirely and the code will still work,
  • although if you really see an improvement in response by changing the .Preset to 1ms, then summat else is amiss; cf. the last item below item ...
• Finally, the TOF is not causing any delay in initial response to a button press (or release):
  • Even if that .Preset was T#100s, the TOF would not delay the response of the motor speed being changed any more than whatever delay you are seeing now.
  • The "_Debounce" TOF is misnamed - it is not really a standard debounce that validates a button press after a delay, so the only delay will come from the HMI latency.
    • There will be no delay on the PLC side because the first rising edge of the HMI_PMotor_Start_ONS boolean will execute the intended action, which is when the TOF starts
      • Note that the speed logic on the top branch is dependent on [NC HMI_PMotor_Start_Debounce.Q], which will only evaluate to TRUE before the TOF is triggered on the next branch.
    • The TOF is only there to disarm the logic for the .Preset time, i.e. ignore any subsequent rising edges within .Preset time after the first.

* My theory, supported by no explicit evidence and rather only observed flaky HMI-PLC interactions plus similar observations relayed to me by my brother, is that Ethernet/IP and other such protocols try to bring determinacy to Ethernet-based protocols by sending a command to do [action X] multiple times with identical packets, with the intent that the protocol implemented in the receiving node will ignore any duplicates after the first is received, so if any one packet has a hypothetical 95% probability of being received, then two of the same packet have a 99.75% probability of at least one being received, and sending five yields 99.99996875%, which is between five and six sigma if my math is right, and anyway the packet loss is probably way less than the 5% in this hypothetical, because by the time the network gets to that state the AGVs are running amok and the plant is a hot mess anyway so the network would have been fixed long before this, and I really should end this sentence ...

[thewalkerist]

I see, i understand now where you are coming from sir. Thank you so much for your valuable answer.

[moggie]

Originally Posted by thewalkerist

That didnt work out, If i do it the way you told me then this doesnt solve the problem instead made things kinda worse . I tried a similar thing to that with a P_Trig before and it didnt work out as well.

Hmmm strange it worked for me in a simulator - maybe you could show what you did? Although I see you have it sorted now.