- This topic has 17 replies, 3 voices, and was last updated 2 days, 11 hours ago by
.
-
Posts
-
> Do you use the Linux machine without desktop interface?
– No, I use Ubuntu with a graphical interface (Xubuntu).> Do you prefer editing mimics on Linux to avoid extra licensing?
– The main idea from my manager is to use Windows only to create local projects and use Linux (our server) strictly as the runtime to collect data from those projects and display them in WebStation. Since the entire runtime environment is on Linux, I assumed that using only one license on the Linux server would be sufficient.The engineer creates the project on Windows → performs deploy → edits mimics directly on the Linux server via the web interface (accessing via IP:port or link) → and the mimic loads the plugin components properly.
However, when we tested editing and saving a mimic via the Linux web interface, the mimic did not load automatically in the runtime WebStation.
Initially, the mimic was not even found because the .rsproj file apparently was not deployed to the server and remained only on Windows. To work around this, I manually copied the entire project folder to the server using AnyDesk, and then the server was able to find the .mim file and open it in MimicEditor.
When MimicEditor opened (showing the extra plugin components under the trial key), we were able to use the plugin and save the mimic. However, it still did not update in WebStation automatically.
That is when I considered manually copying from the editor path to the runtime path: SRC=”/opt/scada/Projects/UFVs/Views/” DST=”/opt/scada/Views/”
But this feels impractical and possibly incorrect, which is why I am clarifying this before proceeding further.
The editor path (Projects) does not seem to update automatically with deploy operations, and I would need to use Syncthing so that every time the Administrator creates a new folder or view, it gets synchronized to the server. Then, after editing, I would run the deploy.sh script to copy to the runtime folder.
Since this approach feels unnecessarily complex, I am wondering if something is wrong in my workflow.
I downloaded and installed the full latest version of RapidSCADA on the Linux server. From the Windows package, I only sent the ScadaAdmin folder to the engineer, since on Windows he only needs Administrator to deploy to the server, and the Linux server handles the full runtime.
So I would like to clarify:
1. In this specific situation (Windows: Administrator only / Linux: full native RapidSCADA server), is this the correct architectural approach?
2. Should the Deploy operation automatically update the editor path on the server? In that case, Syncthing would not be necessary.
3. If I use MimicEditor on the Linux server via the web interface and save the .mim file, should the plugin components immediately appear in WebStation? In my case, they only appear if I manually copy from: /opt/scada/Projects/UFVs/Views/ to:/opt/scada/Views/.
Use temporary keys for Mimic on the Windows development computer and that’s it. Then, when you commit the project to a Linux server where the keys are permanent, everything will work.
The main idea from my manager is to use Windows only to create local projects and use Linux (our server) strictly as the runtime to collect data from those projects and display them in WebStation.
In this case, the correct way is editing the project on Windows workstation and then upload it to the Linux server for execution. Use GIT for managing project versions.
In the next version of Extra Mimic Components, a key will not be required for editing mimics.
- You must be logged in to reply to this topic.