FrameworX v10 Launch

Watch the Presentation

In this webinar, we explored some of the key features of FrameworX Version 10.

FrameworX Version 10 features a refreshed Solutions Designer for faster, more intuitive navigation, and with technology upgrades like .NET 8 and WebAssembly, the platform is even more open, cross-platform, and delivers high-performing graphics. 

Q&A

We already have customers running v10 in production, so absolutely!

Running without a runtime license, the system operates for 2 hours and can be restarted after that time.

Yes, we manage installations of those versions separately!

Yes, we have a specific Upgrade button to use in the new version. You can learn more about that in our documentation.

We’ll automatically migrate the solution, although obviously some of the new technology we’re using might affect your solution, so make sure to verify.

Absolutely! Our Documentation has been completely redone – we also have two training courses published at training.tatsoft.com around v10 (Overview and the Brewery Tutorial). We’re currently working on content around some advanced features and around specific applications. If you have something you’d like to see, please let us know: https://tatsoft.com/feedback

Yes, you can learn more about our Extension APIs at our documentation.

Version 10 runs on Windows with .NetFramework 4.8 or .Net8 for Windows or other operating systems. The hardware requirements will depend on the size of the project and whether .Net8 is supported, but version 10 has significant improvements in memory and CPU consumption. For example, we have a hardware setup with only 800MB running 4k communication points, reading from ControlLogix, and publishing MQTTspB to an MQTT Broker, consuming less than half the memory and with plenty of processing power to spare.
Each license has a limit on the number of clients that can be connected, including mobile devices. RDS is not required as long as the mobile device has access to the network where the server is located.

The Store & Forward can be configured for the historian module or for the MQTTspB protocol, publishing data to an MQTT Broker, regardless of whether it is running on Windows or Linux and which product family is being used. However, high performance depends on the hardware capabilities, such as disk, network, etc. As long as the hardware can handle it, the software is optimized to work in blocks and within the standards of the protocol or database provider.

Internally, they are equivalent, and there is a virtual entity equivalent for the TagProviders. From a communication standpoint, there is no configuration to define blocks, access types, etc. Therefore, in some cases, it may be necessary to use traditional Tags and communication without TagProviders to achieve more optimized, customized communication. However, the TagProvider only communicates with the Source if the external Tag is in use on a screen, in a script, or somewhere else. Otherwise, it is removed from communication, which should ensure good performance in most cases.
For now, you can export your project as text files, so that I can publish it on Git and compare versions, but deeper integration with Git is planned in the roadmap for future versions.
You only need to create a template to be published to MQTT when you are using SparkplugB protocol, once this protocol requires the messages to have a structure. If you want to publish single data, you can always use the regular MQTT protocol, once this one is the opposite, requiring data to be published individually

Yes, you can log the data using the Historian module, then use the method @Client.Context.SetDisplayValueToHistorian(DateTime selectedTime) to open a display where the DisplayValue of the Tags will show the HistorianValue of the selected time, instead of the current value. The example EstimativeValue shows a similar operation to show calculated values

Yes, it is possible to publish the entire UNS or part of it via MQTT. When using the built-in broker, there is a checkbox configuration to automatically make all the tags in the solution visible to the broker. You can more about this configuration at our documentation.

There is now a WebData report for publishing JSON and accessing Web Services. This is the most significant new addition in the modifications to the report.
It is on the product roadmap to implement SVG file import soon.

Debugging can only occur if the runtime is running, as debugging pertains to what is executing. Therefore, code debugging is only available when attached to the runtime.

Let's Continue the Conversation