Ok, one more question. Going through the docs, I’m trying to find some kind of reference to paths so I can put the sound files somewhere I can reference with the source parameter. Any suggestion as to where to put those and how to reference?
Pssst! Try my free Blob Server Module.
I used the WebDev module to store my resources, and then I was able to supply a simple reference to the resource:
I recommend putting the files in the webapps directory, something like,
C:\Program Files\Inductive Automation\Ignition\webserver\webapps\main. Then in the component you can use a relative path, something like
Thank you. I put in the …/webserver/webapps/main folder, and this works great. Will have to check and make sure this survives an upgrade. Originally thought about putting in my custom theme folder but couldn’t figure out how to reference it there.
It will survive an upgrade. If you use redundancy, you will need to manually place in the other gateway.
Note that the
webserver/webapps hosting is deliberately undocumented and unsupported.
@PGriffith where would you recommend audio files reside then?
You proabbly wont have this problem,
But its hard to delete files from the webserver/webapps if the gateway is running, you can check out my solution (for windows) here.
One last thing I’ve noticed with the Audio component. When configured, I get this message in red in the Output Console quite often. It doesn’t appear to effect function, however. I’m using a .wav file.
Graphics2D from BufferedImage lacks BUFFERED_IMAGE hint
I would recommend using Webdev, Phil’s blob server module, a proper external host (e.g.
nginx could be configured as a reverse proxy + a static asset host, so external users would only see one IP + port, and nginx would transparently route incoming requests to either Ignition or serve static assets directly).
Building a lot of functionality on top of the webserver/webapps method is fragile for a few reasons. It’s convenient for a one-off, but not something I would want to rely on forever.
@PGriffith I should have been more clear, without using any other module and nothing external, what is the recommend location for these audio files?
There is none. Serving static assets is not an intentional feature of the core Ignition platform. You either need an additional module (Phil’s is free, iirc), or an external service (
nginx, Traefik, etc, all have free ‘core’ editions). Or you could write a module that hosts files using supported methods; there’s nothing stopping you from doing what Webdev does. I’m not saying “don’t use webapps” because I’m trying to upsell; I’m saying “don’t use webapps” because I think it’s a bad idea.
@PGriffith fair points, but for users on projects who don’t have the option to just install modules at will and have no access to anything external, there should be a supported method.
I don’t think so. Ignition is designed to be a modular system. New Modules are required to get new functionality. If I buy a computer and then a year later want to take pictures with said computer, I have to add a camera to get that functionality.
If customer wants feature B and it needs module or resource X, Y, or Z, then customer has to be willing to have X, Y, or Z installed on their system.
Modularity is not a bug in Ignition, its a design. It allows anyone to think up a great idea and implement it on a solid SCADA, MES, or HMI.
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.
Some requests indicate more abuse than relationship to follow. It’s rare, but I have declined such work more than once in the past 25 years.