Troubleshooting Control Programming

Q-SYS Quantum Level 1 Training (Online) : Control Troubleshooting

10 ) Control Troubleshooting

9m 52s

Transcript

Troubleshooting Control Programming 9m 52s
00:07
[Music]
00:08
Q-Sys Designer software contains several components that can be added to your design
00:12
and then configured to provide control functionality.
00:16
For programmers that are relatively new to the platform or for more complicated programming
00:21
involving a large number of control components,  
00:23
there are some troubleshooting tools available in Q-Sys
00:26
as well as a few important control concepts a programmer needs to understand. 
00:32
Let’s start with a simple example.
00:35
In this schematic we have a Custom Controls component  
00:38
configured to provide two Trigger buttons
00:40
to drive the Decrease and Increase input control pins on a Value Stepper component.
00:47
If we press the Trigger 1 and Trigger 2 buttons,  
00:50
you would expect the Value Stepper to decrease or increase its value.
00:55
As you can see, this does not appear to function correctly.
00:59
There is a very helpful tool available in Designer to help diagnose these types of issues.
01:05
If we go to the Tools menu and select View Component Control Info,
01:10
we will now see a popup window which I am going to dock at the top left of Designer.
01:16
This window will provide a list of the available controls and more importantly their control types
01:22
for any component we select in the schematic.
01:26
These control types typically consist of Boolean, Float, Integer, String, or Trigger
01:34
and let us know what type of control value  
01:37
the component will expect to receive on a control input pin
01:41
as well as what type of control value the component will provide on an output pin.
01:47
While the control components in Designer are quite forgiving when mixing and matches  
01:52
various control types
01:53
from one component to another,  
01:56
you can sometimes run into issues when a control component is receiving a mismatched control type.
02:02
If I select the Value Stepper component  
02:05
we see that the Decrease and Increase controls are Booleans,
02:09
but we are feeding these input pins with Triggers.
02:13
This mismatch in control type is the source of our issue here.
02:17
If we look at this corrected example where we changed the  
02:20
Custom Controls button type to Momentary
02:23
which will produce a Boolean control type value,  
02:26
we see that the Value Stepper then functions correctly.
02:32
In the next example, we have a Text Controller scripting  
02:35
component that provides a Toggle button control
02:38
that we would like to use with the SurgeX Axess plugin to control the electrical power  
02:44
of our AV system.
02:46
If we press the Power Toggle button multiple times,
02:50
we notice that the Power Outlet state does not follow the state of the Toggle button
02:55
and we have to press the button twice for power on and twice again for power off.
03:02
To troubleshoot this issue, we can check the control type  
03:05
of the SurgeX plugin in the Component Controls window
03:09
to find that the Power Outlet control is a Trigger.
03:14
This Trigger input will work with a low to high transition  
03:18
from our Power Toggle button’s Boolean value,
03:21
but not from a high to low transition which is why we have to press our Toggle button twice.
03:27
To correct this issue, we can use a Control  
03:30
Function component configured as a Logic 1-of-N function.
03:36
We will need to route both the output of our Power Toggle  
03:39
and the SurgeX Outlet State output into the inputs of our Control Function.
03:46
Now, the SurgeX plugin will receive a low to high  
03:49
transition to activate the Trigger when the Power Toggle goes high,
03:54
and then receive another low to high transition when the Power Toggle goes low  
03:59
to turn off the power.
04:03
Moving onto another troubleshooting example.
04:06
In this design, we are attempting to perform a Value Sum of some Integer  
04:10
Knobs and the Value output from a Selector component.
04:14
If I change the Integer Knob values you can see that the Value Sum is adding these values,
04:21
but the Selector’s Value output is not included in the overall sum.
04:26
To troubleshoot this issue, we can use a couple of tools.
04:29
We can use our Component Controls window in Designer to determine the Selector  
04:34
Value’s control typewhich is a String.
04:38
We can also use another tool such as the Control Signal Monitor script  
04:43
to monitor and track control value changes in our design.
04:48
This helpful script and many others are available from the QSC Communities website.
04:54
If you are unfamiliar with the QSC Communities website,
04:57
this site is a location for QSC programmers  
05:00
to ask questions and receive answers for Q-Sys related topics
05:05
as well as download example designs and control programming such as this
05:09
Control Signal Monitor script we will be using to help troubleshoot this issue.
05:15
If we take a closer look at the Selector’s Value, we see that the String value is changing,
05:21
but the actual integer Value remains zero.
05:25
For us to correct this issue we will need to find a component that can interpret this String  
05:30
and provides an Integer control value.
05:34
To do this, we can add a Custom Control configured as an Integer Knob.
05:39
changes are now being converted by the Custom Controls Integer Knob
05:44
and the Value Sum is now providing us with an accurate sum of the control values.
05:51
To assist with troubleshooting plugins and scripts,
05:55
the left pane of Designer includes a section called Inspector that provides information
06:00
to help locate and identify scripting and plugin issues.
06:05
In this example, I am currently connected to a core,
06:08
and if we navigate to the Inspector pane in Designer,
06:12
we see the Scripts and Plugins sections that include a list of the scripting components
06:17
as well as all of the plugins included in our design.
06:21
Paging through this list, we can quickly scan all of the scripts and plugins in the design  
06:27
to identify which ones may be causing an issue.
06:30
This design includes a Script named Inspector Demo  
06:34
that I have added to help illustrate some of the diagnostic information provided by the Inspector.
06:41
If we open up this demo script’s section in Inspector  
06:45
we can monitor various aspects of this script while it is running.
06:50
Starting at the top we see a Load percentage my script is consuming.
06:54
This Load percentage is based on the processing time required for my script to run versus
07:00
the total processing time Designer allocates for a script or a plugin to finish processing.
07:07
If I then set my demo script to perform some very processor intensive tasks,
07:12
you will see that the amount of processing time consumed by this one script will increase.
07:18
This increase in processing time is also reflected by the Control  
07:22
and Lua Compute Usage in the core’s Status component.
07:27
If you have a large number of scripts or plugins or just a single processing intensive one,
07:33
this processing time percentage can help identify where your design may have an issue.
07:40
Next, we have the Memory consumption that displays how much RAM my script is consuming.
07:45
This can be helpful identifying issues such as memory leaks where  
07:49
an ever increasing amounts of RAM is being consumed.
07:52
With my demo script, I created a trigger to start a memory leak  
07:56
by storing more and more data to RAM as shown in Inspector.
08:01
This increasing RAM consumption is also shown in the Memory Usage meter  
08:05
in the core’s Status component.
08:08
If this were left running, this would eventually cause serious stability issues for my design  
08:14
as the core will eventually run out of RAM.
08:18
If we look in Inspector below the memory usage,
08:21
we have Errors which will display if there  
08:23
have been any processing errors while running a script or plugin.
08:28
If I use my demo script to execute some poorly written code that causes an error,  
08:33
not only will we see this listed below Memory,
08:36
but we will also see a red indicator beside the name of our script  
08:40
to help us locate if a script or plugin is having an issue.
08:45
In addition, the Inspector displays the Verification status of scripts and plugins.
08:51
As an example, a plugin such as the SurgeX plugins in this design has been verified by Designer
08:58
and can be trusted to be an unaltered official version of the plugin.
09:03
If a programmer was to download a plugin from Asset Manager,
09:07
and then crack open and make any modifications,
09:10
this verification process would fail and the status  
09:13
in Inspector would show as “Verification Failed”.
09:17
If we look at my demo script’s status,
09:20
this shows as 'Unverified' which indicates the script  
09:24
has not gone through the verification process
09:27
which is perfectly normal for user generated scripts.
09:31
As you can see, Inspector can be very helpful when locating and diagnosing issues,
09:36
but this can also be helpful when writing your own scripts and plugins to check for memory leaks
09:41
or excessive processor consumption to avoid these issues while your code is still in development.

Downloads and Links

Troubleshooting Control Programming 9m 52s