8.3 Transformation performance in Vision client

Ignition
,
1

Hello,

I recently upgraded an Ignition 8.1 project to version 8.3.0 to evaluate the impact on functionality and identify any necessary changes. Overall, the migration process was straightforward and didn’t require much effort the documentation was clear and helpful.

That said, I’ve come across a couple of things I wanted to ask about:
First, regarding deprecated scripting functions: in the migration reference, it’s noted that system.db.runPrepQuery is deprecated in Vision with no replacement listed (what should I use now?), and that system.db.execSProcCall is replaced by system.db.storedProcedure.

However, I noticed that system.db.storedProcedure doesn’t show up in autocomplete, and system.db.execSProcCall isn’t marked as deprecated in the script editor.

Are these known inconsistencies, or is this something that still needs to be updated?

Here the warning symbol clearly states “deprecated function only for retro compability”

image
image692×220 30.6 KB

Second, I’ve run into performance issues with system.gui.transform (now system.vision.transform). While the function parameters appear unchanged and the animation logic still runs, the actual animation performance in the Vision Client is extremely poor, either very slow or not rendering properly. Interestingly, running the animation in the Designer preview shows noticeably better animation fluidity. I also tried running it with and without the async parameter, but it didn’t seem to impact performance.

The script used for the transformation:

def action():
    component = event.source.parent.parent
    system.vision.transform(
        component,
        component.location().x-50,
        25,
        duration=300,
        acceleration=system.vision.ACCL_FAST_TO_SLOW
    )
    event.source.parent.parent.parent.doAction('edit')
    
system.util.invokeAsynchronous(action)

I’m wondering if these are known issues in 8.3, or if there’s something on my end that might be contributing to them.

Thanks in advance for any insights you can share.

2

Use a named query. Or use system.util.sendRequest() to delegate to a gateway scope script. The intent is to not pass raw SQL over an RPC connection, just values. This allows you to not turn on the Legacy DB permission in your project, which is a significant security hole.

2 Likes
3

In 8.3:

  • The non-"prep" variants of direct SQL query functions (runQuery, runScalarQuery, runUpdateQuery) are deprecated in all scopes, because they're strictly worse than the prep variants - there's literally no reason to use them.

  • The runNamedQuery and runSFNamedQuery functions are deprecated in all scopes because:

    1. It had a fundamental signature incompatibility between client and gateway scope with the project parameter
    2. The idea of a single named query function issuing any kind of query (query, scalar, or update) was misleading at best.

    The recommended replacements are system.db.execQuery, execUpdate, execScalar, and execUpdateAsync.

  • asdf

You should use named queries, or if you need more dynamic SQL, you should send a message using system.util.sendMessage and invoke a message handler on the gateway that runs system.db.runPrepQuery. There's a fundamental security issue with running 'raw' DB queries from Vision, hence why it's been gated behind the 'Legacy Database Access' permission in your project properties since Ignition 7.9.4.

This part of the 8.1 to 8.3 upgrade guide, which I'm assuming is where you're seeing that:

System Function Deprecated Replacement System Function
system.db.beginTransaction No system.db.transaction
system.db.beginNamedQueryTransaction No system.db.transaction
system.db.closeTransaction No system.db.transaction
system.db.commitTransaction No system.db.transaction
system.db.rollbackTransaction No system.db.transaction
system.db.createSProcCall No system.db.storedProcedure
system.db.execSProcCall No system.db.storedProcedure

Is just wrong - we haven't yet introduced these new functions, so they shouldn't be in the migration guide. No matter when they are, since 8.3.0 is already out the existing functions to manage transactions/stored procedures will not be deprecated until our next major release.

All that said - as ever, just because a function is deprecated does not mean it is going to break, now or in the immediate future. With literally one exception in the last decade, we do not remove scripting functions after they've been added. Eventually they may functionally stop doing anything (e.g. the system.alert functions, originally deprecated in 7.6 / 2013, stopped doing anything in 8.3), but they will not be removed, and in the unlikely event we can't provide equivalent functionality automatically, it will be clearly marked in the upgrade guide.

With 8.3, this situation actually got more clear for you as an end user - previously, we could only show or hide functions entirely, with no ability to "soft" deprecate them. The plan is to use this new capability to stage deprecations for the duration of an entire major release, and only hide them in the next major release.
8.3 also has a larger than usual swathe of deprecations because of this new capability and this new guarantee - so we packed a lot of long-due reorganization in. In the long run, this makes things more clear for new users.

All that said,

This function is literally identical to the 8.1 version. system.vision.transform simply calls system.gui.transform for you. Any difference in behavior there is either environmental, or due to some other factor in the 8.3 upgrade, but I can't really think of what it would be.

But:

This is not safe. Any interaction with Vision components, even indirectly via system.gui.transform, must take place on the EDT. system.gui.transform is non-blocking by nature - that's why it accepts a callback argument.

4

Is the vision client on windows or linux?

5

Is the vision client on windows or linux?

The vision client is running in windows 10 on a vm. Regarding this I will try some more testing with different windows versions and also on a not virtualized machine.

You should use named queries, or if you need more dynamic SQL, you should send a message using system.util.sendMessage and invoke a message handler on the gateway that runs system.db.runPrepQuery.

Yeah, I get the security concerns around system.db.runPrepQuery being deprecated for dynamic SQL. Guilty as charged I’ve leaned heavily on it for dynamic CRUD operations and calling stored procedures. Named Queries are great for a lot of things, but when it comes to flexibility, especially with dynamic structures, they can feel a bit rigid. That said, your suggestion makes sense. I’ll start pushing the raw SQL work to the gateway side and have the client use system.util.sendRequest() (hinted by pturmel) instead especially since I usually need something back anyway. Not ideal, but it’s a fair trade for better security.

1 Like
6

You might also like my @system.util.runInGateway decorator provided by my Integration Toolkit. Simpler than, and more bandwidth than, sendRequest.

7

if you are referring to:

Integration Toolkit-2.1.1.251011523-v81.modl (https://www.automation-pros.com/ignition/Integration%20Toolkit-2.1.1.251011523-v81.modl)

I was already taking a look at your Toolkit (stumbled by chance during forum browsing) while using the 8.1 version of Ingition. With the 8.3 I wasn’t sure if it was compatible. I will give it a spin non the less.

Thank you.

8

The v8.1 module is not compatible with v8.3 (none are, from anyone). See this topic: