I have no idea what to even try or what info is relevant, so here are a few things that might be helpful:
perspective 8.1.18
it happens “randomly”, I can’t seem to find a way to reproduce it consistently
The view is actually a flex repeater
When this happens, another view just above it doesn’t show. (I find this really weird)
There’s a message handler configured on the dock’s main view, and receives messages sent when navigating, in order to load some parameters (no alterDock available here).
But it seems to come from a different view in the dock. I’ve never seen this error before, and I have a metric ton of it.
I’m kind of guessing the view tries to access parameters that the message handler is supposed to set, but something goes wrong with it. Maybe the dock hasn’t loaded yet when the message is sent ?
That error with the SingleConnectionDatasource indicates something in your setup is hogging the gateway’s configuration database for 30+ seconds at a time. That causes all kinds of problems. Complicated bulk tag operations sometimes do this (via the designer) but can also be caused by scripts’ use of recursive tag browses. Ring any bells?
No tag browse in there.
One of the views in that dock is a custom accordion. One of the views in that accordion is responsible for the SingleConnectionDatasource error.
Let me describe things a bit more accurately
in blue is the accordion.
in red is the view that sometimes provokes the Configuration Error.
the view above it disappears when the Configuration Error happens.
the device tree that is used in the accordion is built when the dock is first loaded, from a fixed session.custom property. It only filters it to extract the devices it needs.
the alarms are also computed when the dock loads, by reading and filtering a dataset tag that contains the currently active alarms (generated by a gateway timer script).
In the basic accordion rows, each beige rectangle pulls data from 5 tags.
the detail rows each pull data from 3 tags. This is the view that causes the SingleDataSourceError.
Do you think I should try to pull ALL the data for ALL the devices in the accordion at once, and then dispatch that to my flex repeaters ? I’d rather avoid that, as it doesn’t seem practical, but if that’s what needs to be done, I’ll do it.
“Pulling data from tags” uses what technique? Indirect tag bindings? system.tag.readBlocking() in transforms? Or a bulk system.tag.readBlocking() for multiples at a time?
Indirect tag bindings, configured on custom properties.
The detail view’s bindings have map transforms,
One of the bindings on the beige rectangles is a direct tag binding on the alarm dataset, and has a script transform:
priorities = value.getColumnAsList(1)
devices = value.getColumnAsList(5)
try:
return max(prio for prio, device in zip(priorities, devices) if device == self.view.params.name)
except:
return None
The “Configuration Error” you are seeing is typically encountered when a property which a component absolutely must have is dependent on a binding which is failing to resolve properly, or is returning an unexpected shape (when the property must be an object, but the binding returns a simple value). Once the component enters that state, the only way to get out of it is to force the component to re-evaluate the binding in question – usually a page refresh, or a scripted forced evaluation.
So you’re probably encountering this because the instances of the Flex Repeater is being evaluated as null or something of that manner. Could you provide a description of the components in this View? I know you mentioned a Flex Repeater and an Accordion, but what is the top-most piece? Please provide the exact order so I can try to replicate on my end.
The one above is just an embedded view that contains a coordinate container that itself contains coordinate containers (an alternate version of it is a flex repeater instead, same problems arise). All those are in a flex container.
There’s also, in the same dock, another container that contains more static things, I doubt they have anything to do with the issue:
screenshot of the browser's tree
The flex repeater ‘devices info’ is the one with the Configuration Error.
The view it repeats is quite simple: A coordinate container, that contains 3 labels (2 with bindings to the view params) and an embedded view for the indicator, also bound to the params:
screenshot of the browser's tree
The script on the root container is just an on click event to navigate to the device’s page.
The flex repeater’s instances property is bound to 2 custom properties of the dock’s main view, and a session property:
session.custom.devices is a map of devices on the field. It is static, and evaluated once with a script when the project is created. custom.zone_num is a simple int, custom.alarms is bound to a dataset tag, that contains data about the current alarms and is generated by a gateway timer script.
All it does is make a dict of devices with active alarms, where the keys are the device’s name and the values are a counter of how many times that device appears in the dataset:
I tried to be as thorough as possible concerning the devices_info flex repeater. If you think more details about other parts of the dock can be relevant, I’ll dig there too.
If you think some parts of this could be done better, I’ll gladly take any advice you can throw at me ;D
I'm not saying the binding needs to finish, I'm saying the evaluation finished and returned something invalid -- like null -- and the next update is likely to return the same. If the binding is constantly updating and returns a valid value then the component should recover.
I'm not concerned about their involvement, I'm trying to discern why they aren't displaying - when the component which is faulty enters the Configuration Error state it should not prevent other components from displaying; knowing what else you're using could help me determine why it's disappearing. Just for clarity, could you provide a screenshot of the entire "dock" so I could get a better idea of what is displaying and what is not? Your previous screenshot is pretty limited to just the Configuration Error, which isn't something I actually need to see.
I'll look into this with the info you've provided and see what I can find.
The first culprit we need to lockdown is going to be this name property. I'm going to need you to supply some logging in your transforms for me to really make progress on this.
Steps I need your help with:
You have two transforms which have objects which contains a key of name. One of those transforms even assigns that key by reading the name of a different object. One of these two transforms OR something downstream which uses the objects returned from the rsus binding is trying to work with a name but failing - potentially due to an unexpected type being encountered. Please put additional logging into these transforms which logs the value being supplied for name. I also recommend you include the type of the value being supplied so that we can identify areas you might think are strings but which might be Qualified Values. I also recommend that you rename your variables or keys to something more descriptive than name. It seems you've programmed this for simplicity, but now during troubleshooting you're running into a scenario where your blanket use of a generic name for variables/keys is masking the failure cause.
Thanks for all the help and clues. I'll work on your requests tomorrow, as it's pretty much time to get out of the office and in front of a fresh beer.
Maybe I should try leaving it like this for a while and see if it gets refreshed after a while - maybe something is just taking too long.
I say this, because I can't see a reason why it would sometimes fail and sometimes not. The way I get it to fail is going to another page, then coming back, then out again, then back again, until it finally fails. Nothing apart from the url changes, so I'd expect the bindings evaluation to return the same thing... just maybe not always in the same amount of time.
I doubt I can easily do that. That property is usually a kind of object member, so that you know what you're looking at: rsu.name, ncu.name, etc.
I kind of need the genericity for things where different kind of devices get mixed up. It would be doable with more descriptive names, but it would make things more complicated.
I hope logging will be enough.
The highly suspect line I’m focusing on right now is in the ncu transform:
ncu_name = next(z.ncu.name for z in...)
If the z.ncu object does NOT have a name key, you’ll hit this error. I’m not saying this is definitely the culprit, because that name vaiable/key is in use too many places to realy narrow it down, but try also investigating that ncu object and how it’s created; make sure there are no instances were it could be created without a name key.
It’s a static object that doesn’t get created, it’s always there. I pull it out of a ‘constant’ session property:
screenshot
The only way for the ncu_name variable to not be what it’s supposed to be would be for the comparison to fail: ncu_name = next(z.ncu.name for z in value.devices if z.zone_num == value.zone)
If value.zone is not a valid zone number, then nothing good will come out of this.
This zone number is set by a message handler on the dock’s root:
def onMessageReceived(self, payload):
if payload.get('page') in ["zone", "ncu", "rsu", "tcu"]:
self.view.custom.zone_num = payload.get('zone_num')
The associated message is sent by a value change script on the pages’ main view params (passed through the url).
I believe I’m seeing similar behaviour to the above.
I have an embedded view used extensively that contains an LCD display. It worked fine until I tried to make it more flexible. I created a bunch of custom props on the view to determine whether the parameter intended for the LCD display’s value property was a boolean or a numerical type with one of three slightly different indirect binding patterns. I use expression bindings to unpack the incoming parameter string to various custom props based on prefixed characters. Some custom props are precursors for the evaulation of others.
Example view parameter strings:
-fDI_09_FS_01 ‘-’ denotes boolean, ‘f’ denotes flowswitch (used to select wording such as “flow” or “no flow” as opposed to ‘l’ for levelswitch (“level OK” or “level low”) and the remainder “DI_09_FS_01” is the root tag to be bound for the boolean state driving the message choice.
~Setpoint ‘~’ denotes a simple variable with no intermediary folder hierachy required within the indrirect binding, the view’s incoming parameters can simply be concatenated to form the binding.
The LCD display’s value is bound to several of the custom props (one for each possible ‘type’ of parameter passed, an expression selects the non-null value.
In principle this works OK (although I accept it is not graceful; I’m still feeling my way with Ignition), however, from time to time I get the Configuration Error described above. Refreshing the view fixes it. I figure my custom props are perhaps not fully evaluated when the view renders or my expressions/props are just clumsy.
Passing digital values to evaluate and display strings in the LCD display component is not providing much value so I was planning on dumbing the view back down to avoid the errors. I did learn a few things along the way.
