Best Way to Develop While Disconnected from Device

[rrebro]

I am working on creating a standard for our HMIs using Ignition Vision. One of the biggest obstacles is trying to develop while away from the actual live PLC. I know there must be an easy way that I am missing.

[JordanCClark]

Have you looked into the simulator?

https://docs.inductiveautomation.com/display/DOC80/Programmable+Device+Simulator

[pturmel]

What driver will the real PLC use? If modern Logix, you could load a copy of the PLC code into my Ethernet/IP driver, which will simulate the tags. You could use a 2nd server with the target PLC's real IP address for even more confidence:

Allen-bradely tags

Ask that customer to provide an export of that processor in “L5X” format (xml). Install my Ethernet/IP Class 1 Communications module and create a virtual PLC device (Host Device) with it. Import the L5X into the “Configuration” section of that virtual PLC device. There are only a handful of datatypes that won’t import, like MESSAGE tags. Even AOI types and tags import as long as they aren’t protected. At this point, the tags and datatypes from the real PLC will be accessible as if you were …

Step by step instructions here (and read the whole topic):

AB PLC tag import/export

Start in your gateway’s configuration section, under the OPC Server’s “Device Connections” and click on “Create new Device…”: [Screenshot_20200312_155620] Select the Ethernet/IP Class1 Host Device: [Screenshot_20200312_155641] Give it a name and serial number… [Screenshot_20200312_155724] … and a slot number and listening address (required for external access) then “Create”: [Screenshot_20200312_155758] Then, in the list of devices, pick the new device’s “More” button, and select “Co…

[pturmel]

Also, if the target PLC or device will use Modbus (TCP or RTU), you can use my beta Advanced Modbus Driver in a v7.9 server. Again, giving that server the IP address of the real PLC.

Automation Professionals' Advanced Modbus Driver

Automation Professionals is pleased to announce the first beta for its Advanced Modbus Driver, for Ignition version 7.9. Key features: Server mode, emulating one or more slave devices, using any of the three typical connection types, including simultaneous connections of multiple types. Client mode, incorporating all three connection modes in one driver. Support for Modbus Function Codes 20 and 21, File Records. Configure protocol tweaks for troublesome devices per slave unit, enabling suppor…

[nminchin]

I find it easiest just to convert the tags from OPC to memory tags. No information in the tag config is lost in doing so (all of your OPC property config remains in v8, this was not the same back in v7!! ).

I use the python3 script in here to do this. Note it's python3 and therefore incompatible to run inside igntion. It will convert back and forth between opc and memory, and will only convert back tags that are actually opc tags, as opposed to converting all memory tags to opc, which would be bad..

Reading PLC tags offline

If I don’t have a PLC but I have the project, most of our tags are within UDTs which are already developed, so these are fairly easy to create manually or using a tool that takes in a list of instance names and parameters and creates the udt instances for me. Without a PLC, in v8, you can convert tags between opc and memory without any information being removed (this wasn’t in the case in v7). I use this script, just copied into the script console, to convert tag json copied into the clipboard…

[pturmel]

@nminchin

I find it easiest just to convert the tags from OPC to memory tags.

Meh. Letting Ignition talk to what it thinks is a real device is way simpler, in my book.

[nminchin]

That’s assuming though that there are simulation modules for each plc type you’re reading from though, and that the plc code is actually written yet

[maidamar]

@nminchin I like your approach.
I tried your code but it did not update the UDT instances. And it makes sense, since copying the UDT instances as JSON does not recover the opcItemPath or valueSource properties.
You mentioned it worked for instances as well. Was it a different code?

Also, it does not work if I copy a single tag, only for multiple tags, but it’s not that hard to adapt that part.

[nminchin]

As you discovered, you need to use the script on the UDT definition itself, not the instances. If you wanted to just affect some instances, you’d need to modify the script to add the value source property in order to override the definition.
I’ve actually rejigged thmy code a bit as I have other functions now that act in the clipboard so I wanted to make it more reusable, and I did end up fixing the single tag issue in that.

[rrebro]

I’m circling back to this, I tried it out, uploaded a .L5X and it seems to work pretty well, except I can’t seem to find any tags that were aliases of another tag. Any thoughts on that?

[pturmel]

Aliases aren’t supported. Mainly because I don’t know how to represent them when an external client connects and browses my virtual controller. It isn’t documented in Rockwell’s Data Access manual and I haven’t tried to reverse-engineer it.

[pturmel]

Just took another look at the relevant AB docs.... there's a mention in the Design Considerations manual (RM094) discouraging external access to aliases, for performance reasons:

Because an alias tag appears as a standalone tag to Linx-based software, an alias tag that references a compound array or structure can require additional communication time. When you reference tags from Linx-based software or other HMI, it can be fastest to reference base tags directly.

FWIW, I've avoided aliases in my projects for ages.