Every SCADA professional, from veterans to beginners, has a DREAM SCADA in their mind. Do you have any such dream or desirable feature or wish list for Ignition?. If so, please share it here.
My wish:
Ignition must release a full fledged MQTT-JSON client module which can PubSub the full internal Tag database including Alarms and properties as JSON payload on MQTT. This will open up the gateway for a large number of developers to build their own multiplatform clients especially on mobile platform. Let every one unleash their imagination and passion, and build their own DREAM SCADA client.
IMO, this forum is more open for the public, SEO optimized and doesn't require an account for a casual visitor to browse the topic and discussions. It can easily pop up during a google search and can attract a larger audience to debate and share their views.
It seems to me astonishingly rude and arrogant to advocate knowingly breaking the rules and netiquette of a free-to-use website, in general, and unprofessional to do so in a commercial setting. A professional would create an entry in the ideas portal suggesting it be made more open. You can link into the portal from here.
Any idea which is put open for a public debate, attracts larger participation and helps the decision makers to weigh the pros and cons better. I strongly believe that any worthy idea, will eventually gain momentum and knows how to reach the right destination on it's own.
Think of this scenario:
SCADA community is always looking for better solutions and searches the internet to find one. An idea discussed in a open forum like this may get a hit in his search, may attract him to this site which in turn may trigger his curiosity to dig deeper. There's a greater chance that he may find something much better offered by Ignition than whatever he was looking for. This process may convert a casual visitor into a potential client. I think this is what eventually matters for Ignition.
Not sure how long you have been here, but what you describe was in place before Inductive moved to the new system. They obviously moved it to the new system for a reason. You should respect their wishes if you want to be a contributor to the forum. I also see you continually hawking other software’s which are directly competitive to Inductive, which IMHO is very disrespectful to Inductive. There are many forums out there to discuss Automation products as a whole, but IMHO, discussing competing products on this forum is very disrespectful to Inductive. Inductive is nice enough to have a community where anyone can sign up and have a voice, and in many cases direct contact, with high level Inductive support and development staff. If people disrespect and abuse the system, they may decide to swap to a system like many other Automation companies, where you have to pay to be a part of the forum or no forum at all.
Cirrus-Link already provides a module that can accomplish what you need. The protobuffer definition of the sparkplug payload is widely available, so i do not buy that JSON is needed, unless you want to increase the payload size exponentially.
Also, with 8 around the corner, I doubt any sane person would consider building a stand alone client, it would be such a small subset of capabilities that it would be a waste of time.
I 100% reject this statement. I found Ignition as a SCADA which provided a platform to fulfil my dream. I have worked on all top 3 SCADAs and found Ignition outperforms them convincingly. Till date, i could not find a better one. This is the reason i posted the following topic.
This topic has attracted a large number of visitors, especially from the Indian subcontinent. Competition is inevitable. A product which is closed for public debate and criticism will not survive in the long run. Criticism helps innovation and helps a product to get better. Fear breeds secrecy, builds a ring of sycophants and kills innovation.
I agree that i have posted certain outlandish ideas like USD 99/- annual subscription and so on. But the net result is, these topics have generated a very interesting debate and has helped Ignition to spread.
Many a great products which closed their ears and did NOT listen to the public opinion have disappeared from the market. Nokia is one classic example which thought nothing can shake them. When Android hit the market, Nokia disappeared from the sales counters over night. Ubuntu kicked the invincible Windows very hard and has forced mighty Microsoft to release a free W10.
Let's NOT make a holy cow out of Ignition. If some one offers a better SCADA than Ignition, almost every Ignition evangelist here will jump the ship like they did before with other vendors. Loyalty is a cruel joke in business and politics.
I have a lot of admiration for Cirrus-Link. They know MQTT better than many others. I wish, Cirrus-Link releases an MQTT-JSON client module for Ignition before some one else captures this golden opportunity.
What's wrong in building a client which can handle bigger payload better?. Let the end user decide whether he wants a bigger or smaller payload for his application.
Can you imagine what kind of client another human wants to build for his business?. It's impossible for any human to innovate every possibility and fulfil the dream of others. It's better to provide a play ground for them to build whatever they want and let fulfil their own dreams.
I guess scope of a SCADA software is fairly well defined, to be able to monitor and control a plant. It was a replacement of control panel based plant control of previous generation which resulted in a huge saving in cost of instrumentation and it facilitated additional functionality like historization of data (which was done in strip chart recorders) and alarms (which was done using SOE recorders). SCADA is at a plant floor layer not at MIS or business layer so its unlikely that anyone would like to build a business application or e-commerce site or do stock trading or an ERP or MRP on a SCADA system! Even MES is a layer between plant floor and MIS or ERP/MRP which is a separate application on top of SCADA.
I guess its enough to provide responsive screens which scales on any device and some dash boards and tables and buttons for control is enough for a SCADA client or HMI. Other things are in scope of other level software and its better to have well defined boundaries or else we would just try to solve an imaginary or non existent problem!
What golden opportunity? The Cirrus-Link modules can publish data to a broker for your application to ocnsume.
Why would you ever want a larger payload? I can't think of anything I have ever built where I thought to myself "I know I can fit all my data in 50 KB space, but it would be better for the application if it took 50 MB to move the same information"
I was merely referring to your desire to build an HTML based client. It is already coming. Again, the data is already pushed to the broker in an open way, it adheres to the sparkplug spec, which is incubated by Eclipse (I think). I do not see a need to using JSON.
I felt a need of leveraging the AR and Virtual Tours technology in SCADA which was not possible earlier which could give an operator a new interface with physical identity of plant (some thing like PCB image v/s schematic diagram of an electronic circuit, both are important from understanding and operation perspective of plant). GCM is to fetch data for displaying real time parameters on virtual tours, without it it would be just an offline tool for O&M personnel. NJSCADA was required to serve AR pages on its clients.
Then pursue away! Implement your dreams with Ignition and post the working modules here! If you want IA to do it for you because you lack the skill or will to do it yourself, you need to post your idea on IA's ideas portal. "Pursuing whatever you want" doesn't mean doing it on somebody else's property (this forum), time, or dime.
I dont think you are understanding what I am saying. The Cirrus-Link module serializes the data into a gzipped protobuffer. Compared to JSON, the amount of data moving across the wire is far less using this approach, as opposed to JSON or XML. In a test, I could move the same amount of tag history data using 100x less data by using gzipped protobuffers as opposed to XML and JSON. There is no limit to the size of the payload, so your point it moot. Either way, I still do not see a need for JSON.
JSON is a well established standard and it complies with my client's eco-system of multiple vendors and consumers. I do not know anything about gzipped protobuffer and do not have the time and energy to convince everyone to switch over to gzipped protobuffer.
I want to reach a larger audience, show them how different solutions and ideas are possible with Ignition and help spread Ignition. You have the freedom to accept or reject my ideas.
Honestly, if i win my dream project, i will definitely contact IA and will negotiate to appoint them as project consultants. I have already made up my mind on this. May be i will contact Mr.Kyle_Chase also because i feel he is very honest in his views, gentleman and a good businessman.
Makes sense in an existing architecture. You would have to build a module that does essentially what the Transmission module does, or contact Cirrus-Link and see if they could add that to their module.
However, if they are not using MQTT with JSON right now, but merely, using JSON in general, you could pretty easily in Ignition build a REST endpoint that could bridge for you.