That's a bit of a stretch. The audio component is a built-in component. Isn't it a bit weird that to make it work (in a "supported" manner) you need an additional module?
Who mentioned anything about a bug?
To add, there are some customers that are very strict on what software, including Ignition modules, that can be installed. So, using that use case, our options are very limited. My main point is that using webapps, which does work, should be supported, or another option supported that is native.
I can see that... I wonder if a built in sound file server, like there is for pictures, would do it. Maybe just allow the existing one to also host sound files would work.
And sorry for implying that you thought modularity was a bug. I did not intend to imply that.
You're basically saying that the 3rd party modules route is bogus, and IA should make everything native.
Sorry, as a module developer, I'm not sympathetic at all. Companies that reject 3rd party modules automatically are getting what they asked for: limited features.
No I am basically saying that a built-in component should work without additional addons (perhaps reread my responses). The customer(s) are the ones stating not to use 3rd party modules. They have their reasons, which I am not going to get into a debate on.
As an integrator, I don't typically bark too much at customers and their requests, otherwise, we might lose that relationship. I figured as an integrator yourself you would be somewhat sympathetic to that. From your response, sounds like maybe not.
I think this is a valid point, especially in relation to mobile devices meant to interact with control systems. Sound is a valid, an often important, method of notifying operators/users. For Ignition to create the sound module but then say "we don't really have an official way to host the file that this thing is supposed to play" seems out of place. Seems like if the file is supposed to be served to the client, it should have an official location on the gateway, similar to all the other graphics that are served.
But they don't say that. They have the official WebDev module (which predates Perspective, fwiw). If an end-user doesn't want to buy that (and Ignition has always been modular--there are lots of times customer trim basic functionality to cut cost), they can easily put a proxy in front of Ignition to serve files any way they like. Most of those proxy options are also free.
Third parties like me fill in options that are either more convenient or more featureful than IA's base offerings. That's the whole point of a modular system where 3rd parties can participate.
And the phenomenon isn't just about this audio component. For example, try using Perspective's Power Chart without the Historian module. Some parts of some modules simply don't work, or don't fully work, if you don't use other modules.
I have to agree with others. If IA is offering an audio player to be able to support things like audible alarms, they need to provide a means of supplying the audio file for that feature as well without needing to buy an additional module.
We're building some Edge systems and the only way I can find to make this work is to use the undocumented/unsupported path or buy the compute module, because I can't tie to a database to use your blob module and I really don't want to over-complicate things by adding a static web server to a small modular panel just to host some audio files.
It would be great if they even just added a folder under "data/modules/com.inductiveautomation.perspective" like "sounds" just like they have fonts, icons, and themes already where we can add custom icon libraries, custom themes, etc. I would think since that mechanism is already there, it should be a fairly easy addition. (I've already tried dropping a wav file under those folders and have tried making my own "sounds" folder and none of that worked).
This would at least travel with the project and get backed up. I'm not asking them to fully provide a full mounted folder resource like exists in the WebDev module, but just something similar to what exists for themes and icons that limits data types to only supported audio files.
Well, good luck convincing them. There're already free ways to deliver audio without any additional module (via proxy, or CORS configuration to allow external web audio, or via jetty's webserver folder), and a free module (mine) to deliver from a DB.
Ignition is modular. You buy/deploy the parts you need. Building everything in raises costs for everyone to benefit a few. Expect pushback from many of us who like modularity.
Adding the capability to host the sound files needed for audible alarming doesn't reduce the modularity of the system at all. All the free supported ways are not friendly to most of our engineers or customers (we have customers who are already struggling with the learning curve migrating to Ignition because they're used to other HMI products which are limited but are easier for them to grasp how things are done). They shouldn't need a computer science degree to figure out how to set up a reverse proxy or need to know how to set up content security policies (is there a way to do this with Perpsective?) The unsupported way also doesn't get backed up as part of a gateway backup and we don't want to run the risk of it breaking with an upgrade since it's unsupported (even though that seems to be our easiest option at this point).
It's no different than the drawing tools they're developing for perspective. Yeah, they could just say you're stuck using Inkscape forever, but I've already got people complaining that they have to use a separate program to just create some simple PID graphics for the system because they're used to HMI/SCADA packages having this built-in.
I also wouldn't say this would benefit just a few. Audible alarms are a part of practically every system we deploy and I'm sure we're not the only ones who would be in the same situation. In Vision, you just select the Sound Data file to play from local storage and its easy. I realize Perspective is a completely different system, but some sort of feature parity between visualization modules would be nice.
I agree with that ideal, but the disparity you are focusing on is a fundamental difference between a true local application and a web-based application. The cut-down nature of cheap Edge licenses exacerbates your specific case, with Perspective.
FWIW, I don't think Perspective (with or without Workstation, with or without Edge) is a good choice for actual machine-control HMIs, mostly due to the difficulty securing based on local machine identity. Workstation might someday solve that, but probably won't ever support launching local executables--a common requirement when integrating multiple technologies in a single point of operation. This is just one more reason to think so.
{ Note: Edge with the compute plugin can play sounds independent of the UI, on suitable hardware. }
Maybe I'm overlooking something simple, but in what ways can you truly secure Vision based on machine identity? Plus isn't that part of the whole point of Perspective - to make it versatile in what machines can access it? Security should be done at the user level to prevent unauthorized connections and security zones can limit access from specific networks.
Within jython, access durable machine identifiers like MAC IDs (all of them), IP addresses behind NAT translation, and any unique material exposed by the OS (like Linux's virtual FS that exposes BIOS and motherboard serial numbers, and other unique computer build information).
From jython, call local external code that can perform hashing and signature and token operations with Trusted Platform devices, whether built-in, plugged in externally, or perhaps, plugged into a motherboard header.
Any of the above can be retrieved in a client startup script (supplied by the gateway), passed to the gateway to validate/compute permissions, and those permissions applied within the application in addition to any role-based or user-based privileges.
Assuring that machine direct controls occur at a physical location with suitable visibility into the machine is important to many operations. While true human safety controls need to be part of a properly designed circuit outside of HMIs, there are many operations that can damage or destroy a machine for which HMI enforcement is appropriate.
Geo-fencing is an attempt to provide such in a mobile environment, but coordinates used for that can be faked in mobile devices.
I know I started this thread and then took the route to add to the webapps folder. This worked and I moved on. Figured I'd deal with it later if it became a problem.
That said, I think the simple solution is to allow to load through the image management tool. Of course, I won't pretend to know the technical details to be able to do that.
