[00:00] Components and clients will resize to fit within the available space of the window in the client. You can see my client here. If I were to bring in the right-hand side over here, that this edge, this little label here, shrinks in or stretches and grows depending on how large the client is, up until a certain point. Right about here, you'll see that I have some scroll bars. And if I make this a little bit smaller, the actual size of the component no longer changes here. This is because the client has reached the minimum size. Once this occurs, we stop resizing the components and place scroll bars on the client. Now the minimum size is customizable so lets' take a look at the settings here. I'm going to move my client off to the side first, just a second here. And in the designer, I'm looking at that same project. I'mma come up to the Project menu, go to Properties, and under Client, and User Interface, we can see the Minimum Size up here.

[01:01] Now if I were to make these much smaller, so I'll change my Width and my Height to zero, I'll click OK. And I will save and publish the project. Let me bring my client back over. We can update. Update again. And you can see I no longer have scroll bars. If I reduce the size of the client again, we can see that the component is also being resized. Furthermore, we will not see scroll bars because the client has not yet reached its minimum size. Now my docked windows, on the edges here, do have a say in the matter. If we bring our client to a size so small that it starts to cut in on to my docked windows, we will add the scroll bars. But the main lesson here is that when the client's width or height is smaller than the project's minimum size, scroll bars are added. When starting a new project, it is a good idea to plan for the minimum size your clients will be launched on and adjust the project properties accordingly.

Ignition Client Launcher

However, in an effort to aid architectures making heavy use of 32-bit hardware, Ignition 8.0.3+ includes some batch and bash scripts that can be used to launch 32-bit clients. These launchers are unsupported, but are useful in cases where 32-bit Vision Clients are the only option. Ignition versions 7.8.x or older: To export the Gateway log on Ignition versions 7.8.x or older, go to your Gateway's Configure / System / Console page, and click on the 'export logs' link on the right. This will download a file called logs.bin.gz. Inductive Automation Support has the tool necessary to view this file.

Ignition Client Download

Ignition Client Tags

[00:00] In this video, we'll take a look at the differences between client and gateway event scripts. We'll start off in the designer, and under the project section, there's a scripting section, and inside of there you'll see we have client event scripts as well as gateway event scripts. We're going to start by double clicking on client event scripts and you can see that there are several options available to us, we'll talk about these more in depth in later videos. But all you need to know for right now is that client event scripts are scripts that trigger based off of something that happens within the client. So for example, if I wanted something to run on a timer, so I could use a timer event script, so every five seconds I could do something on timer within the client. Now, it's important to understand that each running instance of the client will basically have another execution of this script or this event running. So if I had five clients open, I would have five executions of this timer script. One running in each client every five seconds. Additionally, if I closed all of the clients, the script wouldn't run anywhere. So actually, leads us to the gateway event script. So I'm going to open up the gateway event scripts. And these are very similar in concept to the client event scripts, except that they are scripts that run on the gateway itself. So using that same scenario, if I had a five second timer script defined on my gateway event scripts, I would have one single execution of that running at any given time, regardless of how many clients I had open or not. As long as the gateway's up, there will be one execution of that timer script. So you can see that this concept of a simple timer just running the script at some rate yields wildly different results based on the scope. Now I'm going to bring my client event scripts back up here. Now, if we compare the two, you'll notice that there are more events on the client event script side than there are on the gateway event script side. The reason for this is that some of the events on the client event side don't really make much sense on the gateway. So, for example, the keystroke and the menu bar, these are both constructs of the client. So it doesn't really make much sense for them to be running in the gateway. So that's why there's a difference between the number of available events within each scope. Now, another big difference is how print statements are handled. So let's say in my client event scripts I'll type print hello. So when the user logs into a client, we'll print this hello message here. Whatever we print here would be viewable from the clients console. However, if I take this same print statement, I'll copy it and paste it over to the gateway start up script here, this will appear in the wrapper log file that's located inside of the ignition installation directory. So if you wanted to see this print statement, you'd have to log into the server that ignition's installed on. In a lot of cases, this might not be an easy task, as you'll have to have direct access to the server. Instead, we recommend you use one of our system functions, and specifically system, dot, util, dot, get, logger. There's a logging function you can call, this returns a logging object that we can name. I'll call this gateway logger, we can then invoke it, and then pass it a message. So when you call this get logger system function here, you're actually injecting a message that will appear within the diagnostic logs on the gateway. This is typically a little bit easier to troubleshoot with since you only really need to have access to the gateway's web console. Since we're talking about system functions, it's important to remember the scope or where you're writing the script. Is this a client or a gateway event script? Some system functions are available in both the gateway as well as the client scope. My system util get logger here is actually a very good example of that. You can call the system function in a client event script as well as a gateway event script. However, if you take a look at the system gui, or GUI functions, confirm for example, shows a little confirmation message box the user can click on. This makes sense at the client scope but not so much at the gateway scope. So you can't call the GUI functions in the gateway scope. If you try, they'll throw an exception. Because of this, it's important you pay attention to the scope that the system functions you're using run at. If you're ever curious, you can check the user manual within the scripting appendix. Not only do we list the system functions, we describe the scope that they run in. The last thing I want to cover before we end the video here, is I want to take a look back at my designer here and I want to point out that these gateway event scripts, even though it says gateway here, this is, in fact, a resource of the project. So, for example, if I were to export this project, a copy of any gateway event scripts could potentially be in that export. Additionally, if I wanted to view gateway scripts and other projects on the same gateway, I would have to open those projects up in the designer. I can't view them from here. Lastly, if I duplicate this project, the duplicate will also have the exact same gateway event script. So I could have two scripts running simultaneously on the same triggers doing the same work. This could potentially cause a number of problems.