Print outside of the script console

Hello, I started working with ignition about a month and a half ago.

I'm trying to find out how a existing script is working. I'm working with a project where I don't want to make any changes as saving anything in the script directly affects the production environment.

I was wondering what the best practice would be here. Should I create a duplicate of the perspective component in designer, and then use system.util.getLogger()? Is there other ways of finding out data? The script I'm dealing with is tied to a chart's data property and uses property binding and a transform. I can't copy and paste this script into the script console as it is using values from the arguments passed into the transform function, and I don't know what those values look like, hence why I want to print.

1 Like

Sounds like you need to stand up a development environment (isolated) and dump the gateway backup into it. You are otherwise playing with fire.

(You can run a dev environment two hours at a time, indefinitely, without a license. There's no excuse for experimenting in production.)

Do make sure the isolated dev environment cannot physically reach the production database and devices.

4 Likes

Check what properties the bindings point to, and then go see what they look like.
If they don't have a value because you're in the designer, check their bindings to see where they get their data. Follow that trail until you have enough information to mock up data.

But as Phil said: Run a test/dev environment.

1 Like

This is what I'm worried about: if I dump the gateway backup and export the project from designer into another instance, I won't have access to the data for the script anyway. No mock data has been created for this at all, so I still won't have access to any data to investigate how a script works. This specific script references arguments passed into the transform function and runs system.db.runNamedQuery.

A proper dev environment has access to replicated databases

4 Likes

I will try this until the script console works, I see now that the value property in the transform binding is referencing this 'data' prop that has an array. I do want to try creating a proper dev environment.

Then follow the bindings until you get something that you can feed into a script console replication of the transform script

1 Like

I'm not sure how to start that process. It is something I will look into, thanks for pointing that out.

1 Like
1 Like

So I'm waiting for approval to duplicate our databases.

In the meantime, is it realistic to create a backup gateway, upload it to ignition maker edition, automatically have all the same opc ua and plc connections, and connect it to the current database, but only have read access for the database, that way I can't mess anything up? I won't have a full dev environment, but I think it might be a good crutch for now.

Sorry to reply on a thread with a solution, but I wanted to reference this context. Should I create a new thread next time?

I suggest you read carefully the EULA of ignition maker.

"Ignition Maker Edition is a free-license edition that can be strictly used for non-commercial and personal educational use."

2 Likes

In addition to it being for non-commercial use, it also has limitations as to what it can do, it is not an acceptable replacement for a full blown gateway.

If the cost is a concern, install an unlicensed gateway and just use the trial mode for testing purposes, it's completely free.

6 Likes

Nope, not with any edition of Ignition. You need proper isolation, full stop.

And really, just use trial mode of the standard edition for testing and development. I have dozens of VMs that I spin up on demand, matching various client systems. All unlicensed. The two-hour trial can be reset as often as needed, and doesn't kick you out of the designer or anything drastic like that.

Ok, thanks for the clarifcation there everyone on maker edition. Barring that, does the rest of the idea work?

When you create those extra environments, do you create a replicate database for each, or just connect them with current databases with read access only? this is my main question

Yes, when the functionality I'm working on needs the DB. Otherwise I leave the connection broken. Same with device connections. (I have a hardware lab with a variety of PLC hardware, and I can emulate large numbers of Logix and Modbus-based PLCs with my third-party modules.)

I insist that my dev environments be able to take a gateway backup from a client system and it "just work" in my isolated environment. That way, anything I export from dev/test to deliver to production doesn't require any further preparation.

2 Likes

Let's have a photo, Phil, and try and show some of the candles for your late-night coding.

It's a mess. I have plans to get it all wall-mounted in the near future, in my copious free time. I'll post a photo then. (:

Exactly! We want to know that you're just like the rest of us!

5 Likes