Best Way to Develop While Disconnected from Device

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.

Have you looked into the simulator?

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

1 Like

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:

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

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.

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..

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

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

@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.

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.

1 Like

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?

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.

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.