Ignition V8 release

I am seeing the same the thing as you when I try to load the demo webpage.

Loads okay for me in Chrome right now.

I’ve not had any issue, aside from perhaps the first hours after it was announced, that was almost certainly due to the fact that 700-800 people were congesting the wifi and cell towers at ICC.

edit:
Also, keep in mind this is early preview software. We’re proud of the work we’ve done, but we’re just getting started. Between now and release, we’re going to be doing a lot of development focused on improving speed, stability and reliability. This demo project is for us just as much as you in that regard.

Also, as we get closer to release we’ll be providing more information regarding supported devices and browsers.

What browser are you running?

1 Like

I mean between fetching tags in a Siemens like system where tags have an explicit memory address and in a Rockwell Logix v20+ where tags are only named. The difference of time responsiveness for the same amount of tag is big.
At least for the cases I have seen.

Ok. This doesn’t have anything to do with the tag system, unfortunately.

The PLC is almost always the limiting factor in responsiveness.

3 posts were split to a new topic: Issues loading demo Perspective project

Does this affect how we program UDTs / Templates right now. We have a big project we will just developing in Decemeber that will use all UDT / Template with passing indirect to the templates. Will it still be best practice to do it this way or will we be able to tie the UDT to the Template and utilize drag and drop for the graphics?

None of the changes should really change how you should develop the types or templates. The drag/drop support will continue to be what it currently is- any template that has a complex type as a drop target will show up as you drag those types (or sub types) on the screen.

Perhaps you were asking about binding performance, in that the “best practice” was to not use complex type properties, but instead use indirect binding for each individual tag deep in the component. That situation was caused by how complex bindings worked- they created subscriptions to everything under the type, even if you weren’t using them. This definitely will be improved, but is still not totally perfect- it still subscribes to the full type. However, instead of creating individual subscriptions, it can subscription to the top level tag and get all values in one update. So, still more data than it needs, but should be much quickly/lighter than before.

1 Like

Thanks, Colby -

Yes, I was asking about the binding performance using UDTs - as our UDTs have a lot of properties. You answered my question we will continue with not using the drop target for the whole UDT in our templates.

Hi @Colby.Clegg, is there any improvements in tags and udt V8.0 such as :

  • eu, min, max,… bindable to other property
  • new fields for doc or JSON fields
  • enum of value for integer datatype
  • multiple history destination
  • redundant source for opc tag
1 Like

Ok. This doesn't have anything to do with the tag system, unfortunately.

The PLC is almost always the limiting factor in responsiveness.

Hummmm... I don't want to extend that OT discussion but I'm interested. Which documentation should I read to understand those performance? And to understand when PLC is a limiting factor?

Some of the drivers have status/diagnostics pages that give insight into the response times from the PLC.

Your original question wasn’t even a fair comparison - the protocol used by Logix PLCs and the one used by Siemens PLCs is entirely different. One doesn’t have anything to do with the other, and neither have anything to do with the Ignition tag system.

With V8 Ignition Perspective is a new module. Will there be a migration path for Vision module screens into the new Perspective module?

No. Vision continues to work and be supported.

Developing Perspective screens is quite different than Vision and there is unlikely to be any kind of automatic conversion process that even makes sense (at least for the 8.0 release).

2 Likes

does it support graphics in addition to REACT components? If yes then which one (SVG/Canvas…), and is there a graphic editor supported?

I know it supports SVG for sure.

1 Like

There are improvements that do affect most of those things, and some ideas that didn’t make it for 8.0 (but might for 8.1).

  1. First, you didn’t ask, but I’ll mention: custom properties on tags. This will be totally possible, though right now is not present for 8.0. It may still make it, but probably will be in 8.1.
  2. In general, the idea of properties being “bindable”- to reduce complexity, we do not plan on them being bindable to other tags or properties. HOWEVER, they are bindable to UDT parameters, and UDT parameters can now be written to directly. Furthermore, we have the idea that perhaps we will let parameters be bound to other tags and such, though we haven’t decided to put that in 8. So to be clear: in 8, you can now bind ANY property to a parameter, which wasn’t possible in 7.
  3. There is not direct support for redundant opc, but that is where the idea of bindable parameters came from. You could have the OPC server be bound to a parameter, and have the value of that parameter be a calculation based on information about the current server. Again, for 8.0, you would likely need to manage this from a script that then writes to the parameter value of the data type, but at least it’s more possible than it is in 7.
  4. There is indeed a new data type for Document, that can easily go to and from JSON.
  5. Multiple history stores on tags is an idea that we thought of, and can fairly easily add (and may), but is not currently in place.

Thanks for the questions!

4 Likes

Thanks a lot @Colby.Clegg for these clarification. All the tag’s properties bindable to udt parameters will be an amazing enhancement. That’s indeed what we need! With a JSON datatype added… To store and retrieve extra information… Perfect.
For the redundant opc source for a tag, an opc server name bindable is a good start of solution, but for a true hot standby with a source failover with the minimum time, the only solution is to read data on both opc sources simultaneously and select one or the other depending on the quality or a keepalive criteria… I Hope it could be possible in the future…
Impatient to test a beta!

I wonder how much of such complex data structures, dynamic property binding, nested json objects in tag properties etc will be used by a normal SCADA applications, though they will certainly add a lot of flexibility in address space definition and add dynamic features, if Ignition can easily implement them. Some kind of prioritization may be required based on their practical use cases and importance based on user feed back.

General parameter bindings are just a continuation of what we’ve had, so that will be used a lot. The fact that you can write to them and have the changes propagate immediately is nice, but I don’t believe will or should be commonly used (our general philosophy before was that parameters were a design time setting, and shouldn’t be dynamic… but certainly there are decent edge use cases). Dynamic bindings on parameters would be even further in this direction. I do think it could be useful, but I’m always nervous about making it too hard for someone to come in and understand how the data flows.

@mazeyrat You’re right, and what you’re describing is currently what I’d like to do on an entire tag provider level, not just OPC- it’s what gets thrown around as the concept of “federated tag providers”. A provider that combines other tag providers, and then merges them together and selects the best quality data source on a fine grained level at any time. I don’t have a timeline yet, but I know more than a few people would have liked it “yesterday”.