Not an easy way, but it is possible - but you do have to think about it before you wade on in.
Some background to explain why: When you click a button, an event is raised in Windows. In fact, that isn't what happens: Windows is a message based system, so when you click the button, it sends a message which the UI thread message loop retrieves when it gets to it and calls the Button.Click event handler (after jumping through a few hoops). Once the handler exits, the message loop can look for another message and process that.
Which means that while your event handler is executing, nothing else happens on that thread: no Paint events, no clicks, no nothing ... the thread is fully occupied handling the Click event.
As a result, if your Click handler sits in a loop continuously reading data from your PLC the rest of your app is "frozen" and can't do anything.
If you want to continuously read data, you need to move that away from the UI thread onto a new thread - which isn't difficult to do:
Switching From a BackgroundWorker To a Task - It's a Neater Solution, Particularly When Reporting Progress[
^] shows the code for two solutions. But ... it's not that simple because once you move code to a non-UI thread, it can't interact directly with UI elements like Controls, Forms, or any other display / input elements. If you try, your app will crash with a "Cross-threading exception". You have to transfer the information to the UI thread to display it - and that means either Invoking controls, or passing progress messages between the two threads.
So you have to plan what the new thread will do, and how it interacts with the UI - because if you read from the PLC as fast as possible, your interactions with the UI thread will clog up the system with messages and the system responsiveness will slow to a crawl or even stop from a user perspective.
Start by thinking about the data you are reading, and what exactly you need to display: if it isn't changing, do you need to display it again? What part of the data does the user want to see? What part is "packaging" that should be "stripped out" so that only "whole data" is transferred? 10 minutes of planning can save hours of hair pulling!
BTW: Do yourself a favour, and stop using Visual Studio default names for everything - you may remember that "TextBox8" is the mobile number today, but when you have to modify it in three weeks time, will you then? Use descriptive names - "tbMobileNo" for example - and your code becomes easier to read, more self documenting, easier to maintain - and surprisingly quicker to code because Intellisense can get to to "tbMobile" in three keystrokes, where "TextBox8" takes thinking about and 8 keystrokes...