Guru's Verification engine ensures consistency, confidence, and trust in the knowledge your organization shares. Learn more.

L3AV Control Programming Policy and Process v1.2.03

Revised 9-14-26

Purpose & Scope:

This card describes the complete process required for successful programming of custom control solutions for AV projects.

v1.2.02 Adds process for updating CLIENT (to include a DSP sub folder) folder after project has been completed.

Process Flowchart

image.png

Policy:

  • Applicable steps are required for successful completion of every project.
    • GUI (CLIENT APPROVAL IS REQUIRED ON EVERY PROJECT)
      • As described below GUI submittals are MANDATORY and must be completed prior to staging.
      • Use the template form located at the end of this card
      • For Micron projects the programmer must edit the Control Specification to match the design of the room(s) that are being programmed.
        • There are premade files in 01 Micron Info/Control Sec and QRG folder
    • LOGIC
      • This step is required and to be completed when the GUI is done. Dates are scheduled by the Engineering Manager
        • Smaller projects will require logic and GUI to be completed during staging, or the day prior to staging
    • DSP (where applicable) (the DSP process is covered in another Guru card)
      • To be completed prior staging
    • Staging and Onsite efforts are scheduled during the weekly review with the FE/Install teams
      • Programming calendar is updated during that meeting
  • Programmer shall attend all project related meetings
    • PM shall invite the programmer to the internal KO meeting
      • This is the time where any issues or discrepancies are addressed.
      • Record any meeting notes in the One Note file for programming in the shared OneNote for that project
      • image.png
      • This is mandatory for each day working in staging and commissioning
        • In the event that another programmer takes over the project these notes are essential for a smooth handover
      • The Template listed as 0000 - Template is to be used as a starting point
  • Work is added to the Programming calendar by Engineering Manager based on weekly meetings with the L3 Micron/House teams and OPS
    • All programmers have access to add/remove items from the programming calendar.
      • This is designed to maintain visibility of items not directly related to programming jobs. Each programmer is encouraged to add any personal/professional obligations to the calendar for visibility
      • In the event there is a conflict contact the Engineering Manager to resolve any schedule issues.
  • Programmer creates folder in the _Projects or _Micron Projects Dropbox folder
    • Sample folder structure is located at
      • Level 3 Audio Visual Dropbox\PGM\_Projects\9999 - CLIENT - Job Name
      • Use of this folder structure is mandatory
    • Files are created with the following naming convention
      • Example = 4349_Carollo_Portland_Room1_v1.0.07
      • Format = [ProjectNumber this is mandatory]_[Client(this field is optional)]_[ProjectName(this field is optional)]_[SystemNameIfApplicable(this field is optional)]_v[Major].[Minor].[Bugfixes]
      • Use of this naming convention is mandatory
    • Once in Staging changelog is to be updated every time a new version is saved
      • The programmer that initially writes the code keeps the folder in the main folder
        • Sub folders are created for each space with the programmer's initials (see 5552 as example)
      • Initial version (v1.0.00) does not require a Changelog entry
      • All subsequent versions (after Staging begins) require a Changelog entry following the Changelog format
      • Use of the Changelog is mandatory
      • In the event that Dropbox is not available at the end of a particular day and alternative backup is required. This is typically in the form of an external drive.
        • If an external drive is needed, inform the Engineering Manager and L3AV will provide one
      • Do not power off your laptop without an external copy somewhere
      • Daily backup of changed files is mandatory
        • Make sure Dropbox is done syncing before powering down your laptop

Process:

  1. Programmer creates GUI submittal
    1. This is required for all projects (even if there is no GUI task)
      1. GUI SUBMITTAL MUST BE COMPLETED PRIOR TO STAGING
        1. Staging team needs this document to validate programming for AV9000 compliance
      2. This includes button panels and keypads
      3. Engineering Manager approval is required for not doing GUI submittals
    2. Verify type of GUI required via PM/Proposal
      1. L3AV standard
      2. Client Standard
      3. Micron Control Specification edit to match room capabilities
      4. Other (typically custom)
    3. Use approved GUI submittal form only (link included at the bottom of this document)
    4. Send GUI submittal to BE for review
      1. BE to acknowledge GUI covers all intended design requirements
      2. OR BE and programmer shall schedule a meeting to align GUI functions to design intent
    5. Copy GUI submittal to Cortex prior to staging
      1. Staging will use the GUI as a reference for labelling keypads and testing the system’s operation
    6. GUI to be completed during staging, if needed, to allow accurate screen shots from Zoom etc that use active equipment
    7. Micron requires a (PM coordinated) Control Spec page turn with UCC and the local Business Unit for EVERY project.
  2. Logic is developed for the project and completed prior to staging date
    1. Logic time is scheduled by Engineering Manager, but it is the programmer’s responsibility to ensure sufficient time is allocated and to notify Engineering Manager if additional time is needed or if too much time has been allocated
    2. DSP and Control files are to be uploaded to the Sharepoint folder prior to staging so the FEs can load the files as soon as they start the staging process.
      1. The programmer is still responsible for loading and testing subsequent revisions during the staging process.
  3. Staging is scheduled by Engineering Manager in alignment with OPS
    1. Staging includes complete testing of all DSP and programmed functions
    2. The programmer is responsible for ensuring that all programming is tested by the staging team
    3. Perform daily updates to the project’s Teams channel
      1. This is mandatory for every day worked on a project in staging
      2. List items tested, not tested and reasons for not testing
      3. Enter any red flags that arise during the staging testing process
        1. Red flags, if critical should not wait for daily updates
  4. Onsite deployment is added to the programming calendar by the Engineering Manager in alignment with OPS
    1. Programmer shall be available during the onsite deployment process and assist as needed
    2. The programmer is responsible for ensuring that all programming is tested by the onsite team
    3. QRC shall be completed and delivered to the PM prior to training
      1. Copy QRC into the project folder
      2. Any final edits to the QRC shall be completed prior to the archiving of code
      3. All customers use the standard QRC (except Micron)
    4. Perform daily updates to the project’s Teams channel
      1. This is mandatory for every day worked and/or scheduled on a project onsite
      2. Enter any red flags that arise during the onsite testing process
  5. Once all functions have been verified by the onsite team and training has been completed the programmer shall copy completed programming in L3AV format to Cortex once the onsite deployment is completed
    1. DO THIS AS SOON AS YOU FEEL THAT THE PROGRAMMING IS DONE
      1. THIS APPLIES TO SERVICE PROJECTS AS WELL
        1. IN ADDITTION UPDATE THE SERVICE CASE NOTES INDICATING WHAT WAS DONE AND THE VERSION OF FILE COPIED TO THE PROJECT FOLDER
      2. You can always replace the files if changes need to be made later
    2. This includes completion of all punch list items that relate to programming
    3. Also included is the creation and delivery of the QRC (Quick Reference Chart) to the customer/PM
    4. Copy files to Cortex in the following format: image.png
      1. The programming folder structure in its entirety gets copied over (first folder shown)
        1. Delete the DSP folder inside the programming folder (on Cortex only) to prevent confusion
      2. The CLIENT folder contains all REQUIRED files shown in the example below (programming files will vary by manufacturer)
        1. image.png
          1. Description of files are as follows:
            1. GUI submittal (modified control spec for Micron) and QRC files
            2. Control system programming source code and COMPILED FILE
              1. Compiled files are required to support service needs
              2. Screenshot of processor showing file loaded in processor matches file in CLIENT folder
              3. Using Crestron Toolbox's Text Console, type "PROGCOMMENTS"and HOST" to get the program information and hostname on a single screenshot
                image.png
            3. Touch Panel file and COMPILED FILE
              1. Compiled panel files are required to support service needs
              2. Screenshot of panel showing file loaded in panel matches file in CLIENT folder
              3. Using Crestron Toolbox's Text Console, type "PROJECTINFO"and HOST" to get the panel information and hostname on a single screenshot
                image.png
            4. JSON file used for Zoom portal (if applicable)
            5. Final DSP file
              1. This file to reside in its own folder
              2. Since Biamp does not have a method to gather a screenshot of the running file the following method will be used
              3. At the time of CLIENT folder creation the programmer will connect to the DSP and retrieve the currently running DSP file. This retrieved file includes a date stamp that will serve as verification that the file in the CLIENT folder matches what is running in the DSP at the time of CLIENT folder creation
            6. Drawing files used during the development of the programming
              1. These may be different than the final files. These files represent a snapshot of how the system was installed and programmed
            7. All JSON config files used in the program
      3. The DSP sub folder in the CLIENT folder contains the final DSP files (this may be updated by the FE after final commissioning)
        1. It is the programmer’s responsibility to ensure the latest DSP file is copied into the CLIENT folder
        2. If the DSP file is missing please inform the Engineering Manager
      4. If the CLIENT folder needs to be updated after it has been created please post in the project channel and @ the PM and PC so they will know there are new files to be transferred to the customer
        1. ALL SCREENSHOTS AND DSP VALIDATIONS MUST BE FOLLOWED EVERYTIME THE CLIENT FOLDER IS UPDATED

Related Resources:

9999_Client_Project_TP_User_Guide_v2.0.pub

QRG-touch_panel-2pg-v4.pub

https://app.getguru.com/card/TyAMpB8c/L3AV-DSP-Programming-Processv1100

Multiple Programmers working on a single Project (Control and/or DSP) v1.0.00

Micron Custom Room Control Specification

Micron Programming Development Phase Programming Process

You must have Author or Collection Owner permission to create Guru Cards. Contact your team's Guru admins to use this template.