Hello Ignition community.
My organization is need of a test strategy for our medical device manufacturing application. In the past we have performed a rigorous, Use Case to Requirement to Test Case formula. This has proven too tedious for the level of automation we are currently at.
Envision an architecture similar to this one, taken from Inductive University as a reasonable simplification to start the discussion:
Some notes from our team on thought process:
• The problem is how to test the Ignition Gateway which manages data flow, not so much the HMI even though they’re closely related.
• Manufacturing Cells (with PLCs) talk to the Ignition Gateway, which talks to a part tracking database to find out what the state of the part is when it enters or leaves.
• The architecture is the Manufacturing Cell changes some tags and the Ignition Gateway uses that tag data to make DB calls via procs.
• It would be nice to test the Ignition Gateway directly without needing all the cells & DBs - could it be done?
• Manufacturing Cells talk to the Ignition Gateway which talks to the part tracking database to find out what the state of the part is when it enters or leaves.
• There is a need work out how to make sure the Ignition Gateway captures the right data from the Manufacturing Cell and makes the right SQL calls without requiring all the Cells and DB.
• Creating a test framework might be more trouble than it’s worth.
I have brainstormed a few strategies but am somewhat new to Ignition. Our external system integration organization is the system supplier but validating the system is incumbent upon us internally.
• Option 1: The feasibility of sending raw TCP/IP commands to the Ignition Line Control Hub would depend on whether they provide a command set, if there’s restrictive timing involved, etc. But of course there are many ways to send TCP/IP commands if the answers to the previous questions come out favorably – I’m from the LabVIEW world and it’s one option of many.
• Option 2: If not, using an RT controller (including the possibility of a single instance of the PLC used in the production system itself, with similar software) programmed in a manner to represent the rest of the production system “behind” it is the thinking for the other option (the “HIL” option)….
Expertise is greatly appreciated!
Ignition gives you 2h trial resettable and there a lot of things you can test and try. As user and independent designer I highly recommend you to test it step by step for your needs, surely you will realize Ignition is a great option for all you said. You should create a test environment and for example use third party software as wireshark to see how data it’s been managed. For deeper solutions and advices, you should consider contact a company for Engineering based on Ignition because remember this is a forum open for the community and expertise is a scare resource.
I’m starting to see that expertise is a scarce resource indeed…
Does Inductive Automation not have applications engineers that contribute to these forums? As a comparison, National Instruments AE’s answer posts if the community does not, at least last I was aware. This would be an improvement to the Ignition community…
You can talk to your account rep about getting some time with a sales engineer.
Exactly, I mean this a open community source.
And expertise shouldn’t be looked up here. Instead,
And you won’t be disappointed.
if “expertise shouldn’t be looked up here,” what is the point of a forum?
you are not in a position to assure that I “won’t be disappointed.”
Please only post value-added input, otherwise you’re damaging the value of the forum.
This forum is an “official” venue (it’s hosted on our website, after all) but is not an official support resource. There are many contributors from IA, including development, QA, support, and, yes, sales engineering. Those people all do their regular jobs as well; there’s no guarantee that you’ll get a response on this forum, because there isn’t; that’s just not a thing that we provide on this forum.
This forum is best suited for specific technical problems, by nature of the contributors here. General architecture questions are also perfectly fine here, but you’re limited to the expertise of the people with time to contribute. I can answer technical questions all day long, but I’ve set up exactly 0 production Ignition systems - so I only have general advice to offer.
Meanwhile, our sales engineering team has two veterans at the head with decades of experience setting up real, actual Ignition systems, and a dedicated team of incredibly smart people directly working with them. I can assure that they won’t disappoint - and they’re really the people who you should talk to.
You’re being oddly combative about this whole thing - you posted early afternoon on a Friday, then seemed to expect feedback first thing in the morning on Monday. That’s a reasonable expectation for an official support venue, sure - but, again, this forum isn’t one, and doesn’t claim to be.
you catch more flies with honey than you do with vinegar!
Not at all combative; just looking for quality input
Our team evaluated both options (RT hardware based / HIL, and “software only” on a PC).
Current thinking is to use LabVIEW with the OPC UA toolkit (correction, it is not a module) on a PC and do it “software only.”
I post this for the benefit of other medical industry engineers who may in the future have similar questions. If I stay in involved in the project further I’ll post an occasional update.