# Persisting an Instance of an Object that Talks to Devices **URL:** \ **Category:** Ignition\ **Tags:** python, ignition79, scripting\ **Created:** [November 7, 2018, 1:37am UTC](https://forum.inductiveautomation.com/t/persisting-an-instance-of-an-object-that-talks-to-devices/20608 "2018-11-07T01:37:06Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![cmaynes](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmaynes/32/6852_2.png) [@cmaynes](https://forum.inductiveautomation.com/u/cmaynes)\ **Post date:** [November 7, 2018, 1:37am UTC](https://forum.inductiveautomation.com/t/persisting-an-instance-of-an-object-that-talks-to-devices/20608/1 "2018-11-07T01:37:06Z")
**QUESTION** : Is the following approach to object persistence in Ignition optimal? (I added a lot of extra documentation, because I think this is probably a common-ish problem in manufacturing.) **Problem:** I have a [VB.NET](http://VB.NET) program that sits on a test station and talks to a few devices. This was legacy code that was reworked a little to work with Ignition system. We talk to the VB program and get data back from it through a PLC middleman. I want to move this [VB.NET](http://VB.NET) driver into Ignition, converting to Python 2.5. **Why I want to make the change:** - One language for future developers - Python - Reduce pain of adding / rearranging stations, by not relying on PLC unnecessarily - More maintainable - Far richer controls from user’s perspective ( a lot of features have not been added, because of limited PLC space and pain of deployment ). - Cheaper -\> No PLCs for at least this part of our system **Characteristics of driver:** - receives async command from user - maintains state & periodically polls the device to keep connection alive - periodically does other things like evaluate bus to check for new devices - only one command allowed at time to be sent to device, to avoid weird overlapping commands from separate chains of commands that result in funky operation. **The Approach I am Thinking of:** - create a class, Device() -\> see below for example. **_Use Python 3…just for print statements_** - use a few kill events - Event() thread objects - to stop long threaded processes, like testing and polling - set these kill events when I need to abruptly end something in a safe manner ( the real-world version will involve data collection with a Queue() ) **- use putClientProperty/getClientProperty to store this class between asynchronous calls to action from the user to test / abort a device** **Question (again):** So, again my question is whether this is the best approach to this problem. I haven’t seen anything quite like this question here. Most questions about persistence revolved around global variables or using the database and tags, but that is painful while an object-oriented approach feels much cleaner and understandable. I am open to hearing other possible implementation schemes…whatever anyone has to offer. ---
**Author:** ![raymond1982](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/raymond1982/32/6490_2.png) [@raymond1982](https://forum.inductiveautomation.com/u/raymond1982)\ **Post date:** [November 7, 2018, 2:34am UTC](https://forum.inductiveautomation.com/t/persisting-an-instance-of-an-object-that-talks-to-devices/20608/2 "2018-11-07T02:34:35Z")
Ive read this 3 times. And Id like to get some clarity. We talk to the VB program and get data back from it through a PLC middleman. \<----- Confused [is this an Ingear thing?] I want to move this [VB.NET](http://VB.NET) driver into Ignition, converting to Python 2.5. \<---- By driver do you mean leveraging Ignitions built in device drivers and writing your code around them? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [November 7, 2018, 3:53am UTC](https://forum.inductiveautomation.com/t/persisting-an-instance-of-an-object-that-talks-to-devices/20608/3 "2018-11-07T03:53:32Z")
It’s not a terrible approach, but consider **not** using python threads or events. Jython is really a java environment, not python, and using invokeAsynchronous is really the best way to launch independent threads in Ignition. Also, make sure that a scripting restart in the gateway triggers replacement of your background threads – this is not automatic, and will be a source of grief (memory leaks and blocked sockets, at least). So too with all jython classes – make sure instances are tracked in system.util.getGlobals() so they can be replaced. Consider writing state changes to one or more memory tags and letting Ignition distribute naturally. (You can then initialize from them when scripts reload, too…) ---
**Author:** ![cmaynes](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmaynes/32/6852_2.png) [@cmaynes](https://forum.inductiveautomation.com/u/cmaynes)\ **Post date:** [November 7, 2018, 6:13am UTC](https://forum.inductiveautomation.com/t/persisting-an-instance-of-an-object-that-talks-to-devices/20608/4 "2018-11-07T06:13:35Z")
1. I plan on using **sockets** lib in Python to handle the SCPI commands. I may need to write it in Python 2.7/3, so I can use PyVisa though. 2. By driver, I just mean a program that sits on the host computer, takes commands through the PLC and then executes those by sending commands to the device itself. This currently uses Ingear drivers, but PyVisa has a pure python implementation that doesn’t require the drivers to be installed. ---
**Author:** ![cmaynes](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmaynes/32/6852_2.png) [@cmaynes](https://forum.inductiveautomation.com/u/cmaynes)\ **Post date:** [November 7, 2018, 6:29am UTC](https://forum.inductiveautomation.com/t/persisting-an-instance-of-an-object-that-talks-to-devices/20608/5 "2018-11-07T06:29:37Z")
Thanks for your suggestions. I am not sure why I need to replace my threads when there is a scripting restart in the gateway. If you are saying that I will lose my object instance when an update comes into the client, then a simple if statement to create another and re-evaluate the bus would solve this. As for storing state changes, I am really trying to make something completely independent of Ignition. It sounds like running this in Ignition will create too many weird problems when the client is updated. I am thinking of just writing in Python 3, storing a self-contained (all libs & python 3 included) copy of the program on the server, having Ignition copy this to the host computer when a client opens if the program is not already there and the version has not been updated since the last copy, and then start that program from Ignition and use a server/client model with sockets lib to send commands back and forth. I don’t like this as much…thoughts? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [November 7, 2018, 1:55pm UTC](https://forum.inductiveautomation.com/t/persisting-an-instance-of-an-object-that-talks-to-devices/20608/6 "2018-11-07T13:55:20Z")
> [@cmaynes](#): > > I am not sure why I need to replace my threads when there is a scripting restart in the gateway. Because your threads will continue running old code in the old modules' contexts, but all new calls from the rest of Ignition into your code will call the new function and class instances in the new modules' contexts. Even the unedited modules. I think running such a "driver" in a separate process, with code in Ignition to pass information back and forth, is dramatically more complicated than just writing the driver for jython 2.5 (or 2.7 in v8). ---
**Author:** ![cmaynes](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmaynes/32/6852_2.png) [@cmaynes](https://forum.inductiveautomation.com/u/cmaynes)\ **Post date:** [November 7, 2018, 4:44pm UTC](https://forum.inductiveautomation.com/t/persisting-an-instance-of-an-object-that-talks-to-devices/20608/7 "2018-11-07T16:44:36Z")
Wait... If I create an instance of a class, which has internal references to threads it has created, and then I update the client and, for example, I added a new function to the class in the update, then all instances of that class should get updated automatically - right? Shouldn't the instance of the class already sitting there in the client from before the update still be available after the update? It should, I think, so the new method should appear and I should be able to use the new code immediately. If this last assumption is wrong and an instance of the class doesn't get updated, then I guess the thing I would need to do is check the edit count and then kill all threads connected to the class instance and then create a new instance that references the new class code. ... I have hit a wall with converting from [VB.NET](http://VB.NET) to jython/python. It looks like I absolutely need the PyVisa library. I tried importing to Ignition, but it needed to use: > from **future** import unicode\_literals and this wasn't available in current **future**.py file. I tried getting a copy of this file from the latest jython version available and pasting that in, but I get the same error after deleting the cache on my computer and restarting the designer. I am not sure if there is maybe another way to handle this? If I can't get this library into Ignition, I have no choice but to create an external python program to act as my "driver." ---
**Author:** ![raymond1982](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/raymond1982/32/6490_2.png) [@raymond1982](https://forum.inductiveautomation.com/u/raymond1982)\ **Post date:** [November 7, 2018, 5:01pm UTC](https://forum.inductiveautomation.com/t/persisting-an-instance-of-an-object-that-talks-to-devices/20608/8 "2018-11-07T17:01:44Z")
I just designed a part of a project where an instance of a class could survive an update and hot-load any script changes made. This is no trivial task. It requires an understanding of async threads and if you’re communicating with the event data thread back and forth it gets even deeper. Maybe consider your design where any state is off loaded to a db or tag. @pturmel is giving you good advice. And I would highly recommend any socket/io comms to be run through a java module of your on devising. Making comms truly non-blocking in jython is tricky especially if its running in the gateway scope.We had a need for unsolicited messages so I wrote an ENIP/Cip AB driver in jython that runs in the gateway scope and it took a long while with much heartache to get it stable. Also any experimentation with (infinite loops) that you run in the gateway scope could crater it… backup frequently. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [November 7, 2018, 6:18pm UTC](https://forum.inductiveautomation.com/t/persisting-an-instance-of-an-object-that-talks-to-devices/20608/9 "2018-11-07T18:18:03Z")
> [@raymond1982](#): > > We had a need for unsolicited messages so I wrote an ENIP/Cip AB driver in jython that runs in the gateway scope and it took a long while with much heartache to get it stable. Holy smokes! I'm guessing this was before I introduced my [Ethernet/IP module](https://inductiveautomation.com/moduleshowcase/module/automation-professionals-llc-ethernetip-class-1-communications)? ---
**Author:** ![cmaynes](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmaynes/32/6852_2.png) [@cmaynes](https://forum.inductiveautomation.com/u/cmaynes)\ **Post date:** [November 7, 2018, 6:27pm UTC](https://forum.inductiveautomation.com/t/persisting-an-instance-of-an-object-that-talks-to-devices/20608/10 "2018-11-07T18:27:18Z")
Alrighty then…what I am hearing is that object persistence / thread persistence is a pain in the butt and not worth the trouble. New Design: - create a Device() class in pure Python - replace all of the threading calls with system.util.invokeAsynchrous() - use tags to store data, kill event bools. When class created, use @property in python to do lazy reloading of this data from the tags as needed. So I am still using a class, but I am not going to maintain an instance and instead create it on-the-fly when I need it. This should avoid all of the problems you have described. I am not going with writing a java module, because a big reason for doing this in Ignition is reducing the number of programming languages so it is easier to maintain and for new developers to understand. Thanks for the help! ---
**Author:** ![raymond1982](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/raymond1982/32/6490_2.png) [@raymond1982](https://forum.inductiveautomation.com/u/raymond1982)\ **Post date:** [November 7, 2018, 6:31pm UTC](https://forum.inductiveautomation.com/t/persisting-an-instance-of-an-object-that-talks-to-devices/20608/11 "2018-11-07T18:31:20Z")
No it had been out a while. I just wanted the experience and knowledge. I see 0x4c in my sleep now. I also got it running on Python 3.7 using async/io for comms full logix data structure browsing, local emulation, and reading and writing. The other side of the 3.7 version is that it can be used as a api for web services. For example think of a web api where you post a query for a tag(s) and get a json object in return. In my spare time im integrating a websocket framework. I got inspired by a crypto market API for pushing crypto currency market data to the client and i thought i could make this work for my driver. Its a side project for fun though nothing commercial. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [November 7, 2018, 6:37pm UTC](https://forum.inductiveautomation.com/t/persisting-an-instance-of-an-object-that-talks-to-devices/20608/12 "2018-11-07T18:37:48Z")
> [@cmaynes](#): > > If I create an instance of a class, which has internal references to threads it has created, and then I update the client and, for example, I added a new function to the class in the update, then all instances of that class should get updated automatically - right? No. For a client, I believe the client restarts deep enough that background threads will be killed. But if not, and certainly in gateway scopes, the old instance and threads will still be there running the old code. All event routines will call into the new code, with new instances. Even the module global scope (where module functions and class names exist) is recreated from scratch upon script reload. Old threads see the old modules. The dictionary you get from system.util.getGlobals() is the only object that remains untouched. Put your state variables, thread objects, and sockets here so that your module code can find and kill off old versions. You don't need to watch the edit count. Just do it unconditionally at the top level of your script module(s). > [@cmaynes](#): > > I have hit a wall with converting from [VB.NET](http://VB.NET) to jython/python. It looks like I absolutely need the PyVisa library. Ewww. I don't see any way to use VISA drivers from a java environment, a requirement for jython access. ---
**Author:** ![raymond1982](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/raymond1982/32/6490_2.png) [@raymond1982](https://forum.inductiveautomation.com/u/raymond1982)\ **Post date:** [November 7, 2018, 6:39pm UTC](https://forum.inductiveautomation.com/t/persisting-an-instance-of-an-object-that-talks-to-devices/20608/13 "2018-11-07T18:39:16Z")
They are not killed on Update Push i know that for certain. Restart absolutely. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [November 7, 2018, 6:43pm UTC](https://forum.inductiveautomation.com/t/persisting-an-instance-of-an-object-that-talks-to-devices/20608/14 "2018-11-07T18:43:30Z")
> [@pturmel](#): > > Ewww. I don't see any way to use VISA drivers from a java environment, a requirement for jython access. There's a SourceForge project that wraps the VISA API for java: > **[Java API for VISA Devices](https://sourceforge.net/projects/jvisa/)** > > Download Java API for VISA Devices for free. Java wrapper for native VISA library and TDS3000 oscilloscope driver. Write VISA instrument drivers in Java for Windows and Linux. Maybe the best way to give a full description is to explain the history of... ---
**Author:** ![cmaynes](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmaynes/32/6852_2.png) [@cmaynes](https://forum.inductiveautomation.com/u/cmaynes)\ **Post date:** [November 7, 2018, 7:46pm UTC](https://forum.inductiveautomation.com/t/persisting-an-instance-of-an-object-that-talks-to-devices/20608/15 "2018-11-07T19:46:06Z")
PyVisa has its own internal implementation of VISA, so that you don’t need any external driver. PyVisa is completely self-contained and has a very simple interface, which is why I want to use it. Moved to [new thread](http://forum.inductiveautomation.com/t/how-to-use-pyvisa-or-maybe-sockets-in-ignition-to-talk-to-visa-scpi-device/20634/3) for PyVisa / VISA communication.