What? You haven't tried the Morning Coffee module from ACME software? You will never make coffee the hard way again.
Seriously though, that's another great benefit that I don't think has been mentioned here yet - the availability of a growing selection of 3rd party modules. We not only have the gurus at IA developing for us, we have many other brilliant folks as well...and a lot of them hang out here on the forum.
Hey, when we're feeling bored, at least we can still use our skills to solve the occasional Microsoft Office problem, but I can't imagine going back to Visual Basic HMIs.
That's very similar to something @pturmel helped me out with here, Recursively Iterate Through Components. Notice how neat and tidy it is in Ignition/Python.
I feel the same way. I've written a TON of VBA but it's an obsolete language that is prone to memory leaks when people who don't know the language try to write it.
It’s prone to memory leaks when people who do know the language write it.
Can you link to a post about this? I feel like I know the basics of Ignition pretty well, but this sounds intriguing.
TypeScript. End of.
How did the admin respond?
If I understand it right, you sent:
A summary
A video introduction
A kind of disclaimer, not sure how to term
Popularity and reasons for that
Alternatives and their faults
I am interested in the response you got back.
When I recommend things, I try to express the ROI.
Cost would be X in dollars.
Return would be Y in dollars.
Time will be Z in years.
Then I never hear back though.
I see companies spend like 300 million on something they already do.
So I wonder how the response was that you got.
I don't know if there are any specific topics on this with good examples. I've developed my own tools though in python that help with bulk exporting and importing tags and/or tag prop values
If you're referring to bulk editing tags, you can just export as .json and use Visual Studio Code to open and then find/replace anything
Find/replace can only get you so far though and without much granularity. For example, say you wanted to audit all of your engineering ranges of tags, and reconfigure them if required. You would want to produce a list of tagPaths and their engineering low/highs and maybe the eng units into Excel, then process the list either manually or semi-auto, then write any changes back to the tags
LOL. That was EXACTLY the response I got.
It would be great to express things like this in terms of ROI, but that is something I am terrible at. I am an engineer by nature, disposition, and education. I cannot bring myself to "make facts up". I can't quantify the greater productivity we have in our mill because of Ignition, but no one at this local operation would dispute that it is invaluable. (And by the way, this operation is consistently at the top of the company in terms of ROI over all). Ignition makes us so much more efficient in so many of the things that we do but I have no idea how to quantify that. I am very fortunate that we recently got a new regional VP that is very forward thinking and trusts the judgement of local operations to decide what makes them productive. He has been invaluable in helping us overcome the obstacles that IT/OT security has erected and also supporting local mill managers if they want to purchase an Ignition system.
This has already happened a couple of times at my company. We have bought very expensive solutions that were a poor fit for our needs from huge companies with the inertia of a planet because some higher level manager in our company, well, wanted to. The companies that develop these gargantuan solutions are slow to add the features we request if they add them at all. On the other hand, users of my Ignition apps just send me an email, maybe with a screen shot, and ask "Hey Clint. Can you ....?" They usually get what they want in a couple of days (depending on my workload).
A very common argument is that "Ignition is weird and Clint is the only guy in the whole company that can develop in it. What happens if he gets hit by a bus?" I have attempted on several occasions to get local operations with Ignition needs to use a systems integrator even if it is something that I can do myself just to prove that Ignition is very common and I am not the only guy in the world that work with it, but I have never been successful. I even approached @pturmel myself on behalf of some of our southern operations, but they preferred to keep their head in the sand and just do away with the Ignition they had. @samuraimarc is now back on board and doing his thing down south and there are now a couple more Ignition fans in the house, but overall we lack the clout to influence company wide decisions.
Sounds like it may be good to provide them links to all the free learning resources like Inductive University. From my experience, no other SCADA system comes close in that regard.
From an integrator's perspective, it took me a good year and a half to convince my project manager to consider using Ignition for a project some 8-9 years ago. I hadn't used it before, but what I saw from the demos, the community, and having a play around in the designer was far better than everything else I had used. I finally got to do a freebie project for a customer to replicate a small part of their plant in it as a trial. This was my chance to prove to myself and to everyone else that it's a viable product. If I looked back at the project now, I would be horrified, but let's just say that it turned into a solid 7+ years and counting of expansion development, and obviously completely replaced their existing SCADA. From there, it's grown massively throughout the company I work for, and we've been premier integrators now for several years
I got the same thing. Almost verbatim. I told them "Then it will still work. The 'Ignition stuff' is not the weak link in the chain.
For context, this is an excerpt with an earlier converstaion I had with @cbanzet.
We are moving to Plex as our ERP system. Recently bought by Rockwell. There was a big push to replace evrything Ignition with Mach2, which is Plex's front-end app. So far I've come across a few things Mach2 / Kepserver can't do.
- Connect to a PostgreSQL database
- Kepserver cannot use 'Advanced Routing' on the 5380 Compactlogix, even thogh the 5380s support it. There is also nothing on their roadmap for it.
- There is no way to buffer serialized / traceable production out of the box. After the Plex guys stated it would take a few months to do that, I wrote a common interface for Mach2 to use through Ignition. In an afternoon.
- Mach2 is all function block programming. There is not the same flexibility that you would have with Ignition.
After I stated that Ignition is our SCADA system, and that it was only doing MES operations because of the last 'Rockwell provided solution' from my 2012 post. They have (so far) left it alone.
Who knows, I may come to like Mach2 well enough, but for all things SCADA, I'm sticking with Ignition.
I used to work for a vendor and I saw that comment before of if someone is hit by a bus.
The answer was always, we have a network of developers and a website to find the nearest or just call.
For ROI, in this case I think Ignition has a set price and competition has an annual price.
I can produce numbers. I can't seem to get responses haha.
Edit: If there is a consequence that I had not considered to an idea I had, I hear back a response.
I think when it is a good idea that then I don't hear back.
I've been waiting to see if anyone chimes in on this comment I made. Am I the only who thinks that Rockwell's current solutions are ridiculously complex?
This is coming from a guy whose first serious exposure to automation was as a PLC specialist for a Rockwell (then Allen-Bradley) distributor. I was there when ControlLogix was released before there were even processors available for it...at first it was just a communication gateway. I owe my entire career to the exposure to automation technology I got then. I maintained good relationships with my Rockwell sources even after I left that job and I became the "Rockwell guy" at the systems integrator I went to work for next. I can go on, but suffice it to say that if anyone has a reason to support a Rockwell solution, it's me. Today, I could not in clear conscience recommend anything with FactoryTalk View in the name for any purpose. I have even switched to Automation Direct C-More EOI's for local machine-based visualization instead of PanelViews, which has earned me the ridicule of my peers in my company. But I would do anything to avoid the the FactoryTalk View development environment (and have told my Rockwell distributor as much).
You sound just like me, and not just on this snippet.
Sounds like you're in a somewhat similar situation to what I have at my company. IT is emphasizing security and that is what gave me the biggest justification to switch HMI's from iFix and FTView SE to Ignition. Quote from our IT CyberSecurity Leads when we asked if we could play with running Ignition clients on Raspberry Pi: "We'd love it if you switched from Windows to Linux." Oh really? I now have an Ignition gateway on headless Ubuntu v22.04 server and my Vision clients are on Ubuntu Desktop. Ignition on Ubuntu is starting to spread to other locations with the younger engineers jumping on Perspective, me being older and rebellious so I use Vision and the older "stuck in their ways" engineers stuck in iFix and vba and have no desire to change or learn anything new.
My original 2012 post, for posterity.