Introducing Flintium! An open source library of Ignition faceplates

Ignition
,
21

I’m Grabbing what is needed to get a FULL 100% Functionalty like PlantPAX has? Dont know if you are Familiar with this DCS System and how Tag Consuming it is?.
But i Know that Hidden Members Etc. in the AOI can cause problems :slight_smile:

But Maybe the Flintum Library is To much for Ignition Gateway to Handle a big Process Plant Using only Rockwell AOI with no Changes or Re-programming of them, that intended to or hoped for.

But Me and my Programmer have just got an Idea of how to use a UDT, instead of Reading Directly to and inside the AOI.
So I will re-program and test this during the weekend. :slight_smile:

22

Wild guess that it isn't Flintium that is the issue here.

Also, I would highly recommend, not using Studio 5000 on your gateway server. Not only does this mean that you have Studio running, but you most likely also have RS Linx, FactoryTalk Activation, and FactoryTalk Directory.

I would not do any designing, PLC or Ignition, on the Gateway server.

2 Likes
23

That 's also just a wide Guess :slight_smile:

Also, If no one has Actually Used 100%The Flintum Library for a Big Project and Implemented it, then it is also hard to say if this will actually Work I the Real World?
Thats Why i Came Across here to see if anyone has actually used and done a Commisioning with a Complete SCADA Build Upon Flintum and Rockwell AOI, and facing the same problems i’m Currently seeing.
The Problem is just the Communication gets Chocked, and I know Rockwell use Some Optimizing From AOI to SCADA Faceplates in the Communication.

We Have also Tried to setup a KepServer aswell for this, Same problem.

So you Would Recommend me to spend money on a Computer/Server only for the Gateway, and then have a Second Server as a Development Enviroment? :slight_smile:

24

No, create UDTs as suggested. A lot of us have seen the issues with reading tags from AOIs, and most of us have switched to using UDTs. It resolved the issues you are seeing.

1 Like
25

Yes, purpose built UDTs that contain only externally accessible tags that will be used by the HMI and sampled at the same rate can go a long way.

2 Likes
26

Okay, Thanks for all The suggestions :slight_smile:

Kind of what i’m planning to do This weekend to see if it helps solve the Problem. But seems like your right, so fingers crossed.

27

Kevin,

What are your thoughts about This idea.

  1. Create a UDT - example. P_ain

  2. Inside AOI, create an in/out Tag as that UDT P_ain

  3. Change code inside AOI, to write/read all the needed information we we want to have/Exchange and control, into the Newly created tag/UDT.

  4. Create locally Defined as the, P_ain, only used for HMI monitoring and control, and link that to the new input/output of the AOI?

If it make sense?

Thanks in advance :slight_smile:

28

I think you are describing what is discussed in this thread, yeah?

2 Likes
29

Yeah, it actually sounds quit similar to what I was Thinking. Hopefully it Will help solve the issue.

Thanks for help and suggestions, appreciate that.

30

Also, use Ignition’s UDTs, then all you have to do is pass the basetag and everything just works.

2 Likes
31

Hey @Rasmus_Petterson, thanks for kicking off a great discussion here!

To answer your question - Flintium has not been used for a large project. The tag issue needs to be resolved before I can recommend it for a large project.

Just a comment regarding the PlantPAX tag bloat-
PlantPAX AOIs are amazingly configurable. They can accomodate a ton of different scenarios without modifing their extremely well tested AOIs, and it can all be done through an HMI. It also comes with fantastic documentation. If those factors are not a huge benefit for your project, then you should really use a different solution.

That configurability comes with a huge amount of tags. However, the majority of those are only needed on very rare occasions. We’ve discussed a few solutions to the tag problem-

  1. Use tag groups so the seldom-used tags only update occasionally. That was our first approach, and what is currently implemented, though it was never optimized. See Flintium/gw-resources/tags/tag-groups at master · jlbcontrols/Flintium · GitHub
  2. Drop the seldom-used tags, and just use system.opc.readValues and writeValues for them as-needed.
  3. Add UDTs on the PLC side instead of reading AOIs. This will give us a huge performance boost, but requires PLC side work to migrate an existing PlantPAX project.

It sounds like you’re interested in pursuing #3, which is a great option. If there’s anything I can do to support, please let me know! And feel free to get the discussion going at Issues · jlbcontrols/Flintium · GitHub. There are a number of folks willing to help, but we could really use some fresh determination to solve the tag problem and make it viable for large projects.

32

For maximum performance, make all instances of P_ain part of an array. Ignition will be able to go even faster.

33

So does that mean on your systems - on the Ignition side you tie to P_ain[0] and not to a specific tag name.

How do you manage to keep the documentation that P_ain[356] is tied to PIT_100

I know with my Datatypes in Ignition I have 3 parameters (id, Topic, tagGroup) So the Ignition tag can be descriptive and then the id = P_ain[356], Topic = PLC1 , tagGroup = Analog would create the binding path to the PLC.

I just think it be hard to maintain that cross-reference - IMO - but probably worth the hassle to gain in bandwidth.

34

Make a UDT that has parameters for the root OPC item of the AOI and subscripts for the InOut parameters in their unified arrays. Effectively documented in one point.

35

Phil- Thanks for the info but not really visualizing the structure.

So you would have a udt that has an extra item that would be the opc item i.e. tagName?

36

No, UDT parameters. A parameter points to the OPC item path of the AOI instance tag. For each InOut parameter of the Ignition UDT that points at a particular element of a global array of the InOut datatype, include an Ignition UDT parameter that is the corresponding subscript of that global array. That enables tags within Ignition’s UDT to construct the inner OPC item paths to any element. Documented at the Ignition UDT instance by the parameter values.

2 Likes
37

Hi @joseph.burns, congrats for the good work. We have some experience using PlantPAx in our platform (FactoryCompass) over Ignition, so far it has been tested with 113.000 tags. Our solution was use direct tag group for the objects and leased tag group for the faceplates. That way no modification on the PAC libraries is needed.
But you now, we can always go faster.

image
image1920×1039 183 KB

38

Looks great Ivan! Roughly how many process objects (motors, valves, pids, etc) does that correspond to on your system?

39

We have manage to implement approximately 200 devices, including motors, drives, DI, DO, AI, dosing, etc.

40

Hi @Ivan_H ,
I like the idea of using Leased Tags for faceplates.
What is the best and quickest way to get the list of tags used for faceplates?