I forgot to inquire if you have set memory settings for this machine? Perhaps you can try allocating ~70% of the memory explicitly to Java via moving an appropriate memory script from Mango/bin/ext-available into Mango/bin/ext-enabled, modifying it to your system's resources, and stopping, then starting (not restarting) Mango to have it come into effect.

Yeah, I've tried to upload it here with the "Upload File" option but it says I have no permission to do that. I've sent logs to the support address.

Hi Stefan,

I assume you're talking about DGLux 2.5 (the one based on flash). Unfortunately, the answer is no, it does not backup for you. I've faced that problem a few times, and got more than a little frustrated. My various solutions are:

Is the DGML existent? If so, it may be salvageable! You can find the DGML in the Export item in the menu within DGLux. If you get a really large block of markup on your dashboard that won't render, there is one or more issues somewhere in the DGML. I usually found it via binary search: find the main container and elements and cut out half, import, see if it worked, If not try the other portion, if so replace it and try to halve that section. It's important to make sure you only cut out complete tags and their contents. It's kind of a pain. It'll end up being a malformed property of a tag, like some weird connector string but no actual value (sorry I can't be more specific, I haven't done this in a long while). Or it will all be empty, and you're out of luck. Go ahead and check it on the disk too, if it is empty in DGLux. It may still have all the markup in your Mango/web/modules/dglux/web/dgml (or other directories in dglux/web).

Which brings us to...

Vigilance. Save to your computer (via export in menu, I believe)! Save to server! Save everywhere. Shift + s

I got so aggravated when I was doing lots of DGLux work with this issue that I actually did all my development of new dashboards in a sandbox designed specifically to avoid this stuff. I had a timer element that counted to 300, and triggered a script, which increased a counter X and saved the dashboard (saving the dashboard is a behavior you can trigger) under a name like "autosaveX-dashboardName.dgml" It was irritating to have DGLux freeze for 4 seconds every five minutes, but it saved me three or four headaches over many months, so I accepted it.

It's definitely part of the reason we moved toward our angular dashboards and embracing standard web technologies.

^ You cannot configure it such that anyone may register a user. Only admins may create users, and this includes through the API. So, while you could have a portal to create a user built on the API, that portal would have to have admin permissions.

When each will need to complete a poll durring intilization so it sounds like it's taking a long time for your slave devices to respond and for the poll to complete.

If you edit the data source you can see the last 10 poll time and will look like this:

0_1464974869733_upload-e1efb9d4-4536-42b5-befa-c5129c255eaa

This would be useful information to know. As Phillip mentioned using the new options for a multi threaded start up should speed it up but ultimately the issue is your slave device response time.

Once you have a license installed for Enterprise Demo which includes the NoSQL module it will no longer be a Demo and will be a fully working system.

Glad to hear it!

Well, Joe, I'm making a dashboard in DGLux, and one of the things I want to display there is the number of nonsilenced nonacknowledged alarms from mango, so the user could see that on the dashboard, and go to mango to acknowledge or silence them.

Thx for the video and link.

Hi Stefan,

This information is not kept in the database, as the reliability of a point only exists in the runtime.

This attribute's value is available in DGLux. When you bind a point, one of the options is 'status' which typically says 'ok'. If you wanted to have that supercede the coloring from the value, you will have to create that behavior either with logik attributes or by passing everything through a script.

I'm sorry this answer isn't more specific but I'm pretty sure you will find the answer to your questions in the videos in this section: http://infiniteautomation.com/forum/category/16/dglux-graphic-dashboards

The way to display a value that doesn't exceed a limit is to first bind the value to a script and write a script to limit the value. Use the output of the script to bind to your gauge.

In DGLux 2.5, I do not believe so. I don't think there is an event propagation model like in HTML, so there is no way built in to catch all keypresses by a single object.... but then, for almost all objects except explicit inputs it is not possible to catch any keypresses.

So, there's the hack-it-together solution: use an input with a change trigger that invokes a script. The Script would read the text input and perform any behaviors necessary then set the input back to blank if it wasn't already. You wouldn't be able to use the arrow keys, since they probably don't have a value to the input field, but you could use WADS, the num pad or something.

Thanks joel, it did help. :)