How to learn perspective the right way?

I suggest familiarizing yourself with the different scopes as it’s not super intuitive when you first start scripting with ignition and might be a source of hair pulling and frustration :stuck_out_tongue:

You can also review the list of system functions, which are built-in ignition functions, so you’re familiar with what’s available:

Then learn what expressions are, where, when and how to use them:


Can you please share more details about sandbox environment and how this is set up as i have not used it yet. Is it similar to docker?

No, just create a project called “Sandbox” (or “LearningProject” or whatever). You can then create views, write scripts, named queries, etc., to experiment and try stuff out. Then next time you need to experiment - with a table, for example - you open the project, go to the view with the table and begin your investigation.


yep keeping things separate for experimenting is definitely a good idea as i did fall into the trap of forgetting to delete the rubbish :slight_smile:

It’s how I let others know…


Mine is called “scratchpad”

Project ready can mean a lot of things. If you are doing a project that requires responsive design you definitely want to get good with flex containers and breakpoint views.

When you’re first starting a project I recommend setting up styles and building a general screen layout because then you can just copy a screen to make a new screen and all of your screens are already referencing styles that you can later tweak to update the whole app.

I agree with the suggestion to make a sandbox project and learn about CSS and Python. It’s also a very good idea to learn your way around inkscape for making custom SVGs and save them as “optimized SVG” because it makes them a lot smaller. The Ignition developers are currently working on making embedded SVGs work a lot better and knowing how to do all of that really opens doors.

You can do a lot by adding custom properties onto controls and binding them to things that you want to use to trigger code. Basically, you bind the custom property to something that changes and put a script transform on that binding to run whatever code you want to run. Don’t use that with a now function to do time-based animations because you can do it a lot more efficiently with a css transform. That said, you can execute a good project without knowing how to do animations and all that. It’s just cooler if you can do all that also.

Learn about sending messages to pass information around your project.

Copy/paste things from Ignition into a text editor. This shows you the JSON structure of things and also gives you an understanding of things you can copy/paste.


Get familiar with the developer tools in your chosen browser. Learning how to find the CSS style names that ignition is using in order to customize your look and feel is extremely important. Also, make sure you have multiple browsers to test in, sometimes what works in one doesn’t work in another and the only way to know is to try.

Also, test in a real browser, some things just don’t work the same when run from the designer. Using the designer is a good gut check but the best test is always the browser.

I would also recommend getting comfortable with JSON. Learning to recognize when a JSON string is valid or not comes in handy.

Also, here is a good post that I have bookmarked that really helped me when I was starting to pick up perspective.


Sending messages is so useful, it amazed my fellow PLC engineers. :smile:

1 Like

Yes and another really cool thing you can do once you understand the JSON part (which you copy/paste into a text editor to see) is that you can put a script transform on a property that has sub properties and you can populate all of the sub properties in the script by returning JSON from your script transform.

That combined with an expression structure binding can turn into a function that gets called any time one of an number of parameters changes and dynamically builds a complex control layout. Play around with that. It’s amazing what you can do.

1 Like

Thanks for all replies so far. What about troubleshooting skills for perspective @lrose mentioned developer tools -definitely yes. What other tools/technique do you use for troubleshooting perspective ? I am already familiar with troubleshooting/tracing in vision

Here is also an old essay I wrote about the topic lol. Still has some good gems in there.

The best part about the forums is there is a long history of questions like this that inevitably give people an opportunity to share their best practices with the community.


The best way to troubleshoot anything in Perspective is to use logging. I recommend using a project script to do something like this:

# This is defined in a package named "Logger"
def log(name, msg)
    system.util.getLogger(name).info(str(msg))  # string casting for safety

Then you can easily call your logging anywhere in your Project (not tags, as they’re Gateway scoped) with this:

Logger.log("FocusAreaInUse", "What the next step is")

Including logging like this can easily help you determine what code is not being reached when troubleshooting logic.


A comment on troubleshooting like this, it is super useful, however if you have a lot of different sessions you may want to see things in the specific sessions console or the designer.

I often use a wrapper class to add the capability to push logs into the web developer console, as well as the script console on top of this.

A link to the helper class I use is here: gists/ at master · design-group/gists · GitHub

Using it is very similar to the above, and it uses the builtin .info, .warn, .trace, etc. functions to that its pretty seamless to switch to.

In the gateway logs you see regular messages, but if the correct logging level is enabled, you also see them in the perspective console or script console.

Example script:

logger = Logger.logger("FocusAreaInUse")
logger.trace("Step 1")"Step 2")

Example output (in all consoles):

FocusAreaInUse.TRACE: Step 1
FocusAreaInUse.INFO: Step 2

For Perspective clients though, you also probably want to let the user know the thing didn’t work. For that I wrap my whole script content in try except blocks, with the except block calling a library script function that opens an error popup showing a custom message along with the traceback.format_exc()


Could you give a example

   shared.perspective.errors.displayError("Someone wrote the code bad, like this English")
def displayError(msg=''):
   import traceback
   if msg != '':
      msg = "{}\r\n{}".format(msg, traceback.format_exc())
      msg = traceback.format_exc()
   system.perspective.openPopup('popup', 'popup', {'msg' : msg})

Sometimes you might want to check for Java errors as well, as these aren’t caught by the basic except. Especially if you have queries in your code.

from java.lang import Throwable

except Throwable:

Thank you

xD lets create a game in perspective to learn how to use perspective

not me tho, i would do way to much unorthodox css or js injections... i would be bad example for a starter xP maybe for the extra bonus levels

1 Like