Nightmare. The breakage would be extreme.
Yeah, complete dead end. There's zero chance. Any new scripting engine would only be usable on new projects, or even gateway-wide on new installs. No chance of upgrades, no chance of interop.
1 Like
30 engineers * 3 projects * 5-10 gateways per projects and we're looking at managing ~300-600 ignition gateways all at one time... per day
Are you actually using 5-10 gateways a project? Are you just working on a massive scale or is there something I'm missing here? Maybe a ton of tags with separate IO servers, I'm curious
Maybe an Intellij plugin instead? Intellij has a free python plugin that lets it support whatever python version you install. I know nothing of the difficulties of making this work though, so it might not be feasible.
How much of the scripting would be capturable via transpilation of the underlying python code (if it's stored in text)?
It feels like it should be at least be possible...
Transpiling to another language is irrelevant. The script engine is hopelessly entangled with Jython internals, and so is a lot of user code.
1 Like
Ahhhh, i see -- sure, things like system functions etc are Tied to Jython
Absolutely, but it depends on the type of application.
Anything from Datacenter projects with dozens of IO gateways per building to enterprise MES applications that are running scaled architectures in the cloud.
For instance, we have an enterprise OEE application that runs elastically scaled frontends, a dedicated pair of middle ends, separate broker, 1 OEE backend per site for ~15 sites and then MQTT brokers on premises publishing data to the cloud. For a dev to run this project it is typically around 7 gateways at a time (to run 2 sites)
In general, we find that licensing is very cheap compared to the development it takes to hyperoptimize a project for scale like this. So easier to just dig in with more gateways and make gateways easier to deploy.
1 Like
This is why my VS Code Extension I have doesn't implement an LSC or anything, and it just does all of the work on the fly to handle any intellisense type recommendations etc.
In general though, I think I will end up building a module that implements an LSP (**cough** or @PGriffith will finally get to it **cough**) and then update the vs code extension to work with that instead.
maybe you can shoot my dream down before I try too hard:
- there’s an exhange resource by corso/@andrew.geiger that allows running Jupyter Notebooks against the gateway.
- vscode “server” can be hosted just like Jupyter
- gateway resources can be accessed from scripting environment (or just via filesystem if local)
- embed locally-hosted vscode server (connected to gateway runtime like the Jupyter resource) in a perspective iframe (or just access it directly)
- ….
- Profit!?
Lots in this thread, so I'll just note the Jupyter kernel is essentially just another scripting execution context in Ignition. So when it's spun up, it jams the desired context into globals and evals what the Jupyter environment hollers at it. There's more to it, but that's kind of the gist. The upside is it gives easy (IMO) near full control over that context.
If you can talk like a Jupyter server, you can talk to the kernel. The protocol isn't terribly involved, but it's basically a souped up REPL - you type commands, Jupyter hollers them at the kernel, the kernel executes the commands, and then the kernel emits replies. The catch is that Jupyter uses ZeroMQ (for now), so if your plugin or environment doesn't natively support that then you'd need to add that to drive the kernel running in Ignition.
But if you add additional handlers in the kernel, you can hook into and extend the kernel for other non-Jupyter commands, if you like. I think it should be as simple as adding another handler.
1 Like
@kgamble I made a little video to show how to use the vscode stuff. Your resources are gold!
https://youtu.be/TFooeDCMe_Y
10 Likes
This is better than I could have presented it! Lol, I love it!
I didn't see you mention it, however if you open a VS Code Workspace, you can have VS Code automatically trigger the gateway project scan for you whenever you save project scripts. If you have a docker-compose.yaml file for your project, It should attempt to auto-generate the following settings structure in your workspace settings, however if it cant auto-detect it from a docker-compose.yaml you can just add it in yourself.
"settings": {
"ignitionFlint.ignitionGateways": [
{
"label": "Frontend",
"address": "https://frontend.localtest.me",
"projectPaths": [ #The relative filesystem path to your ignition projects root directory.
"temp/projects"
],
"updateDesignerOnSave": true,
"forceUpdateDesigner": true,
"supportsProjectScanEndpoint": true
}
]
}
2 Likes
I did not realise I could do this! Very nice!
Interesting perspective, I figured it had to be some sort of multi-site OEE application. With that many gateways no wonder you've got so many tools to stay organized!
How does one enable the "refresh" button you show:
Nothing happens when I check any of the toolbar options, including the one I thought might have that: "Perspective Designer Toolbar." When I save a script file on the gateway, using the "Merge" button doesn't update my Designer on my local machine, but from your video it looks like maybe that refresh button does...?
I love that VS Code allows navigation via clicking a function name while holding down CTRL, something I really miss from my days of coding Java in IntelliJ. But it only seems to work within a single file/script. How can I get it to recognize all my other scripts so I can navigate between them that way?
If I can figure these two things out, I might never use the Designer for scripting again.
Did you install the Project Scan Endpoint Module? That is what adds that button in, as well as the REST endpoint at data/project-scan-endpoint/scan that the VS Code extension uses.
1 Like
No, unfortunately I know nothing about Gradle or keystores, and am working in a Windows environment so the build instructions aren't very clear to me...
You can just download the module and install it on your gateway if you go to the Releases page here
Then install it on your gateway, and configure the VS Code extension settings as mentioned here
No need to do a custom build of it unless you are modifying it for your own purposes or making changes to the module directly.
Edit: I realized after pasting this I should probably just release it as v1.0.0... since it hasn't needed any updates since November and been working flawlessly... lol
2 Likes
What are the projectPaths relative to? I just have them in the standard location on a Windows install: C:\Program Files\Inductive Automation\Ignition\data\projects