Musson Industrial's Embr-Periscope Module

Release Notice

Embr v8.1 - 2026.3.20
Embr v8.3 - 2026.3.20

This release fixes some bugs related to periscope.toast on iOS, Safari, and mobile devices.
Shoutout to @aaronrai24 for helping test.

This release also adds perspective.context.view and perspective.context.component object references to the runJavaScript context. This allows you to reference the current calling component/view. Note, these are not available when targeting a remote session or page.

Full Change Log

@embr-modules/periscope-web@0.12.0

Minor Changes

  • dd8a25b: runJavaScript functions now expose perspective.context.component. This is the client-side ComponentModel of the component that made the runJavaScript function call.
    • This is undefined when targeting a specific session/page.
  • dd8a25b: runJavaScript functions now expose perspective.context.view, the client-side ViewModel of the view that made the runJavaScript call.
    • This is undefined when targeting a specific session/page.

Patch Changes

  • 2aa9142: Toast container now smoothly transitions when docks are open/closed.
  • 06455f1: Remove dock padding when screen size suggests a mobile device. This allows the toast to span the full device width when docks are present on mobile.
  • afa89e6: Move z-index to the toast root container. Resolves #435.
  • cb55367: Refactor to properly distribute functions between perspective-client and utils. utils should be usable by any React project, and perspective-client should contain all helpers that are specific to Perspective.
  • Updated dependencies [dd8a25b]
  • Updated dependencies [ca09383]
  • Updated dependencies [cb55367]
    • @embr-js/perspective-client@0.6.2
    • @embr-js/utils@0.6.2
5 Likes

This Ignition Exchange Resource should be close to what you're looking for.

Hey @bmusson, the latest couple of releases seem to be missing the built modl files, not sure if this was intentional or something went awry? Do you have the modls available (i'm looking for periscope and charts at this stage). Cheers!

2 Likes

Thanks for the heads up, I’ll rerun the affected releases.

I changed releases to be Immutable, but didn’t take into account how I’m building the release :joy:

I’m creating the release, then uploading the artifacts after (which is failing because it’s immutable lol).

2 Likes

Haha, that ol' chestnut!

1 Like

The affected releases have been re-run.

The version numbers were double bumped... but I don't think I care.

3 Likes

Release Notice

Embr v8.1 - 2026.5.28
Embr v8.3 - 2026.5.28

Client Resources + React Component

Client Resources are files compiled to JavaScript that are loaded by the Perspective client on launch.

There are currently two supported types:

  1. TypeScript (supports JavaScript, TypeScript, JSX, and TSX)
  2. CSS Modules

All Client Resources loaded and run on page load/refresh, serving as a direct, robust alternative to Markdown Injection. They can also provide React components, which can be used via a new dedicated React Perspective component or anywhere you would normally use an EmbeddedView.

Attached is an example project that demonstrates:

  • Writing React components.
  • Accessing the available system modules: (system:perspective and system:periscope)
  • Importing/exporting between Client Resources.
  • Using style classes from CSS Modules.
  • Rendering Client Resources inside of EmbeddedViews, using @/{path} syntax.

client-resource-testing_2026-05-28_1506.zip (400.9 KB)


Future Work

  • Synchonous Loading

    • Currently, Client Resources are loaded asynchronously via Periscope's BrowserResources.
    • This means the first render can happen before all resources are loaded.
    • Future work will attempt to make Client Resource loading happen during client startup, before any rendering occurs.
  • Embr Charts Integration

    • More work needs to be done to add Client Resource support for Embr Charts.
    • The goal is to provide a way to write Chart.js plugins inside Client Resources.
    • This will require synchronous loading.
9 Likes

For external dependencies or complex libraries, is it possible to load files directly from a folder on the hard drive instead of defining them one by one inside the Designer’s Resources section? For example, could we configure a specific directory that the module can access and import files from at runtime, similar to how a web development module exposes a shared folder?

1 Like

You can actually use

import * from “@webdev/{path}”

to reference the current project’s WebDev root:

If you put your resources in a folder and then mount it using the WebDev module, you should be able to load them this way.

I’d like to have a more dedicated way to load 3rd party libraries though, so I’m open to any suggestions.

1 Like

Your module should expose a dedicated folder inside ignition data folder to user so user doesn't need to buy webdev only for this purpose.

2 Likes

I get this error when I install the module on 8.1.52:

1 Like

Ah dang, that error is going to appear on any 8.1.49+ gateway.

That change is over a year old, so it’s definitely time for us to commit to Embr’s 8.1 branch to 8.1.49+ compatibility.

(Also shows that it’s time for my customers to upgrade too :eyes:)

1 Like

Hey @bmusson, I questioned a few weeks ago whether your Periscope module's EmbeddedView+ container might resolve the issue with IA's EmbeddedView container randomly not passing params through sometimes (or not-so sometimes!!) when you have nested views (even 2 layers deep), often where the params have dicts/objects and lists.

I've just done an upgrade from v8.1.42 to 8.1.51 and noticed that a lot of the EmbeddedView containers had these issues, so I moved some of the problem ones across to EmbeddedView+ and the issue went away entirely; I cannot get them to fail.

So I think the answer to my question is "yes", it does resolve the issue.
Although now my question to IA is: why is it still an issue??

7 Likes

If I had to guess:

  1. It’s been this way forever.
  2. They can’t really solve it without re-architecting how views are initialized.
  3. They can only do that during a major release.
  4. 8.3 has enough going on already.
1 Like

Some would say that the symbols on the screen reflecting the bindings that you've set on them is somewhat important for a SCADA system though :face_with_hand_over_mouth:

6 Likes

I agree, to the point that I went and found a solution :joy:

5 Likes

Release Notice

Embr v8.1 - 2026.6.4
Embr v8.3 - 2026.6.4

This release resolves a NPE error reported by @jpark.
Thanks Jae!

@embr-modules/periscope@0.14.1

Patch Changes

  • 0e6b25f: Resolve NPE related to ClientResourceManager initialization for ClientResourceWorkspace's Welcome Page.
    • @embr-modules/periscope-web@0.14.1
4 Likes

I started this java GUI for the designer to facilitate easy switching between EmbeddedView and EmbeddedView+ because of this :face_with_hand_over_mouth:
(It just migrates the differently named props between the two since they're different [better, more consistent names in yours, imo])

6 Likes

Yeah, I need to target 8.1.49+ for this to work.

I’m torn between totally dropping support for 8.1.33 through 8.1.49, or maintaining a separate release branch.

Any thoughts from the community? What are other 3rd party module authors doing?

I think that's fine to support it for versions 8.1.49+ , I personally wouldn't mind upgrading a client's gateway to the latest version of 8.1 to use it.

1 Like