I'm looking to have a database containing the locations and materials,... required to operate a warehouse.
The client wants to have a local Edge to make sure they can keep operating everything but Edge can't use databases on it's own.
Is it possible to have a named query tag via remote tag provider to use this info in the Edge?
How would it respond when the connection is gone, you continue making modifications in the tag and then the connection comes online?
Sometimes Edge isn't the answer.
If you want DB access without a connection to "central," install a limited license set of the full version locally.
1 Like
You really want to use standard Ignition in the facility with such a system, and have the database local as well. Really.
1 Like
If there were already a full Ignition gateway on-premises, and you were looking at adding an Edge instance for a process area within the warehouse, then yes - there are discussion points - majority of which would involve a messaging scheme between Edge <--> Full gateways (Edge cannot query DB directly, but can request that another gateway run the query and return the results, which may be stored in a dataset tag for use locally).
In general, Edge shouldn't be considered if there is not a full gateway to accompany.
Oy! Never do this. If uptime/fallback is a concern, add a redundant backup server to the full Ignition install, not an Edge instance.
...because? Edge has limitations, but operating as a standalone (periods of offline access) gateway isn't one of them.
In the same facility, an offline situation should never happen. If the local network is not reliable, fix the local network !! Add multiple link paths moderated by RSTP or your favorite branded equivalent, if necessary.
Edge as a fallback solution requires dramatically more engineering to deploy, and to maintain. It may be a good deal for an integrator advising an end-user, but is not a good deal for the end-user.
Can't say I've experienced much hardship with fallback regarding Full+Edge architecture (trivial by comparison to Full-Full). This is another case where details matter. Lots to speculate on. To get back to the topic & better answer the OP:
An Edge gateway cannot connect to DB. Since an Edge gateway can have only one tag provider (and, it cannot be a remote tag provider), I believe the answer is No.
Can a remote (full) gateway write to tags on an Edge gateway? Sure...please don't do this.
See above. If you need an Edge gateway (really, any gateway) to operate standalone, then ensure information is stored locally. The request for the information should always originate where the data is to be stored, where possible.
While a full Ignition gateway and local DB is the preferred route for a new installation, know that Edge is perfectly capable of scaling out an existing architecture:
- Sending cached historical data that's been accumulating during an outage (via native store & forward - up to 35 days).
- Requesting information from a full gateway (using native methods)
After all, that's what it was designed for: "...from the plant floor to independent remote sites..."
Can you elaborate a bit on this? How is this different than having a backend gateway and having the frontend gateway write to tags on the backend gateway?
The specific case in this topic would be to run a query tag in the overall system's Standard Ignition gateway and push the result down to an Edge Ignition gateway. Ugly and trouble-prone through any network problems.
Thanks. If one has already decided to host the project on Edge gateway and wants to use message handler to move data back and forth to a full gateway and then to the database, what are the potential risks for going that route? I know Chris said in the previous post that he would cache data to a dataset tag. But is this method even reliable?
This statement was edge-agnostic. I added a tip later on in the post, stemming primarily from a future someone trying to troubleshoot the once-working logic:
Assuming that Gateway1 is the gateway that needs data that only Gateway2 has access to: Gateway1 requesting data from Gateway2 (when it needs it) is preferrable over Gateway2 sending data to Gateway1 periodically. The data stream will be easier to troubleshoot down the road.
What data do you need to 'move back and forth'? Do you require that the data is cached locally?
Context of data size and frequency you intend to pass would be important consideration. Is this an occasional task or something that’s going to be constantly pinging messages to move a lot of data?
I do basically what you’re asking without issue. I use a central Ignition gateway’s database to store certain user-specific config data and query it when they sign in to load it into the local session but that is infrequent as it only loads during sign on and writes if they change something. However you do have to embed the consideration of a down network and how that will pan out. In my case, they simply get the default trend configs rather than allowing them to format things to their liking. None of it is safety related.
1 Like
In my use case, it is potentially going to be process parameters will be managed in the database. Caching data locally will definitely be ideal as it can reduce the frequency of requests. If assuming network is reliable and steady, this method is still okay?
If these configuration parameters are for the Edge gateway's exclusive use, you might consider keeping them local to Edge (via folders of Memory Tags, or a Dataset tag, etc.).
Reliability is relative...but I'd say 'yes'.
If there are other reasons for utilizing the database, consider exploring the sending of messages to full gateway, whereby message handler on full gateway executes the (named?) query and returns results of the query to the Edge gateway.