Loading an Excel-Like Square by Square Grid of our Mechanical System

For our product, we use a Square by Square grid, using X-Y-Z coordinates to draw a series of “Locations” that we can interact with. Each “Square” has a lot of custom properties, such as the “Type” of location (i.e. we can store pallets here, or only travel is allowed here, or pallets are inducted into the system here, etc.)

Our largest system currently is 7,800 individual locations, with a variety of purposes for each square. We display where Pallets are stored square by square, and also keep track of the location of our vehicles, square by square.

To do this, we are using Perspective and the View Canvas component. We created a function that grabs all of our data from our “Locations” table, and creates an individual “Instance” for each location square. Each individual instance has a “Pixel” coordinate, so we can effectively draw every square side by side and match our current implementation of the grid in Winforms. See a sample image from Perspective, and also a sample image of our current “Grid” using Winforms.

We find that as we have more and more instances to keep track of everything, the View Canvas becomes extremely inefficient, and we are unable to justifiably use it. For example, for our site in Washington, we have 7,800 “Locations”, and about 1200 “Pallets” stored in the system, and 20 “Vehicles” that move around this square by square setup, picking up and dropping pallets as appropriate.

The View Canvas has been the only way we have been able to successfully draw this Square by Square setup, and make it so we can interact with each individual Object, or “Instance”, where we are able to view the Location “ID”, the location “type”, whether it has a pallet or not, whether a “Vehicle” is in this position, as well as animate the vehicles traveling across the grid.

The view canvas seemed to work well enough for small systems (less than a thousand locations or instances), but for our largest system, it takes 10+ minutes to load every instance into Perspective, assign its pixel coordinates and modify the Background color of each “square” based on the type of location it is. The View Canvas has been nice because it allows us to be able to view all information on hover, on instance click, or at a glance but it’s just to slow. Also, View Canvas then repeats this long load when briefly switching to a different page and coming back, resulting in conversations about keeping the tab open and never closing it. Which is not ideal and very clunky.

We are unsure of what we can possibly use within Perspective to load such a grid efficiently, while still maintaining all information square by square, and make each square “interactable” where we can add or remove pallets to/from each square.

The purpose of our System Grid, is for the end user to be able to view the entire system, level by level, and see where they have pallets stored, what path the Vehicles are taking to reach pallets, and what each type of location is. And also, clearly distinguishing between a “Location” and whether it has a “Pallet”, or a “Vehicle” in said position.

I hope I explained this well enough that our goal is apparent.

Does anyone have any ideas of how we can do this quickly and efficiently?

We built all instances for the View Canvas via our own scripts and on change events.

1 Like

I think the next most obvious thing to try would be dynamically creating/returning an SVG, though interactivity will be challenging.
After that, the thing to do would be a totally custom Perspective component - obviously a non-trivial amount of work, although perhaps not as much as you might think.
I guess an approach in between the two would be a Webdev (or other server) endpoint in an iframe with a custom webpage you create yourself. Passing information to/from that webpage from Ignition could be tricky, but you’d have direct control over the loaded javascript.

A lot of the overhead is probably because the view canvas, as the name implies, works on entire views, which are a fairly ‘heavy’ abstraction. If you don’t need to dynamically add or remove components, and can instead just reshuffle them, moving items around yourself on a coordinate container would probably be more performant. It sounds like that probably won’t fit with your needs, though.

1 Like

Do you have any favorite resources for writing our own Perspective component? A good place for us to get started? This sounds like the best option I’m thinking.

Right now, the public SDK example is the resource:

Be aware that we’re in the midst of revamping our entire build process, which may include some different frontend build paradigm(s) - if you get something working, it should continue working fine, it’s just that it will hopefully get a lot easier to get something working once that restructure is done.

The very high level description of creating a Perspective component is:

  1. Build a React component that conforms to our wrapper over React.
  2. Put the assets for that React component somewhere your module can access, i.e. in a .jar in the module.
  3. Tell Perspective’s Java side about your front-end component(s) via the ComponentRegistry.
  4. Deliver the assets for your component when requested by the rest of Perspective.
1 Like