Dashboard without Authentication

Is there a way to allow access to the Node-Red Dashboard without authenticating a groov user?

Processor: GRV-EPIC-PR1

No.

The idea has been kicked around a bit here at Opto and at the moment the user/pass requirement is going to stay…

I mean this is pretty good compromise…

1 Like

Beno,

Good compromise indeed! I don’t suppose there would be much appetite for allowing a Codesys Visualization to be the First App Loaded… is there?

That would be in the same ‘bucket’ as loading an Ignition visualization app on first log in.
There are some hurdles to get over before that is doable, and we know that because we are working on clearing them… sooooo…

Any further update on clearing those hurdles? Because being able to use a Codesys Visualization on a groov RIO would be amazing! Node-RED dashboard is OK for simple visualizations, but I have something much more complex in mind…

I understood that there are major issues with the Codesys UI interface… Perhaps I misunderstood…

Hey @greichert whats the current status of the Codesys web UI?

Also, may I just add, after re-reading this a few times… Putting a more complex web UI load on a RIO does not sound like the right thing to do, but, eh, thats just me…

Well, I was wondering about that too. And maybe I misspoke on the “complexity” aspect. I was thinking about a visualization option that would have better control over placement of objects on the screen. I’ve played around with the Node-RED visualization a little and found that a little lacking in that regard.

Here is something similar to what I am looking to do, which I am working on in another controller platform - building a PID loop interface:

Of course, something like this is fairly simple in groov View, but I am interested in using the RIO as a replacement for the single-loop controllers that we make heavy use of at my plant. And I’m sure many of you can recognize, based on my design, what controller family that might be.

Two questions (and thanks for the screenshot, very helpful).

  1. Are you using Codesys on the RIO? Or are you just wanting to use the native PID loops? The answer to that will depend on if question two is an option or not.
  2. Hows your HTML / CSS skills? I have not gone there as mine are not great, but if you are comfortable in them, I wonder if something like uibuilder Documentation v6 would get it done in short order?

As of right now, I am waiting on my RIOs to arrive - but when I ordered them, I did not request a Codesys license, since at that point Codesys had not yet been implemented in the RIO (yeah, our vendor has dropped the ball on this delivery…) I have an EPIC available in my spares stock, so I was going to use that as a test bed for some of this - at least creating a simple configuration and trying out a test visualization. But before I devoted some time in doing so, I wanted to see if it was even within the realm of possibility.

And yeah, my HTML / CSS skills are virtually non-existent… :grin:

At last check Codesys WebVisu was not available on the EPIC. Has that changed?

No, thats still the case. Nothing has changed in that regard.

Use groov View.
According to many engineers that I have spoken to it is easier to use and it is included with every EPIC.

This is a RIO only application.
Moving the data back to a central groov Server for Windows is an option, but I see the use case of using the RIO at a small PID loop controller with local UI.

Ok gotcha. Node-Red Dashboard is what I suggest for RIO users also. UI developers can do amazing things with the typical Node-RED UI dashboard implementation.

Did you see the first post in this thread?

Im wondering if I can find some time and put something like your screenshot together with the stock Node-RED dashboard.

Yes, my searching of the Forums did turn up that post, which showed me a little more of the capabilities of the Node-RED dashboard than what I had initially done on my own. I was thinking that I could use the PID loops of the RIO directly and utilize Node-RED for some of the ancillary functionality of the loop controller project by using existing nodes for some things and building up specialty functionality by using Javascript in Function nodes, thereby avoiding using Codesys entirely, but Node-RED isn’t “realtime” so probably not the best approach - but I’m open to suggestions and insights. Ben, if you’re willing to devote some of your valuable time to that, it would be greatly appreciated, but I was not expecting that level of commitment on anyone’s part.

From my point of view, there’s lots of ways to skin this cat, so I’m just spit-balling some ideas and approaches at this point. I could even use an EPIC that is networked in with a few RIOs to act as the HMI front-end with groov View, so really nothing is off the table at the moment - I’m just looking for the cleanest, most self-contained approach. I like the idea of using the RIO since I can change the I/O assignments based upon the needs of the control application, which is where all of these mental gymnastics started.

And yes, I know that the EPIC has the GRV-MM1001-10 module that provides the same functionality as the RIO. The main reason to use a RIO is that it is a stand-alone solution, and if it fails it is only one “loop controller” that fails. I could create an EPIC configuration that could support 16 “loop controllers” with the required I/O for each controller dedicated per module, but if the EPIC fails then we lose control of all 16 loops - not ideal. I know that my peculiar world of single-loop controllers is antiquated and out-of-date, but we have critical systems that rely on these controllers and having one failure take out several of them at once could be catastrophic.

Thank you to all that are reading my ramblings. I’m finding it rather cathartic to write all of this out, but I know it can be incredibly dull to read. :laughing:

I know your focus is on ‘single loop’ controller (RIO), but for those reading along, the maximum number of PID loops in each:

EPIC = 64 loops.
RIO = 4 loops.

After about 20 minutes mucking about in the standard dashboard…

Not sure how much more to keep pushing things along.
The LED/LCD is cute, but not sure it adds much.
The ‘32’ is the temperature, but could show other things.
To stack 4 of them would be doable, but start to take up some space.
Not sure what your deployed screen-size requirements are.
Same deal with the buttons, 1x1 on the left, and 2x2 on the right. It all depends on if you have a set deployment platform in mind or or not.